SMTP Bounce Codes Explained: Every 4xx and 5xx Response You'll See

The Two Families of Bounces: 4xx (Temporary) vs 5xx (Permanent)

SMTP status codes follow a strict three-digit structure: the first digit identifies the family. 4xx codes are transient — a temporary issue you should retry, usually with backoff. 5xx codes are permanent — a hard bounce that will never succeed, regardless of how many times you retry.

In practice, what matters is whether retrying is safe and whether the recipient should ever see mail from you again. A 421 throttling code is fine to retry two hours later; a 550 5.1.1 (recipient does not exist) means the recipient is gone forever. Two further digits follow the family digit:X.Y.Z, where Y identifies the category (mailbox, policy, authentication) and Z is a specific sub-reason.

One trap: soft and hard bounce are operator terms, not standards-defined. Most ESPs label any 4xx as a "soft bounce" (retry) and any 5xx as a "hard bounce" (strip), but the right action per code varies. 421 4.3.2 is safe to retry indefinitely; 421 4.7.28 should be treated as a hard pause on volume. For all 4xx codes, warm-up pacing → typically resolves the underlying issue faster than retrying the same recipient.

Common 5xx Codes — What They Mean and What To Do

Five-by-five (5xx) codes are permanent rejects. Your sending system should record what type of 5xx it received and act accordingly — most should result in the recipient being removed from active lists within a single sending cycle.

• 550 5.1.1The recipient mailbox does not exist on this server.

  Action: Hard bounce. Strip the recipient from active sends immediately.

• 550 5.7.1Message rejected as spam or due to missing authentication.

  Action: Pause the sending IP, review the message content, and re-authenticate the domain.

• 550 5.7.606Microsoft: Mail cannot be sent because it contains a blocked URL.

  Action: Audit every link in the message body. Remove any URL flagged by Microsoft.

• 554 5.7.1Recipient server rejected the message — typically policy or reputation.

  Action: Check your domain and IP reputation. Review recent complaint rates.

• 521 5.2.1Recipient mailbox disabled — formerly active, now closed.

  Action: Hard bounce. The address is gone.

• 523 5.2.1Sending MTA blocked at this domain — IP / domain is denied.

  Action: Confirm you are not blocklisted. Wait out the block or contact the receiving admin.

• 530 5.7.0Authentication required and missing on the sending side.

  Action: Check that your SMTP client issues STARTTLS or AUTH before transmission.

• 552 5.2.2Mailbox full — recipient inbox is over quota and accepting no new mail.

  Action: Treat as a transient hard bounce on most providers (Microsoft hard-bounces 552 after 30 days).

On any 5.7.x code (517–5.7.999), the issue is almost always on the sender side — the message is being refused for content, authentication, or reputation reasons. These stop being "the recipient's fault" and start being "your sending reputation is dropping." Pause the campaign and check your authentication.

Common 4xx Codes — Retry, Throttle, or Stop

Four-by-four (4xx) codes describe transient failures. The retry policy on each one is the operator's decision, and the right policy varies by code. A blanket "retry-all-4xx-for-3-days" rule will mask a 421 throttling signal from Microsoft and cost you weeks of inbox placement.

• 421 4.7.28Microsoft: Our IP has been rate-limited due to poor reputation.

  Action: Reduce send volume immediately. Re-pace the queue and check Postmaster/SNDS data.

• 421 4.3.2Recipient server temporarily busy or under maintenance.

  Action: Retry with exponential backoff. Auto-suppress after 5 failed retries over 72 hours.

• 450 4.2.1Mailbox temporarily unavailable — usually greylisting or throttling.

  Action: Retry in 5–15 minutes. Greylisting typically resolves on the second attempt.

• 452 4.2.2Mailbox full or over quota.

  Action: Retry for up to 7 days. Suppress only if the recipient has not freed space by then.

• 451 4.7.5AMIS: Message rejected due to content or reputation policy.

  Action: Audit the message and check your IP reputation. Retry is rarely productive.

• 471Microsoft: IP is in a deny-list block.

  Action: Do not retry. Resolve via SNDS / Outlook postmaster or delist with Microsoft.

Reading Microsoft vs Google vs Yahoo Bounce Wording

The same 4xx/5xx code can mean slightly different things across providers, mostly because of how they encode policy in the trailing digits. A typical parsed bounce log line looks like this:

Remote Server returned "550 5.7.606 Mail cannot be sent because it contains a blocked URL."

Microsoft uses the second and third digits aggressively — codes like 5.7.501 and 5.7.606 are Microsoft-specific sub-categories you'll never see on Google. They also use the literal phrase 'blocked at request of' or 'due to content policy violation' to communicate recipient-server policy.

Google 5.7.x reasons almost always relate to authentication — 5.7.1 means "SPF / DKIM / DMARC failure," and 5.7.10 is the specific Gmail-rate-limit code. Bounces at Google almost always lead back to SPF, DKIM, and DMARC → setup. If your DMARC report shows alignment failures on the DKIM side specifically, jump to How to Fix DMARC Failing →.

Yahoo typically returns a smaller family of codes (550, 554, 421) without the sub-category detail. When Yahoo returns 421 it's almost always back-pressure from hard throttling — the right move is to back off on volume rather than retry.

A 5xx string with the phrase "block listed," "deny listed," or "blocked at request" is almost always a separate path from a normal SMTP bounce — your sending IP is on an external list. Confirm the situation at Am I Blacklisted? → before doing anything else, since retries will not help.

When Bounces Aren't Bounces: Feedback Loops vs SNDS Complaints

Two adjacent notification channels frequently get confused with SMTP bounces but behave completely differently. Feedback loops (FBLs) are complaint notifications — a recipient hit "Report spam" in their webmail client, and the provider is informing you. They aren't rejections; they are signals that the recipient didn't unsubscribe the way you intended. Every FBL you receive should result in the recipient being suppressed, not unsubscribed — they don't want more mail even in fewer categories.

SNDS complaints are Microsoft's aggregate complaint-rate signal, published daily through the SNDS dashboard. They aren't per-message — they're a 24-hour roll-up. A SNDS complaint rate above 0.3% silently caps your future delivery rate; you should monitor it alongside any per-account bounce data.

The Mechanical Cleanup: Removing Hard-Bounced Recipients Fast

Every 5.1.1, 5.7.1, and 5.2.1 is a signal that the recipient is permanently gone. The mechanical job is to remove them from your active list before the next send, ideally within 60 seconds if you're sending through an automated ESP. Hard bounces left in the active list pollute open rates, drag your domain reputation, and are the single biggest driver of "list-hygiene" complaints from Gmail.

For high-volume senders, the cleanup should also remove:

• Recipients on inactivity lists for 90+ days, regardless of bounce history — they will hurt you on list hygiene even with a clean auth stack.
• Recipients who hit the spam button instead of "unsubscribe" — FBL hits, as covered above.
• Single-opt-in confirmed recipients who never engage within 30 days of signup — they are a soft signal, but in aggregate they pull reputation down.

Doing this cleanup manually is the most boring part of high-volume sending. Done automatically after every bounce event, it disappears as a problem. For the broader playbook on list hygiene and engagement signals, see Cold Email Deliverability →.