SMTP "431" and "432" are not real reply codes

431 and 432 are not SMTP reply codes. No version of Postfix, Exim, Sendmail, Microsoft Exchange, Gmail's receiving infrastructure or Yahoo's mail stack emits either number. The valid 4xx space used in real mail traffic is a short, well-known set - 420, 421, 450, 451, 452, and a handful of vendor-specific extensions - and 431/432 fall outside all of it. If you are looking at a report that cites these numbers, treat the number itself as unreliable and go find the raw log line.

What was probably actually received

The description attached to these codes in most places that mention them - "recipient server storage or queue full" - maps directly onto the real, standard code 452, specifically paired with enhanced status 4.2.2 (mailbox full) or 4.3.1 (insufficient system storage). That is almost certainly what the sending server actually received; "431/432" is a label invented somewhere downstream, most likely by a bounce-categorisation tool that grouped several real codes under made-up bucket numbers for its own internal reporting.

Who is at fault

For the real underlying condition (452, mailbox or queue full), the fault is on the receiving side's capacity, and it is transient - a full mailbox or a queue backlog that clears once space frees up or messages are processed. One more reason to distrust the fabricated numbers specifically: a genuinely non-existent code

cannot have a consistent "correct" fix, because nothing defines what it means. Any advice attached

to "431" or "432" online is, at best, someone's guess at what the real underlying condition was in

whatever specific case they encountered - and that guess may not match your situation at all. The

only way to get advice that actually applies to what your server is doing is to find the real code

behind the label first, every time, rather than trusting a cached explanation from a page that

never checked its own numbering. If

you maintain a shared knowledge base for your team, flag any page referencing these two numbers as

unverified and schedule a correction rather than leaving it for the next person to rediscover the

same dead end.

The exchange (the real reply)

MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
452 4.2.2 Mailbox full

How Gmail, Microsoft 365 and Yahoo word this real condition

Diagnostic commands

Find the raw log entry your tool summarised, rather than trusting its label:

$ grep -B1 -A3 "recipient@example.com" /var/log/maillog | tail -6
to=<recipient@example.com>, relay=mx.example.com[203.0.113.44]:25,
delay=0.9, status=deferred (host mx.example.com said:
452 4.2.2 Mailbox full (in reply to RCPT TO command))

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  452 4.2.2 Mailbox full

The ordered fix

1. Find the raw SMTP transcript behind whatever report shows 431 or 432 - check your MTA's own mail log, not a third-party dashboard's summary field.
2. Confirm the real code is 452 (or occasionally 450) with a mailbox-capacity enhanced status.
3. Let the normal retry schedule run - a full mailbox often clears on its own within a day or two.
4. If it persists for more than a few days, the recipient's mailbox may be abandoned; contact them through another channel before writing off the address.
5. Fix the tool that invented the fake code number so your team stops seeing numbers that do not correspond to anything a server sends.

What not to do

• Do not search for "SMTP 431" or "SMTP 432" documentation. You will not find authoritative sources, because the codes are not real.
• Do not treat this as a hard bounce. The real underlying code, 452, is temporary; removing the address immediately is premature.
• Do not change authentication settings. Mailbox capacity has nothing to do with SPF, DKIM or DMARC.
• Do not keep reporting on the fake bucket numbers internally. Every dashboard that shows 431/432 should be corrected to show the actual reply code, or it will keep producing confusion for whoever reads it next.

Checking your own reporting pipeline for the same bug

If one tool in your stack invented 431 and 432, it is worth auditing every other bounce-processing

or analytics tool touching the same mail stream for the same habit. A quick test: pick five recent

bounce events, trace each back to its raw SMTP log line, and confirm the code your dashboard shows

matches exactly. Any mismatch found this way is worth escalating to whoever maintains that tool,

since a numbering discrepancy discovered once in isolation is rarely isolated in practice.

MailPilot's reputation and deliverability reporting always surfaces the literal reply code and enhanced status from the wire, specifically so a downstream categorisation bug cannot hand your team a code that does not exist.