SMTP 455, 458 and 459: rare legacy server-hold and queue codes

455, 458 and 459 are not codes any current mainstream mail server emits. They do not appear in Gmail's, Microsoft 365's, Yahoo's, Postfix's or Exim's reply tables. Historically, numbers in this range were associated with older mail systems - some legacy mainframe and VMS-era mail transfer agents used extended 4yz numbering for node-level queueing and parameter-accommodation failures that modern SMTP implementations simply do not reproduce. If you are looking at a modern sending log and see one of these three numbers, treat the number itself with suspicion rather than assuming it is an authoritative current reply.

What a modern sender almost certainly actually received

The conditions these three numbers are typically described as meaning - "server unable to accommodate parameters," "unable to queue messages for node," "local processing error" - map onto a small set of real, current, standard codes:

• 452 - queue full or resource exhausted (the modern equivalent of a "can't queue this" failure).
• 421 - service not available right now, closing the connection (the modern equivalent of a general local processing error that prevents the server continuing the session at all).

Who is at fault

For the real, current equivalents, the fault sits with the receiving server's capacity or internal state, not with you. Both 452 and 421 are temporary failures. If you maintain internal documentation or a runbook that references these three numbers, the

most useful single change you can make is replacing them with the real, current codes they most

likely map to, along with a note explaining why - so the next person who encounters an unfamiliar

reply from a modern mail server does not waste time trying to match it against a numbering scheme

that was never real in the first place. Historical curiosities are fine to keep as footnotes, but

operational runbooks should point at what a current server will actually say.

The exchange (the real, current reply)

220 mx.example.com ESMTP
EHLO mail.yourdomain.com
250-mx.example.com
250 SIZE 26214400
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
452 4.3.1 Queue full, try again later

How Gmail, Microsoft 365 and Yahoo word the real, current condition

Diagnostic commands

$ grep -i "status=deferred\|status=bounced" /var/log/mail.log | tail -5
to=<recipient@example.com>, relay=mx.example.com[203.0.113.8]:25,
delay=0.4, status=deferred (host mx.example.com said:
452 4.3.1 Queue full, try again later (in reply to RCPT TO command))

$ swaks --to recipient@example.com --from sender@yourdomain.com --server mx.example.com
<~  452 4.3.1 Queue full, try again later

Checking the raw mail log first, before trusting any dashboard summary that cites 455/458/459, will nearly always reveal the real, current code behind it.

The ordered fix

1. Pull the raw log line rather than any pre-processed label showing 455, 458 or 459.
2. Confirm the real reply is a 452 or 421, and treat it as a standard temporary resource/queue failure.
3. Let your queue retry normally - these are transient, receiving-side resource conditions that typically clear within hours.
4. If the condition persists past a day, contact the recipient through another channel.
5. Correct whatever reporting tool displayed the legacy/fabricated number so your team sees the real reply code going forward.

What not to do

• Do not assume your sending system is running into some exotic legacy protocol issue. Modern servers simply do not generate 455, 458 or 459; the explanation is almost certainly a mislabelled real code.
• Do not treat this as a permanent failure. Both the fabricated numbers' descriptions and their real-world equivalents (452, 421) are temporary.
• Do not change authentication or content in response. The underlying condition is about receiving-side capacity, unrelated to SPF/DKIM/DMARC or message content.
• Do not keep relying on whatever tool invented these numbers without checking its output against a raw log at least once - if it fabricated these, it may be doing so elsewhere too.

Why legacy numbering schemes persist in documentation

Old mail-system documentation, once published, tends to get copied into newer summaries without

anyone re-verifying it against current server behaviour. A page written years ago describing a

VMS-era mail system's queue-node codes can still rank well in a search result today, and someone

troubleshooting a current issue can land on it and reasonably assume the numbers are still in use.

The only defence is the same one that applies throughout this topic: trust the raw log line from

your own current mail system over any external description, however authoritative it looks.

MailPilot surfaces the literal reply code and enhanced status from the wire in its deliverability reporting, so a downstream tool's legacy or invented numbering scheme never becomes the only record your team has of what actually happened.