SMTP Error Codes List: Diagnose Bounces by Code

Every time a mail server speaks, it leads with a number. That number is not decoration, it is a machine-readable verdict on the fate of your message. Understanding the SMTP error codes list in full is what separates engineers who fix delivery failures in minutes from those who spend hours reading unhelpful bounce text. This reference groups every operationally significant code by class, explains what it signals about MTA state, and pairs it with a concrete next action.

How SMTP Response Codes Work

Anatomy of an SMTP Server Response

The SMTP response code format is defined in RFC 5321 (the core SMTP specification) and extended by RFC 3463, which introduced the enhanced status code in X.Y.Z notation. Every legitimate MTA in production today is expected to honour both.

A response looks like this:

550 5.1.1 The email account that you tried to reach does not exist.

Break it into three parts:

• First digit (class): 2 = success, 4 = transient failure, 5 = permanent failure.
• Second digit (subject): Broad category, 0 = syntax, 1 = information, 2 = connections, 3 = unspecified, 4 = network, 5 = mail system.
• Third digit (detail): Specific condition within that subject.

The enhanced code X.Y.Z follows the same logic at higher resolution. 5.1.1 means permanent failure (5), addressing (1), bad destination mailbox address (1).

Why the First Digit Is All That Matters First

Per RFC 5321 §4.2.1, the human-readable text that follows an SMTP status code is non-normative. Receiving systems word it however they like, and many do. Engineers who diagnose bounces by reading the banner text rather than the numeric code will mis-triage failures repeatedly. The number is the contract; the words are a suggestion.

Read the first digit. Act on it. Then use the enhanced sub-code to narrow the cause.

4xx vs 5xx SMTP: Soft Bounce vs Hard Bounce

What a 4xx Transient Failure Tells You

A 4xx response means the remote MTA is saying: not now, but try again later. This is a soft bounce. The message stays in the sending MTA's retry queue, and delivery attempts continue on a back-off schedule, typically hourly for the first few hours, then tapering over days until the queue expiration timeout fires (commonly 4–5 days).

The key operational implication: do not suppress the recipient address on a 4xx. The failure is transient by definition. Suppressing after a single soft bounce discards mail that would have delivered on the next retry.

What a 5xx Permanent Failure Tells You

A 5xx response means the remote MTA has made a final decision: this message will never be accepted. This is a hard bounce. The sending MTA discards the message immediately and generates a Delivery Status Notification (DSN) to the envelope sender.

Suppress the recipient address immediately. Continuing to send to addresses that return 5xx tells receiving MTAs that you ignore their rejections, a behaviour pattern associated with spam senders. Ignoring 5xx suppression is one of the fastest ways to destroy sender reputation with major mailbox providers.

SMTP Error Codes List: 4xx Transient Failures

SMTP 421 Error: Service Temporarily Unavailable

Code: 421 / Enhanced: 4.3.2, 4.4.5 MTA state: The receiving service is closing the connection or refusing new ones. Common causes:

• Server overload or maintenance window
• Rate limiting: the receiving MTA is throttling your sending IP
• The remote MX is temporarily offline

Next action: Your MTA will retry automatically. If 421 persists across multiple retry cycles over several hours, escalate from "transient load event" to "configuration problem." Check whether your sending IP is on the receiving domain's rate-limit list, whether you are sending large bursts that trigger connection throttling, and whether the remote MX has a published maintenance window. A 421 4.4.5 specifically signals that the remote server's resources are insufficient, consider reducing concurrency.

Code: 450 MTA state: Requested mailbox action not taken, mailbox temporarily unavailable. Common cause: Mailbox lock, disk quota approaching limit, or temporary server-side filter hold. Next action: Retry automatically. If 450 persists for a single address across many retries, investigate whether the mailbox is permanently over quota (some servers downgrade what should be a 552 to a 450).

SMTP 451 Error: Local Processing Error or Greylisting

Code: 451 / Enhanced: 4.7.1 (greylisting), 4.3.5 (system configuration error) MTA state: The server encountered a local error while processing the message. Common causes:

• Greylisting: The most operationally common cause. Greylisting implementations, standardised in RFC 6647, return a 451 4.7.1 on first contact from an unknown sending IP, then accept the message after a configurable delay, commonly 5–15 minutes, on retry. Legitimate MTAs retry; spam sources typically do not.
• Upstream DNS failure: The receiving MTA could not resolve something it needed to process the message.
• Content filter deferral: A virus scanner or policy engine timed out.

Distinguishing greylisting from genuine failure: If the same IP successfully delivers to other mailboxes at the same domain, the 451 is almost certainly greylisting. If delivery fails across all addresses at a domain, suspect an upstream processing failure. Check the enhanced sub-code: 4.7.1 is the conventional greylisting signal; 4.3.5 points to a server misconfiguration on the receiving side.

Next action: For greylisting, wait for the retry. For 4.3.5, the fault is on the remote side, no action needed beyond monitoring. For persistent 451 with DNS-related text in the banner, verify your sending domain's PTR record and confirm your HELO/EHLO hostname is valid and forward-confirmed.

Code: 452 / Enhanced: 4.5.3 MTA state: Insufficient system storage, or too many recipients in the envelope. Common cause: Remote disk full, or envelope recipient count exceeds the server's per-transaction limit. Next action: For storage errors, retry later. For recipient count errors, split large recipient batches into smaller transactions.

Code: 455 MTA state: Server unable to accommodate parameters. Common cause: An ESMTP extension parameter (such as SIZE) was rejected. Next action: Check message size against the remote server's advertised SIZE limit in its EHLO response.

SMTP Error Codes List: 5xx Permanent Failures

SMTP 550 Error: Mailbox or Policy Rejection

The 550 is the most common permanent failure code, and its enhanced sub-code changes the troubleshooting path entirely.

550 5.1.1 is unambiguous: the address does not exist. Suppress it.

550 5.7.1 is where diagnosis branches. A 5.7.1 from Gmail's MX servers typically signals that the sending IP failed a policy check, most commonly a missing or failing SPF record, a DKIM signature that did not verify, or a DMARC p=reject policy in force on the sender domain. The human-readable text in the SMTP banner varies between providers, but the sub-code is consistent across compliant implementations. Understanding how SPF, DKIM, and DMARC authentication works is essential before diagnosing this class of rejection.

Code: 551 MTA state: User not local; forwarding refused. Common cause: The address exists at the receiving MTA but is not local, and the server will not relay. Next action: Use the forwarding address the server provides in the response text, or remove the address.

Code: 552 / Enhanced: 5.2.2, 5.2.3 MTA state: Exceeded storage allocation, or message too large. Common cause: Recipient mailbox full (5.2.2) or message exceeds server's size limit (5.2.3). Next action: For 5.2.2, suppress temporarily (some MTAs send 452 instead; check behaviour). For 5.2.3, reduce message size.

Code: 553 MTA state: Mailbox name not allowed. Common cause: Address syntax violates the receiving server's local policy. Next action: Validate address syntax. Remove if invalid.

Code: 554 / Enhanced: 5.7.1, 5.7.0 MTA state: Transaction failed, often a reputation or content policy block. Common cause: Sending IP is on a blocklist, message failed content policy, or the connection itself was rejected. Next action: Check your sending IP against major blocklists (Spamhaus ZEN, Barracuda, SORBS). If listed, follow the delisting process for each registry. If not listed, review message content and sending infrastructure.

NDR Codes Email: 5xx Variants That Signal Authentication and Reputation Blocks

Authentication failures produce 5xx codes with recognisable sub-codes:

• 550 5.7.23 (Microsoft): SPF record does not designate the sending IP as permitted.
• 550 5.7.26 (Microsoft): Message failed DMARC because the sending domain has a p=reject policy and the message did not align on SPF or DKIM.
• 550 5.7.1 (Gmail): Catch-all for policy rejection, inspect the banner text for specific mentions of SPF, DKIM, or DMARC.
• 421 4.7.0 / 550 5.7.0: Used by some providers for reputation-based connection refusals, often before envelope commands are even exchanged.

The pattern is consistent: the first digit tells you permanent vs transient, the 5.7.x subject-and-detail range signals a security or policy failure. Authentication failures are always in the 5.7.x range when providers follow RFC 3463 conventions. Where they diverge, the banner text is a secondary signal, advisory, not authoritative.

Reading SMTP Bounce Codes Inside Email Headers

When delivery fails, the remote MTA returns an SMTP response code in the session. That code surfaces in two places you can inspect after the fact.

1. The DSN (Delivery Status Notification)

The DSN format is standardised in RFC 3464, which requires receiving MTAs to populate:

• Status: field, the enhanced status code (5.1.1, 5.7.1, etc.)
• Diagnostic-Code: field, the full SMTP response text, prefixed with smtp;

Raw DSN inspection is the fastest way to identify which MTA in the chain rejected a message. The Diagnostic-Code line will look like:

Diagnostic-Code: smtp; 550 5.7.1 [IP] Our system has detected that this
    message is likely unsolicited mail.

2. The Received chain and Action field

Correlate the Final-Recipient and Action: failed fields in the DSN with the timestamp on the last Received header in the original message. The gap between the last successful Received hop and the bounce timestamp identifies which MTA rejected the message.

For diagnosing delivery failures from raw email headers, the Received chain is your primary evidence trail. Match the rejecting server's hostname in the Diagnostic-Code against the Received chain to confirm which hop failed and whether the failure was at the first MX, a secondary MX, or a downstream filter.

If you need to reconstruct the full delivery path and header forensics, parse every Received header from bottom (origin) to top (destination) and note the timestamp delta at each hop.

SMTP Error Troubleshooting Playbook

Match your symptom to a category, then follow the steps in order.

Category 1: Rate limiting (421, 452)

1. Check your sending volume over the last 24 hours against the receiving domain's published limits (where available, Gmail Postmaster Tools publishes reputation data).
2. Reduce connection concurrency and message-per-connection rates to the affected domain.
3. Implement exponential back-off on retries for that domain specifically.
4. If 421 persists beyond 24 hours of reduced volume, check whether your IP is in an active rate-limit pool by sending a test message via a different IP.

Category 2: Authentication failure (550 5.7.1, 550 5.7.23, 550 5.7.26)

1. Run your sending domain through an SPF validator. Confirm your sending IP is within the include: chain.
2. Check DKIM: verify the signing key is published in DNS and that your MTA is signing outbound mail with the correct selector.
3. Check your DMARC record. If p=reject, confirm that either SPF or DKIM aligns with the From: domain, not just the envelope domain.
4. Pull the Authentication-Results header from a received copy of the message (use a seed address at the receiving domain) to confirm which check is failing.

Category 3: Reputation block (554 5.7.1, 550 5.7.0)

1. Check your sending IP against Spamhaus ZEN, Barracuda Reputation Block List, and Invaluement.
2. If listed, initiate delisting through each registry's published process. Do not relist without fixing the underlying cause.
3. If not listed, check domain reputation at Gmail Postmaster Tools and Microsoft SNDS.
4. Review recent complaint rates. A complaint rate above 0.10% with Gmail triggers reputation-based filtering.

Category 4: Hard address failures (550 5.1.1, 553)

1. Suppress the address immediately from all sending lists.
2. Audit your list acquisition and validation process. High rates of 5.1.1 bounces indicate stale data or no validation at sign-up.
3. Implement an email address validation check at point of collection to catch syntax errors before they become 553 bounces.

Category 5: Remote server error (451 4.3.5, 450)

1. Confirm the failure is isolated to one recipient domain. If so, the fault is on the remote side, monitor and wait.
2. If 451 appears across multiple domains, check your sending MTA's PTR record, HELO/EHLO hostname, and whether your IP has recently changed.
3. For persistent 450, check whether the affected mailboxes share a common characteristic (same domain, same ISP) that suggests a systemic issue upstream.

The diagnostic loop closes when you can trace the code in the DSN back to a specific MTA hop, identify the cause in the authentication or reputation layer, and confirm the fix with a successful delivery. For the authentication layer, the companion reference on how SPF, DKIM, and DMARC authentication works covers every mechanism that generates a 5.7.x rejection. For header-level forensics, the guides on diagnosing delivery failures and full delivery path analysis complete the picture.