SMTP Error Codes Explained: 4xx and 5xx Bounce Codes and How to Fix Them

Every rejected email comes back with a code. Most people glance at "550" or "421", decide the email failed, and move on - and in doing so throw away the single most useful diagnostic email has. An SMTP reply is the receiving server telling you, in a structured way, exactly why it did or did not accept your message and whether it is worth trying again.

This is a plain-English reference to the SMTP error codes you actually meet: how to read any SMTP reply, what the standard 4xx and 5xx codes mean, the signature rejection codes used by Gmail, Microsoft, Yahoo, Zoho, Fastmail and Apple iCloud, and a fix playbook grouped by root cause. Where a code is documented by the provider we say so; where a code is only ever seen in real bounce logs and is not in the provider's own documentation, we say that too, because guessing at a code's meaning is how senders waste days chasing the wrong fix.

Quick lookup: the codes people search for

The most-searched codes at a glance - each links to its detailed section below. As always, read the diagnostic text the server actually returned; the same number can carry different reasons.

How to read an SMTP reply code

A modern SMTP rejection carries two codes and a human message. Learn to see all three and most bounces become self-explanatory:

550 5.7.26 This email has been blocked because the sender is
    unauthenticated. Gmail requires all senders to authenticate
    with either SPF or DKIM. ... gsmtp
↑   ↑     ↑                                      ↑
basic  enhanced  human-readable reason                  server tag

• The basic reply code (three digits, e.g. 550) comes from RFC 5321. The first digit is all you need for triage: 2xx = accepted, 4xx = temporary failure (try again), 5xx = permanent failure (do not retry).
• The enhanced status code (three numbers, e.g. 5.7.26) comes from RFC 3463 and pinpoints the reason. It reads class.subject.detail - more on this below.
• The human-readable text is where the receiver tells you what actually happened. Two providers can return the same 550 5.7.1 for completely different reasons, so the text is not optional reading.
• A server tag often trails the line - Gmail appends gsmtp (or gcdp when an admin's custom rule caused the block), Yahoo and Apple append a hostname. It identifies the server, it is not part of the code.

Synchronous vs asynchronous bounces

There is a second axis to every bounce: when you find out. It decides where the rejection even shows up.

• Synchronous - the receiver returns the code during the live SMTP conversation, before it ever accepts the message, so your sending server sees it immediately in your outbound mail logs. Most rejections in this guide arrive this way.
• Asynchronous - the receiver answers 250 OK and accepts the message, then discovers later that it cannot deliver and sends a separate bounce - a Non-Delivery Report (NDR / DSN) - back to your Return-Path. It arrives as a new email minutes to days later, with the same enhanced status code quoted inside it.

The important part: this is about timing, not a different set of codes. The very same 550 5.1.1 can come back synchronously (the gateway knew the recipient was invalid at RCPT time) or asynchronously (it accepted the message first and only found the mailbox missing afterwards). As a rule of thumb, connection, authentication and reputation blocks tend to be synchronous, while mailbox-full, unknown-user-behind-a-gateway and post-acceptance content filtering tend to come back asynchronously as a DSN - but you read the code the same way in both.

4xx vs 5xx: the one rule that matters

If you remember nothing else, remember this:

The trap is a persistent 4xx. A single 4xx is harmless. But when a receiver returns the same 421 deferral to every attempt for two days, it is refusing you politely - treating it as "temporary" and retrying harder makes things worse. Persistent 4xx = a reputation or rate problem to fix, not wait out.

The standard 4xx codes (temporary)

Greylisting deserves a note because it alarms people needlessly: some receivers deliberately return a 4xx to the first delivery attempt from an unknown server and accept the retry a few minutes later. It is an anti-spam tactic, not a problem with your mail - a properly configured server just retries and delivers. Fastmail documents doing exactly this, and even adds an X-Spam-greylist header telling you how long the message was delayed.

The standard 5xx codes (permanent)

Enhanced status codes: the X.Y.Z that actually tells you what broke

The basic code tells you retry-or-not. The enhanced code tells you why. It is class.subject.detail:

• Class (first digit): 2 success, 4 temporary, 5 permanent - it mirrors the basic code's first digit.
• Subject (second digit) is the useful part: .1 addressing, .2 mailbox, .3 mail system, .4 network/routing, .5 protocol, .6 media/content, .7 security/policy.
• Detail (third digit) is the specific condition, and its meaning depends on the subject - the same detail number means different things under different subjects, so read it as part of the whole code (see the table below for the ones you will actually meet).

A .7 in the middle almost always means the block is about you - authentication, reputation or policy - which is the good news, because those are the ones you can fix. The codes below span three layers: the base subjects from RFC 3463, the standard authentication codes added in RFC 7372 (e.g. X.7.25, X.7.26), and higher detail numbers that are provider extensions (e.g. Gmail's 5.7.28 and 5.7.40, in the provider tables further down). Here are the ones you will actually meet:

Provider-specific codes

This is where the standard tables stop being enough. Each major mailbox provider layers its own reason strings on top of the standard codes, and knowing the signature ones tells you the exact fix. The strings below are quoted from real bounces; we note which are documented by the provider and which are only observed in the wild.

Gmail and Google Workspace

Google publishes a full SMTP error reference, and it is unusually systematic: most 2024 bulk-sender rules exist as a matched pair - a 4xx deferral that throttles you first, and a 5xx block for repeat offenders. Gmail appends gsmtp to its error messages; errors caused by a Google Workspace administrator's custom rule can instead show gcdp.

Microsoft (Outlook.com and Microsoft 365)

Microsoft is really two systems: consumer Outlook.com / Hotmail and business Microsoft 365 (Exchange Online Protection), with separate block lists and delisting paths. The codes below are from Microsoft's official NDR reference unless noted.

Yahoo and AOL

Yahoo (which also runs AOL) documents its errors by category rather than a numbered table: temporary errors are 421/451, permanent are 553/554, and it names two tag families, TS* for reputation deferrals and PH* for content/malware blocks. The specific sub-tags below (TSS04, TS01-TS04) are seen constantly in real logs but are not individually defined by Yahoo - their meanings are inferred by email providers and vary, so use them as a signal, not gospel.

421 4.7.0 [TSS04] Messages from 4.16.55.1 temporarily deferred
    due to unexpected volume or user complaints;
    see https://postmaster.yahooinc.com/error-codes

Yahoo's 2024 bulk-sender rules (authenticate with SPF and DKIM, publish DMARC, one-click unsubscribe, low complaints) are enforced through these same codes: complaint and reputation failures surface as TS* deferrals, and authentication or policy failures as 554 5.7.9.

Zoho Mail

Zoho tends to wrap its rejections in a 5.7.1 enhanced code with a descriptive reason, and (unlike most providers) tags its outbound rate limit with a 5xx code even though it behaves like a throttle. The strings below are verbatim from Zoho's help community.

Note: a widely repeated claim that Zoho uses 554 5.7.5 for spam is wrong - the real spam code is 554 5.7.1. Setting Zoho up cleanly is largely an authentication exercise; our Zoho SPF, DKIM and DMARC guides walk it end to end.

Fastmail

Fastmail is the outlier, and it is worth understanding why: it deliberately does almost no content-based rejection at SMTP time. Per Fastmail's own documentation, SPF, DKIM, DMARC and content scoring only adjust the spam score and file to the Spam folder - they do not bounce the message, even for a domain publishing p=reject (which Fastmail treats as a high-scored quarantine, not an SMTP rejection). So there are very few Fastmail rejection codes to learn.

Fastmail also rate-limits sending hosts and blocks address-enumeration and RFC-violating spambots at the envelope stage. Fastmail does not publish a full numeric code for the Spamhaus block or greylisting - so if you see a bounce claiming a specific "Fastmail 550" for a spam-content reason, be sceptical; that is not how Fastmail behaves.

Apple iCloud Mail

Apple documents the least of any provider: its postmaster page lists requirements but no codes and no bracket tags at all. The bracketed tags below ([CS01], [HM07], [HM08]) are real and appear in live bounces, but they are undocumented by Apple - known only from mail logs - so treat them as "reputation/policy, slow down and clean up" signals rather than precise diagnoses.

550 5.7.1 [CS01] Message rejected due to local policy.
    Please visit https://support.apple.com/en-us/HT204137

Apple runs no feedback loop and no allow list, so with iCloud "local policy" rejections you cannot get a complaint report - the only route is to get your authentication, reputation and list hygiene right, then escalate with logs.

Other systems: gateways and blocklists

A lot of mail is filtered not by the mailbox provider but by a security gateway sitting in front of it, or rejected because of a blocklist. You will meet their codes too - here are the official references to keep on hand:

• Barracuda (Email Security Gateway / Email Gateway Defense) - SMTP error codes reference.
• Mimecast - SMTP error codes (and their rejected-and-deferred message reasons).
• Spamhaus - the blocklist behind many of the rejections above (Fastmail, Yahoo and Apple all cite it). Use the IP and domain reputation checker to see a listing and request removal.

Fix playbooks by root cause

Nearly every 5xx block above collapses into one of four root causes. Fix the cause, not the code.

When the code says the problem is not you

Not every bounce is yours to fix. Addressing and mailbox errors - 5.1.1 user unknown, 5.2.2 mailbox full, 5.2.1 mailbox disabled, 5.1.10 null MX - are the recipient's address being wrong, full or closed. There is no sender-side fix beyond removing the address. Likewise a genuine 4.4.x routing error or a one-off 421 during a provider's incident will clear on its own. The codes worth your energy are the 5.7.x security-and-policy family, because those are the ones that are about your authentication, reputation or content - and those you can actually fix.

Bookmark this page as a decoder: read the basic code to know whether to retry, read the enhanced code's middle digit to know the department, read the provider table to know the exact fix. An SMTP rejection is not a dead end - it is the most precise instruction email ever gives you.