SMTP reply codes and enhanced status codes, explained properly

An SMTP reply is three digits plus optional text, and an enhanced status code is three

dot-separated numbers inside that text. Together they answer exactly two questions: **should this

message be retried, and whose problem is it?** Every other use of these codes is decoration.

The retry answer comes from the first digit of the reply. The fault answer comes from the middle

number of the enhanced code. If you remember nothing else, remember those two positions.

Reply code structure

RFC 5321 defines the first digit as the outcome class and the second as a broad category.

There is no 1xx class in SMTP. Tables that list "1XX - informational responses" have borrowed

the row from HTTP. SMTP has no informational replies, and no server will ever send one.

The 3xx class has exactly two members in normal use: 354 Start mail input after DATA, and

334 as the base64 challenge during AUTH. Tables describing 3xx as "persistent transient

negative completion" have mangled the RFC's own wording, which applies that phrase to 4xx.

The replies you will actually see

Success and intermediate:

Transient failures - retry these:

Permanent failures - do not retry:

Enhanced status codes, digit by digit

RFC 3463 defines the format as class.subject.detail, and RFC 5248 maintains the registry of

assigned values.

The class repeats the reply class: 2 success, 4 transient, 5 permanent. If the class

digit and the reply's first digit disagree, trust the reply - the enhanced code is often copied

inconsistently between server versions.

The subject is the part worth learning, because it tells you who owns the problem:

So 5.1.1 is a permanent addressing failure: the address is dead, suppress it. 5.7.1 is a

permanent policy failure: the address is fine and something about your sending is not. Those two

get conflated constantly, and conflating them is how senders end up with suppression lists full of

valid contacts and an unfixed reputation problem.

Turning codes into a working policy

1. Branch on the reply's first digit first. 4xx queues, 5xx stops. Nothing else.
2. For `5xx`, branch on the subject digit. Only .1 and the null-MX 5.1.10 justify

suppression.

1. Give `4xx` a retry schedule with a ceiling. Retry frequently for the first hours, then back

off, and give up after four to five days. Then record a bounce.

1. Treat `.7` as an alarm, not a bounce. Count .7 rejections per receiving provider. A rise

at one provider is a policy change or a reputation slide you can still fix.

1. Keep the raw string. Store the full Diagnostic-Code: text, not just the number. Providers

put the actionable detail - a block reference, a help URL, a bracketed internal code - in the

text.

What not to do

• Do not key your logic on the enhanced code alone. Plenty of servers send mismatched pairs,

such as 530 5.7.1 where the registry says 5.7.0.

• Do not collapse `4xx` and `5xx` into one "bounce" counter. They demand opposite actions.
• Do not suppress on `.7`. You will burn good contacts and leave the real cause in place.
• Do not retry a `5xx` because the text sounds temporary. "Try again later" inside a 550 is

boilerplate; the class digit is the contract.

MailPilot acts on this distinction rather than averaging it away: it tracks per-mailbox reputation

daily, measures inbox placement per provider with a seed-inbox network, and checks SPF, DKIM and

DMARC - so when .7 rejections start appearing you can see immediately whether authentication or

reputation is the cause.