SMTP 453 "server not accepting mail": not a real reply code

There is no RFC 5321-defined SMTP reply code 453. The base reply codes a compliant server can send are limited to a known set — 421, 450, 451, 452, 455 in the 4xx range, and 500–504, 550–555 in the 5xx range, plus whatever enhanced status code (RFC 3463) rides alongside the base code. 453 fits the 4xx pattern syntactically but isn't an assigned code, and major mail systems (Gmail, Microsoft 365, Yahoo, and the common open-source MTAs) do not emit it in practice.

What's actually going on if you see "453"

If a deliverability tool, a forwarded report, or a log parser shows "error 453," check the raw SMTP transcript rather than the label. In the overwhelming majority of cases, the real server reply is a standard 450 ("Requested mail action not taken: mailbox unavailable") or 451 ("Requested action aborted: local error in processing") — both genuine, both 4xx temporary deferrals describing a receiving mailbox or server that isn't ready to accept the message right now.

Who is at fault

Whichever real code is underneath — 450 or 451 — this is almost always a recipient-side or transient condition: a full or paused mailbox, a receiving server under load, or a greylisting response, not something broken in your sending setup.

The exchange (what the real underlying reply looks like)

220 mx.example.com ESMTP ready
EHLO mail.yourdomain.com
250 mx.example.com
MAIL FROM:<sender@yourdomain.com>
250 2.1.0 OK
RCPT TO:<recipient@example.com>
450 4.2.1 Mailbox temporarily unavailable, try again later

How the big three word the real condition

Diagnose it

Pull the actual SMTP response from your mail server's log or your ESP's bounce detail — don't rely on a summarised "error code" from a third-party dashboard that may be normalising or mislabeling the real reply.

$ grep -A2 "RCPT TO" /var/log/maillog | grep -E "^4[0-9]{2}"

Fix it, in order

1. Get the raw reply text, not a paraphrased code, from your mail logs.
2. Treat it as a 4xx deferral: let your MTA retry automatically; most queues retry for 24–72 hours before giving up.
3. If it recurs for the same recipient repeatedly, that mailbox may be inactive or over quota — consider suppressing it after several failed attempts rather than retrying indefinitely.
4. If it recurs across many recipients at one provider, that points to a reputation or rate issue on your side, not a mailbox-specific one — check your sending volume and authentication.

A cause worth checking directly: greylisting

One specific trigger worth checking by name: greylisting. A server practicing greylisting issues a temporary 450 or 451 on the very first delivery attempt from an unfamiliar sending IP, sender, and recipient combination, by design, before it has ever seen you retry. Tools that normalise bounce codes sometimes bucket this first-attempt greylist deferral under an invented label like "453" because it doesn't map cleanly onto either a hard failure or a simple full-mailbox condition in their own taxonomy. If your logs show the deferral clearing on a retry roughly 1–15 minutes to a few hours later, for the exact same recipient, with nothing else changed on your end, greylisting — not a genuine server fault — is almost certainly what happened.

A second diagnostic pass

$ swaks --to recipient@example.com --from test@mailpilots.in --server mx.example.com

Running a manual swaks test against the same recipient, separate from your production queue, shows you the live reply text directly rather than through whatever summarising layer produced "453" in the first place, and confirms whether the condition is still active.

How long to expect it to persist

A genuine 450/451 under this kind of mislabeling should clear on your MTA's normal retry schedule — most queues retry within 15 minutes to 4 hours initially, backing off toward the 24–72 hour range if it persists. If the same recipient keeps deferring past 72 hours with no change in the underlying reply text, treat it as a stalled mailbox rather than routine greylisting, and consider suppressing it after several more failed attempts.

What not to do

• Don't search for "SMTP 453 fix" guides and follow their steps literally. They're describing a code that doesn't exist and the advice is often generic filler unrelated to your actual reply.
• Don't report "453" as the issue to your ESP or hosting support. Give them the raw transcript; the real code is what they need to diagnose anything.
• Don't assume it's a permanent failure. Whatever the real underlying code, a 4xx-range reply should never be treated as equivalent to a hard bounce.

MailPilot surfaces the raw SMTP reply text from every bounce alongside per-provider inbox placement data, so you're working from the code a server actually sent rather than a label a tool invented.