SMTP 522, 523, 531, 532, 540, 542, 556: which of these are real

Before working through these one by one: most of them are not real SMTP reply codes. RFC 5321

defines a specific set of replies, and 522, 531, 532, 540 and 542 are not among them. They appear

in dozens of "complete SMTP error code" tables that have been copied from each other for twenty

years, and no mainstream MTA - Postfix, Exim, Sendmail, Exchange, Gmail, Microsoft 365 - emits

them. If you believe you received one, you almost certainly received something adjacent, and the

real code is what you need to search for.

Two of the seven are genuinely worth a section: 523 appears on some systems for message size,

and 556 is a real, registered, modern code.

The honest table

556 5.1.10: the one that is real and current

556 was added for a specific, modern situation. RFC 7505 defines the "null MX" record - a single

MX with priority 0 and a target of . - which is how a domain states that it accepts no mail at

all. Many organisations publish it on domains used only for web or for sending, to stop

backscatter and to make bounces immediate instead of waiting out a retry timeout.

$ dig MX send.example.com +short
0 .

550 5.1.10 RESOLVER.ADR.RecipientNotFound; Recipient address lookup failed
556 5.1.10 Requested action not taken: domain does not accept mail

If you get this, the address is permanently undeliverable and should be suppressed - but notice

the cause. It is not a typo and not a closed mailbox; the domain owner has declared the domain

non-receiving. Check that you have the right domain: send.example.com and example.com are

frequently split exactly this way, with the sending subdomain publishing a null MX.

523 and the real size limits

Message size rejections are real and common; the code usually is not 523. What you will see is

552 5.3.4 Message size exceeds fixed maximum message size or, when the server advertises SIZE

in its EHLO response, an outright refusal at MAIL FROM:

MAIL FROM:<sender@yourdomain.com> SIZE=41943040
552 5.3.4 Message size exceeds fixed limit

The limits that matter in practice:

The trap is base64. MIME encoding inflates binary attachments by roughly a third, so a 20 MB file

becomes about 27 MB on the wire and is refused by a 25 MB limit that looked like plenty. Size

your attachments against the encoded size, not the file size - or send a link.

522 and recipient counts

For too many recipients in one transaction, the real codes are 452 4.5.3 (transient - split the

message and retry) and 552 5.5.3 (permanent). The transient form is the common one, and it

matters that it is a 4xx: the correct response is to break the recipient list into smaller

batches and resend, not to suppress anybody.

Recipient caps are also enforced per message by sending providers rather than per transaction by

receivers, and those are the limits most senders actually hit. Note that providers generally count

quota per *recipient*, so one message to thirty people consumes thirty of your daily allowance.

531, 532, 540, 542

• 531 is listed as "authentication required" or "mail system full" depending on which copied

table you land on - two completely different conditions, which is a good sign the code is

folklore. The real authentication-required reply is 530, with 5.7.0 as the registered

enhanced code.

• 532 tends to be listed as a storage condition. The real one is `452 4.3.1 Insufficient

system storage`, and it is transient: retry it.

• 540 is listed as "no DNS server for the recipient domain". The real replies are `550 5.1.2

Host unknown when the domain genuinely does not resolve, and 450 4.1.2` when resolution failed

temporarily. The difference decides whether you suppress the address or retry it, so it is worth

reading carefully.

• 542 is listed as a rejected recipient. The real replies are 550 5.1.1 for an unknown

mailbox and 550 5.4.1 Recipient address rejected: Access denied on Microsoft 365, which

returns the same string for a nonexistent mailbox and a blocked one so that address harvesting

does not work.

The ordered fix for any unfamiliar code

1. Get the raw reply, not a summary. Look in the delivery status notification's

Diagnostic-Code: field, or in your MTA log. A wrapper library's paraphrase is where invented

codes come from.

1. Read the first digit. 4xx means retry the same message later. 5xx means stop. This

decision never depends on the enhanced code.

1. Read the enhanced code's subject digit. .1 addressing, .2 mailbox, .3 mail system,

.4 network and routing, .5 protocol, .6 content, .7 policy and security.

1. Act on the subject digit, not the headline. .1 justifies suppressing an address. .7

never does - it is a judgement about you.

1. Check the registry if you are unsure. RFC 5248 maintains the official enhanced status code

list. If a code is not there and no major MTA source contains the string, it is not a code you

need to handle.

What not to do

• Do not write bounce-handling rules against codes from copied tables. You will build branches

that never execute while the codes you really receive fall through to a default.

• Do not suppress addresses on `4xx` replies such as 452 4.5.3 or 452 4.3.1. Those are

instructions to retry.

• Do not raise a support ticket quoting a code you did not actually receive. Paste the full

Diagnostic-Code: line instead; it names the rejecting host as well as the reason.

• Do not treat a null MX rejection as a bad list. The data may be perfectly accurate and the

domain simply does not receive mail - check whether a parent domain does.

MailPilot's own classifier matches on the raw provider string rather than on the numeric code

alone, because the same number means different things at different providers. Per-provider inbox

placement from a seed-inbox network, plus daily per-mailbox reputation, gives you the comparison

that tells you whether a rejection is about one receiver's policy or about your domain.