SMTP Error Codes Explained: 550, 551, 552, 554 (and What to Do About Each)

SMTP error codes are three-digit replies a mail server returns when it refuses or defers your message. The first digit carries the single most important fact: 4xx means "try again later" and usually fixes itself, while 5xx means "permanent failure" — no amount of retrying will deliver that message as-is. This guide decodes the four codes that dominate bounce logs — 550, 551, 552, and 554 — plus the enhanced status codes that tell you why the server refused.

How SMTP response codes are structured

Every reply you see in a bounce has up to three parts:

550 5.1.1 The email account that you tried to reach does not exist.
└┬┘ └─┬─┘ └──────────────────┬──────────────────────────────┘
 │    │                      └── human-readable text (varies by provider)
 │    └── enhanced status code (RFC 3463)
 └── SMTP reply code (RFC 5321)

The three-digit reply code. The first digit is the class: 2xx = success, 4xx = transient failure, 5xx = permanent failure. The second digit is a rough category — x0z is syntax, x2z is connections, x5z is the mail system — and the third digit narrows it further.

The enhanced status code. Defined in RFC 3463, formatted class.subject.detail. The class mirrors the first digit (4 = transient, 5 = permanent). The subject tells you what broke:

So when you read 550 5.7.1, you can parse it cold: permanent failure, policy layer, not authorized. That reading skill is worth more than memorizing any SMTP response codes list.

4xx vs 5xx: the distinction that decides your retry logic

4xx = "not right now." Greylisting, rate limiting, a full queue, a flaky DNS lookup on the receiver's side. The correct response is to back off and retry — a sane schedule is 15 minutes, then 1 hour, then 4 hours, giving up somewhere between 24 and 72 hours. Almost all 4xx bounces resolve without you touching anything.

5xx = "not ever, as things stand." The server is making a definitive statement about the recipient, the message, or your reputation. Retrying the identical message to the identical address produces the identical result — and actively hurts you. Hammering a domain with mail it has already refused trains its filters to distrust your IP, and re-sending to addresses that 5.1.1'd yesterday is exactly the behavior Gmail's spam classifiers are built to catch.

One nuance: a 5xx condition can change over time. A full mailbox gets emptied. A blacklist listing expires. But nothing about pressing "resend" changes the outcome — something has to change first, on the recipient's side or yours.

SMTP error codes: the field guide

For the deeper model of bucketing every bounce type, see our guide to bounce categories and handling.

What does SMTP error 550 mean?

RFC 5321 defines 550 as "requested action not taken: mailbox unavailable." In practice it's two completely different problems wearing the same code — and telling them apart is the whole job.

550 5.1.1: the address doesn't exist

550 5.1.1 The email account that you tried to reach does not exist.
550 5.1.1 <[email protected]>: Recipient address rejected: User unknown

The mailbox was never created, was deleted, or you have a typo (gmial.com, yaho.com). This is a true hard bounce: suppress the address immediately, everywhere it appears. Continuing to send to known-dead addresses is one of the fastest ways to tank sender reputation — Gmail watches your invalid-recipient rate closely, and a bad one drags down delivery for everyone else on your list.

550 5.7.1: policy rejected you

550 5.7.1 Message rejected due to content policy
550 5.7.1 Our system has detected that this message is likely unsolicited mail

Here the address is probably fine — the receiving server refused you. Common triggers: spammy content, a listed IP, failed authentication, or a recipient-side block. Don't suppress the address; fix the stream. The 5.7.1 vs 5.1.1 distinction — policy problem vs address problem — is the single most useful reading skill in bounce debugging.

How to tell them apart in practice: read the enhanced code first (5.1.x = address, 5.7.x = policy), then look at the blast radius. One recipient bouncing while their colleagues at the same domain receive fine → bad address. Everyone at the domain bouncing at once → policy.

Try it: Run your list through the free email validator before the next campaign. Its 12 layers — syntax, MX, SMTP probing, catch-all detection, typo suggestions — flag the addresses that would come back as 550 5.1.1 before they bounce and cost you reputation.

What does SMTP error 551 mean?

551 means "user not local; please try \<forward-path\>." It was designed for forwarding: the server tells you the recipient moved and where to send instead. In 2026 you'll rarely see it in the wild — most servers folded the behavior into 550 because returning live forwarding addresses made address harvesting trivial for spammers.

Where it still appears:

• Decommissioned domains and migrations. The old mailhost knows the user moved, but the new address isn't published.
• Hybrid Exchange / connector misconfigurations, where an on-prem server and the cloud tenant disagree about who owns the recipient.
• Relaying denied, historically 551 we do not relay — today that's almost always expressed as 550 5.7.1 instead.

Retry: no. Suppress the address and get the current one from the recipient through another channel. If you see 551 across a whole domain you own, check your hybrid mail-flow connectors — something is routing mail to a server that no longer hosts those mailboxes.

What does SMTP error 552 mean?

552 is "exceeded storage allocation," and it splits into two very different situations.

552 5.2.2: the mailbox is full

552 5.2.2 The email account that you tried to reach is over quota.

Treat this as a soft bounce wearing a hard code. The address exists; the human just hasn't cleaned their inbox. Retry over a few days. But a mailbox that stays full for weeks is usually abandoned, and abandoned mailboxes eventually become spam traps. Rule of thumb: suppress after 3 consecutive full-mailbox bounces spanning at least 30 days. Some receivers return the temporary variant (452 4.2.2) for the same condition — your normal 4xx retry logic handles that one.

552 5.3.4 / 5.2.3: the message is too large

552 5.3.4 Message size exceeds fixed limit

Retrying changes nothing — shrink the message. Remember that MIME base64 encoding inflates attachments by roughly 33%, so a 30 MB file becomes ~40 MB on the wire. Gmail accepts up to 50 MB inbound; many corporate gateways cap at 25 MB, and Microsoft 365 tenants can set their own limits. If you hit this regularly, stop attaching and start linking to hosted files.

What does SMTP error 554 mean?

554 "transaction failed" is the catch-all: the server refused the message and didn't commit to a precise reason. Since late 2025 it's also where you feel the big providers' shift to hard rejection of non-compliant senders:

• Gmail moved from temporary 421 deferrals to permanent 5xx rejects in November 2025: 550 5.7.26 for failed SPF/DKIM/DMARC authentication, 550 5.7.25 for missing reverse DNS (PTR), and 5xx variants for streams with bad spam signals.
• Microsoft began hard-rejecting unauthenticated high-volume mail in May 2025, typically as 550 5.7.515.
• Yahoo has been domain-reputation-first since April 2025; expect 554 5.7.9 Message not accepted for policy reasons when your domain reputation is weak.

The root cause behind a 554 is almost always one of five things: a blacklisted IP, failed or misaligned authentication, spam complaints above the 0.1–0.3% ceiling, spammy content, or missing PTR/HELO hygiene. Diagnose in that order:

1. Check your sending IP and domain against 20+ DNSBLs with the free blacklist checker. Listed? Work through the blacklist removal playbook before anything else.
2. Verify SPF, DKIM, and DMARC are passing and aligned — our explainer on SPF, DKIM, and DMARC covers what "aligned" actually means.
3. Paste the full bounce into the header analyzer to read the Authentication-Results and see the exact hop where delivery died.
4. Check Google Postmaster Tools for domain reputation and complaint rate.
5. If you send more than ~5,000 messages a day, audit yourself against the Gmail and Yahoo bulk sender rules.

Two don'ts: never retry 554s blindly (the condition won't self-heal), and don't suppress the addresses — the recipients are fine; your mail stream is the problem. Suppression here just burns good contacts while the root cause stays broken.

Other SMTP codes you'll see in bounce logs

• 421 — "Service not available." You're being rate-limited or the receiver is shedding load; 421 4.7.0 [TS01] ... temporarily deferred is Yahoo throttling you on reputation. The 421 vs 550 question comes up constantly: retry 421 with backoff, never retry 550.
• 450 / 451 — greylisting and receiver-side errors. 450 4.7.1 try again later is classic greylisting; a properly configured MTA retries in 15–30 minutes and the mail goes through. 451 means the receiver's own processing failed — genuinely not your problem, just retry.
• 503 — bad sequence of commands. Your client sent commands out of order: RCPT before MAIL, or DATA before authenticating when the server demands AUTH first. This is a bug in your sending code, not a reputation issue — fix the client, not the list.
• 550 5.7.25 / 5.7.26 / 5.7.515 — the new enforcement codes from the section above. Worth grepping for specifically in 2026 logs; they pinpoint exactly which compliance requirement you failed.

Turn bounce codes into suppression logic

Bounce text varies wildly between providers, so parse the enhanced code, not the prose. A minimal classifier:

def classify_bounce(smtp_code: int, enhanced: str = "") -> str:
    if 400 <= smtp_code < 500:
        return "retry"          # exponential backoff; give up after ~72h
    if enhanced.startswith("5.1."):
        return "suppress_now"   # bad address — remove everywhere
    if enhanced == "5.2.2":
        return "watch"          # full mailbox: suppress after 3 in 30 days
    if enhanced.startswith(("5.3.", "5.7.")):
        return "fix_stream"     # size/policy: fix the cause, keep the address
    return "investigate"        # bare 554s land here

The rules that matter: 5.1.x → immediate suppression; 4xx → retry up to ~72 hours; 5.7.x → stop the stream, not the list. Run every bounce through the same bucket logic from our bounce categories and handling guide and your hard-bounce rate stays under provider thresholds on its own.

If you want to see which of these codes your infrastructure triggers before a campaign does, send a probe through the WillItInbox deliverability tester — 70+ checks across authentication, DNS, headers, and content in about 15 seconds. And when 554s spike across an entire domain, the incident root-cause workbench correlates bounce codes with auth drift and reputation data, so you're debugging from evidence instead of raw SMTP logs.