What is the difference between a 4xx and a 5xx SMTP code?

A 4xx is transient: retry, because the condition is temporary. A 5xx is permanent: do not repeat the command in the same form. A 451 is squarely in the first category, and treating it as a bad address is how working mailboxes get deleted from lists.

What is an SMTP handshake?

The opening exchange of an SMTP session: the server sends a banner, the client greets it with EHLO, they negotiate options and usually TLS, and only then does the client name a sender and a recipient. A 451 can be returned at any of those steps, which is why it says nothing about the address.

How does SMTP verification work?

The verifier resolves the domain MX records, opens an SMTP session, sends EHLO and MAIL FROM, names the address with RCPT TO, and reads the reply — then stops before DATA, so no message is transmitted. The reply code becomes the verdict. A transient failure anywhere in that sequence produces unknown rather than a verdict.

What is SMTP handshake validation?

A marketing name for the RCPT TO check: opening a real SMTP conversation with the receiving server and reading its reply, rather than guessing from syntax or DNS. It is the only layer that can establish whether a mailbox exists, and it is the layer that a transient reply such as 451 4.3.0 prevents from completing.

SMTP reply code

451 4.3.0 — temporary local error

A 451 4.3.0 reply means something went wrong in the receiving mail system itself and the message could not be processed now. It is transient and non-specific by design. Retry; there is usually nothing to fix at your end.

The facts

Reference facts for SMTP 451 4.3.0
Field	Value
Reply code	`451`
Enhanced status code	`4.3.0`
Class	4 — transient failure
Subject	3 — mail system status
Detail	0 — other or undefined mail system status
Bounce type	Soft
Should the sender retry?	Yes
Representative wording	`451 4.3.0 Temporary server error. Please try again later`

The representative wording is one real form of this reply. The exact string is set by the receiving server and varies between mail platforms — read the one in your own logs rather than matching on a string.

What VerifyInbox returns

What VerifyInbox returns for SMTP 451 4.3.0
Field	Value
`emailStatus`	`unknown`
`reason`	`greylisted` — the label a 4xx deferral carries when the reply names nothing more specific. The fields that matter for an integration are `emailStatus` and `retryable`.
`smtpCheck`	`deferred`
`retryable`	`true`
Charged	No. The mailbox was never tested.

The deliberately vague one

The three-digit reply code comes from RFC 5321: a 2yz is a success, a 4yz is a transient failure the sender should retry, and a 5yz is a permanent failure the sender should not repeat in the same form. The dotted code beside it comes from RFC 3463 and has three parts — class.subject.detail — where the class repeats 2, 4 or 5, the subject says which part of the system had the problem, and the detail says what it was. The full list is an IANA registry established by RFC 5248, which is the authoritative source and the one nothing else ranking for these queries cites.

Subject 3 is mail system status — the receiving system itself, as opposed to the address (subject 1), the mailbox (subject 2), the network (subject 4) or policy (subject 7). Detail 0 is "other or undefined", which is the registry’s way of saying the server knows something went wrong and is not telling you what.

That vagueness is usually deliberate and reasonable. The causes are things a receiving operator has no interest in publishing: a full disk, a database that did not answer, a downstream filter that timed out, an internal queue that is backed up. None of them is the sender’s business and none of them is the sender’s fault.

What to make of it

One is noise. Every large mail system produces them. A well-behaved sending server queues the message and retries, and the recipient never knows.

A sustained run of them against one domain is different: either that domain is having an incident, or something about your traffic is triggering a resource limit. Some servers also use 451 for greylisting and for rate limiting rather than the more specific codes, so read the text before concluding the receiver is broken.

What to do

If you sent the message

Wait. Your mail server will retry, and the message usually goes through.
If it is happening to every message to one domain, that domain is probably having a problem — try again in a few hours rather than switching to a different address.

If you own the receiving domain

Check the mail system logs: disk, queue depth, and any content filter or antivirus in the delivery path.
A 4xx is the right thing to return while you are degraded — it makes senders queue instead of bouncing real mail.

If you are a developer

Retry with exponential backoff and a cap, and give up into a queue rather than into a suppression list.
Alert on the rate per receiving domain, not on individual events.
Treat retryable: true in a verification result the same way: it is a question, not an answer, and it was not charged.

To find out whether an address will return this before you send to it, run it through the free email verifier

Related codes

Related terms

Sources

Primary sources checked 11 September 2026. If something here is out of date, tell us and we will correct it.