SMTP error 554: what it means and how to clear it

554 is a permanent failure. The receiving server has evaluated your connection or your message and refused it outright, which means a retry with the same message from the same source will be refused again. Unlike a 4xx response, there is nothing to wait out. The useful part of a 554 is never the number — it is the enhanced status code and the human-readable text that follow it.

Read the enhanced code first

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked using zen.spamhaus.org
554 5.7.1 <user@example.com>: Relay access denied
554 5.7.1 Message rejected due to content
554 5.4.6 Hop count exceeded - possible mail loop

The second field classifies the failure:

Copy the whole line out of your bounce before you do anything else. "I got a 554" is not a diagnosis.

The four causes behind most 554s

1. Your sending IP is on a blocklist the receiver consults. The text usually names it. Check the IP against the list that was cited, not against a generic "blacklist check" page, and follow that list's own delisting process. Note that dead lists still appear in old tutorials — SORBS shut down in June 2024, so a reference to it in your bounce means the receiver's configuration is stale, not that you are listed somewhere real.

2. Relay access denied. This is a configuration error on your side, not a reputation problem. You are asking a server to deliver to a domain it does not accept mail for, and you have not authenticated. Almost always: missing SMTP AUTH, wrong port, or a client pointed at the wrong host.

3. Authentication or policy requirement unmet. Receivers increasingly refuse unauthenticated bulk mail. Microsoft's version is explicit — 550 5.7.515 Access denied, sending domain does not meet the required authentication level — and the 554 family carries equivalents elsewhere.

4. Content or structure rejection. Malformed headers, a missing From, a broken MIME boundary, an executable attachment, or a URL whose domain is itself blocklisted. Note that a link's reputation is separate from your domain's: one bad shortener can earn a 554 on an otherwise clean message.

Gmail

Gmail's permanent rejections usually point you at a documented reason:

554 5.7.1 [203.0.113.10] Our system has detected that this message is
likely unsolicited mail. To reduce the amount of spam sent to Gmail,
this message has been blocked.

Work the sender requirements, in this order: SPF and DKIM passing with DMARC alignment on the visible From domain; valid forward-confirmed reverse DNS on the sending IP; one-click unsubscribe on bulk commercial mail; TLS on the connection. Then look at your spam rate in Postmaster Tools v2 against Google's 0.30% threshold — aim under 0.10%. Do not go looking for a domain reputation grade: those dashboards retired with v1, which stopped serving senders from 30 September 2025 and was gone by the end of 2025.

Outlook and Microsoft 365

Microsoft's rejections are more specific and more IP-driven:

554 5.7.1 Service unavailable; Client host [203.0.113.10] blocked
550 5.7.1 Unfortunately, messages from [203.0.113.10] weren't sent.
550 5.7.515 Access denied, sending domain does not meet the required authentication level

Microsoft publishes no checkable blocklist, so there is nothing to query. Your only feedback channels are SNDS, for per-IP volume, complaint and trap data on IPs you can prove you own, and JMRP, the junk-report feedback loop. Register for both. For an IP-level block, use Microsoft's delist portal once — and change your sending pattern before you do, because a repeat submission with unchanged behaviour achieves nothing.

Be careful not to misread the temporary codes as permanent: 451 4.7.500 and the 4.7.6xx family mean throttling. Back off and retry; do not suppress the recipient.

Yahoo and AOL

Yahoo and AOL run on one filtering stack, so a 554 from either is the same verdict:

554 delivery error: dd This user doesn't have a yahoo.com account
554 5.7.9 Message not accepted for policy reasons

The first is a bad address — suppress it immediately, because repeated sends to non-existent Yahoo mailboxes are read as list-quality evidence. The second is a policy decision: check DKIM in particular, since Yahoo's filtering leans on it, and check your complaint levels. Yahoo also honours its own feedback loop for complaint data.

What to do, in order

1. Capture the full bounce line, including the enhanced code and any named blocklist.
2. Classify it: policy, relay, authentication, or content.
3. If an address is invalid, suppress it permanently — do not retry.
4. If a blocklist is named, verify the listing at that list and follow its delisting process.
5. If authentication is implicated, fix SPF, DKIM and DMARC alignment and re-test with a real message's headers.
6. Only then change content, and change one thing at a time.

What not to do

• Do not retry a 554 on a schedule. It is permanent; automated retries accumulate as reputation damage.
• Do not treat a 554 for one recipient as a domain-wide block. Check whether other recipients at the same provider are still accepted.
• Do not submit delisting requests before fixing the cause. The listing returns, and some lists extend the penalty.
• Do not confuse `5.x.x` with `4.x.x`. Suppressing a throttled recipient discards a valid address.
• Do not strip words from your subject line as the first response. A 554 citing a blocklist has nothing to do with your copy.

How MailPilot helps

MailPilot classifies the SMTP responses your mailboxes receive, so a permanent policy rejection is never retried like a temporary one, and it checks SPF, DKIM and DMARC alignment on your sending domain before a campaign triggers an authentication-class 554. Its warm-up — over OAuth for Gmail and Outlook, or SMTP/IMAP for SendGrid, Amazon SES, Mailgun, Postmark and custom hosts — builds the reputation that keeps the policy rejections from firing in the first place.