What do 4xx SMTP error codes mean? (Temporary failures)

A 4xx SMTP code is the receiving server's way of saying "not right now, try me again later." The message is not rejected. It is held in your queue, and your mail server is expected to retry it on a sensible schedule.

This matters because every sender confuses 4xx with 5xx at some point, suppresses the address, and then wonders why their list shrank for no good reason. A 4xx is not a hard bounce. It is a transient delivery failure, which means the receiver thinks the condition will likely clear.

What the spec actually says

The numbering scheme comes from RFC 5321, the core SMTP specification. The first digit tells you the class of the reply:

• 2yz: success
• 3yz: positive intermediate (more input expected)
• 4yz: transient negative completion (try again)
• 5yz: permanent negative completion (do not retry as-is)

The official text for 4yz is: "The command was not accepted, and the requested action did not occur. However, the error condition is temporary, and the action may be requested again." See RFC 5321 section 4.2.1 for the full reply code grammar.

The 4xx codes you will actually see

A handful do most of the work in real logs:

• 421: Service not available, the server is closing the connection. Often a rate limit or a maintenance window. See what does 421 mean for the full breakdown.
• 450: Mailbox unavailable for a non-permanent reason. The address probably exists, the server just will not take it right now. Sometimes a greylisting tactic.
• 451: Local error in processing. The receiver hit an internal hiccup. Retrying usually works.
• 452: Insufficient system storage. Rare on big providers, common on self-hosted boxes that ran out of disk.
• 454: Temporary authentication failure. Often a STARTTLS or AUTH negotiation issue that clears on the next attempt.

For a longer reference, see common 4xx codes and their meanings.

What a sender should actually do

Queue and retry. Your MTA or ESP should hold the message and try again on a backoff. RFC 5321 section 4.5.4.1 recommends the first retry no sooner than 30 minutes after the failure, and a typical retry window runs 24 to 72 hours before the message is given up on and converted to a permanent bounce.

Three rules I give every sender:

1. Do not suppress on a single 4xx. That address is not dead. Suppressing it kills future sends to a real inbox.
2. Watch the pattern, not the event. One 421 from Gmail is noise. Forty 421s in a row is a rate limit telling you to slow down.
3. Read the enhanced status code if there is one. Many receivers attach a three-number code like 4.7.0 after the 421, which narrows the cause to policy, mailbox, auth, network, and so on. Defined in RFC 3463.

When 4xx becomes a real problem

If a message keeps getting 4xx'd for the entire retry window, your MTA gives up and the message converts to a hard failure. The bounce report you get back will look permanent, but the root cause is still whatever caused the temporary block. That is why deep deferral patterns are usually a deliverability problem in disguise, typically one of:

• Sending volume above what the receiver tolerates from your IP or domain
• Reputation issues at the receiver (low engagement, complaint signal, list quality)
• Authentication problems that only surface under load

See what happens after a deferred message retries for the full lifecycle, and how ESPs classify bounces for how this ends up labelled in your reporting.

The short version

4xx means "ask me again later." The receiver is not telling you the address is bad. It is telling you that this attempt, at this moment, did not land. Suppress on patterns, not on single events, and read the enhanced status code if the receiver gave you one. That is the difference between a sender who shrinks their list by accident and one who actually fixes the underlying issue.