SMTP error 554 5.0.0: transaction failed

554 5.0.0 is 5yz (permanent failure) paired with the most generic possible enhanced status

code: 5.0.0 means "other or undefined status" in RFC 3463. The server is refusing the message

outright but is not telling you a specific reason through the code itself — the reason has to come

from the free-text part of the reply or from checking your own sending reputation.

A real transcript

MAIL FROM:<you@yourdomain.com>
250 2.1.0 Sender OK
RCPT TO:<recipient@example.com>
250 2.1.5 Recipient OK
DATA
354 Start mail input
...
554 5.0.0 Message rejected due to policy restrictions

The free-text after the code is doing the real work here — always read the full line, since two

sends that both show 554 5.0.0 can fail for unrelated reasons.

How the generic reject is worded by provider

Microsoft 365 in particular tends to wrap a genuinely generic upstream rejection in its own

5.0.3xx family, which is worth recognising as "we are forwarding someone else's unspecified

reject" rather than a code Microsoft generated itself.

Who is at fault

Almost always sender reputation or policy, since this is a permanent 5xx:

• The sending IP or domain is on a blacklist the receiver consults.
• The message or sender tripped a content/policy filter and the receiver declined to give a more

specific code.

• SPF, DKIM, or DMARC failed in a way the receiver treats as an outright reject rather than a soft

fail.

• A relay in the path (shared hosting, a misconfigured relay) is sending in a way the destination

flags generically.

Diagnose it yourself

1. Check your sending IP against major blacklists with a DNSBL lookup. For an IP of

203.0.113.5, the reversed-octet query is dig +short 5.113.0.203.zen.spamhaus.org — a

non-empty answer means you are listed there.

1. Check your SPF record resolves and is well-formed: dig TXT yourdomain.com +short and

confirm it starts v=spf1 and ends in an all mechanism.

1. Check DKIM is actually signing outbound mail: send a test message to a mailbox you control

and read the Authentication-Results header, or run `dig TXT selector._domainkey.yourdomain.com

+short` to confirm the public key is published.

1. Check DMARC: dig TXT _dmarc.yourdomain.com +short — a missing or malformed record pushes

some receivers toward a flat generic reject rather than a specific alignment-failure code.

The fix, in order

1. Read the full text of the reply, not just the code — providers frequently put the real

reason (blacklist name, policy name, specific rule) in the message text that follows 554 5.0.0.

1. Check your sending IP and domain against major blacklists. A listing is the single most

common cause of a generic permanent rejection.

1. Verify SPF, DKIM, and DMARC are set up and aligned for the domain actually sending the mail.

A p=reject DMARC policy failing silently can surface as a flat reject like this at some

receivers.

1. Review recent content and sending pattern changes. A sudden shift — new subject-line

pattern, large attachment type, sharp volume increase — can trigger policy filters even from a

previously clean sender.

1. If on shared infrastructure (shared IP pool, shared hosting SMTP), check whether another

tenant on the same IP caused the listing; this is common and outside your direct control but

still affects your delivery.

1. Contact the receiving provider's postmaster channel if the above all check out clean and

the rejections continue — this code gives too little detail to self-diagnose past a point.

What not to do

• Do not keep resending the identical message to the same recipient — this is a permanent 5xx,

retrying as-is will fail identically every time, and repeated identical attempts to a server that

already rejected you can themselves look like abuse.

• Do not assume the generic code means a generic, low-stakes problem. 554 5.0.0 sits in the same

severity tier as a specific 550 5.7.1; it is just less informative, not less serious.

• Do not skip the blacklist and authentication checks because the code "doesn't mention" either —

the 5.0.0 suffix exists precisely because the receiver chose not to specify, not because those

mechanisms are ruled out.

MailPilot checks SPF, DKIM, and DMARC alignment continuously and tracks per-mailbox reputation

daily, which turns a vague 554 5.0.0 into an actual diagnosis — you see whether the mailbox's

score dropped before the rejections started, rather than guessing from a blank enhanced status

code.