SMTP error codes: how to read an email bounce

The two codes in every bounce

A bounce pairs two numbers, for example 550 5.7.26:

• The 550 is the SMTP reply code (RFC 5321), a three-digit transport verdict.
• The 5.7.26 is the enhanced status code (RFC 3463), a structured class.subject.detail classification of why.
• The text after them is the diagnostic, and it is usually what actually tells you the cause.

The first digit is the whole story for retries

The first digit of the SMTP reply code decides what to do:

• 2xx means accepted (the message went through).
• 4xx is a temporary failure. The sending server will retry on its own. Back off and fix any reputation or rate problem, but you usually do not need to resend.
• 5xx is a permanent failure. The spec says do not retry without changing something. Fix the underlying cause, then resend. Retrying an unchanged 5xx just earns the same bounce.

(The 1xx and 3xx codes are mid-conversation replies, not delivery verdicts.)

The enhanced code: class, subject, detail

The dotted code is three parts, class.subject.detail:

• Class mirrors the first digit: 2 success, 4 temporary, 5 permanent.
• Subject is the category of problem:

X.1  addressing (the recipient address)
X.2  mailbox (the recipient's mailbox)
X.3  mail system (the receiving system)
X.4  network or routing
X.5  mail protocol
X.6  message content or media
X.7  security or policy

Email authentication failures live in the X.7 security and policy class, which is why every SPF, DKIM, and DMARC rejection you will see is a 5.7.something.

The number is often ambiguous: read the text

The biggest trap with bounce codes is that the same number is reused for different problems, especially in the 5.7.x security class. Microsoft, for instance, uses 5.7.1 as a catch-all that can mean a permission problem, a blocklist, a transport rule, or a DMARC rejection. The numeric code narrows it down; the diagnostic text after the code is what names the real cause. Always read the words.

In a bounce message (a delivery status notification, RFC 3464), you will find the structured code in the Status: field and the remote server's own words in the Diagnostic-Code: field. The Action: field (failed, delayed, and so on) tells you whether it was a hard bounce or still being retried.

The email-authentication codes, decoded

These are the security and policy (5.7.x) codes you are most likely to land on, and where to go for each:

• 550 5.7.1 (Microsoft): a general “not authorized by policy” rejection; on Microsoft 365 this is often a DMARC rejection (the more specific form is 5.7.509). 550 5.7.1: rejected per DMARC policy.
• 550 5.7.26 (Gmail, also Microsoft): the message was unauthenticated, having failed SPF and DKIM and therefore DMARC. Gmail 550 5.7.26.
• 550 5.7.23 (Microsoft): SPF failed because the sending IP is not authorized by your SPF record. 550 5.7.23: your mail failed SPF.
• 550 5.7.27 (Gmail, bulk): the bulk-sender SPF requirement was not met.
• 550 5.7.30 (Gmail, bulk): the bulk-sender DKIM requirement was not met. DKIM failed.
• 550 5.7.25 (Gmail): the sending IP has no matching reverse DNS (PTR) record. Reverse DNS and PTR records.
• 550 5.7.28 (Gmail): an unusual rate of mail from your IP; you may also see the temporary 4.7.28.
• 554 5.7.9 (Yahoo): message not accepted for policy reasons, typically a DMARC failure. Yahoo 554 5.7.9.

And the SPF misconfiguration that often underlies an SPF failure: SPF PermError: too many DNS lookups.

Frequently asked

What is the difference between a 4xx and a 5xx email error?

A 4xx is temporary: the sending server will retry, so back off and fix any reputation problem. A 5xx is permanent: fix the cause, then resend. Retrying an unchanged 5xx just repeats the bounce.

Why does the same code mean different things?

Because the enhanced status code, especially the 5.7.x security class, is a broad category, and providers reuse it for several causes. The diagnostic text after the code is what identifies the specific problem.

Where is the error code in a bounce message?

In the delivery status notification, the structured code is in the Status:field, and the remote server's own message is in the Diagnostic-Code: field.