SMTP rejection codes explained: what 421, 451, 550 and the 5.7.x family mean

Temporary versus permanent: the distinction that matters most

If you remember one thing from this reference, make it the difference between the 4 and the 5. A 4xx is a temporary refusal: the receiving server is asking you to come back later, and a well-behaved sender queues the message and retries on a schedule, often for a day or more, before giving up. Rate limiting, server load, greylisting and a sudden complaint spike all produce 4xx responses, and most of them resolve on their own. A 5xx is permanent: the server will not take this message, and retrying it unchanged is pointless and counterproductive, because each repeated attempt is another bad signal to the provider. The practical consequence is simple. A 4xx is something to watch and, if it persists, to investigate. A 5xx is something to fix at the source before you send to that recipient again. Confusing the two — retrying a 5xx as if it were a 4xx — is one of the fastest ways to damage a sending reputation.

The common temporary (4xx) codes

Temporary codes are the ones your queue lives with day to day. Most need no action beyond patience, but a repeating 4xx is the early-warning system for a problem that is about to turn permanent — especially the authentication deferrals, which the providers use as a warning shot before they start rejecting outright.

The common permanent (5xx) codes

Permanent codes are the ones that need your attention. Some are mundane — a nonexistent recipient, a full mailbox — and call for list hygiene. Others are reputation and policy rejections that signal a deeper problem with how you authenticate or how the providers see you. The 5.7.x family, in particular, is where the authentication enforcement of the last two years now lives.

The authentication rejections we see most today

Two years ago, the codes most senders met were about addressing and capacity — unknown users, full mailboxes, the occasional content block. Today the codes that fill bounce logs are about authentication, because that is what Gmail, Microsoft and Yahoo decided to enforce. Gmail’s 550 5.7.26 means the message was blocked as unauthenticated: neither SPF nor DKIM passed in alignment with the visible sender domain, so Gmail could not confirm the mail came from where it claims. Microsoft’s 550 5.7.515, in force since May 2025, is the equivalent for its bulk-sender requirements: the sender does not meet the SPF, DKIM and DMARC expectations for its volume. Gmail also defers before it rejects, sending a 421 or 451 4.7.26 as a warning, and since November 2025 it converts persistent warnings into outright rejections rather than letting them slide. The throughline is that these are policy failures, not content failures, and no amount of rewriting the message body will fix them. They are fixed in the DNS and in the signing configuration.

A real example: two bounces, two causes

Consider two bounces that look almost identical and mean opposite things. The first reads “421 4.7.26” with text about unauthenticated mail. That is a temporary deferral: Gmail is slowing you down and warning you, but the message may still get through on retry, and you have a window to fix your authentication before the warning hardens. The second reads “550 5.7.26” with similar wording about being unauthenticated. That is permanent: the same underlying problem, but now Gmail is refusing the message outright, and no retry will help. The lesson is that the three-digit code, not the explanatory text, tells you how urgent the situation is. The 421 says you have time; the 550 says you have already run out of it. Treating the 421 with the urgency it deserves is how you avoid ever seeing the 550.

Connection and network codes: the 4.4.x family

Not every temporary failure is about policy. The 4.4.x subject covers network and routing problems: a connection that dropped mid-transaction, a timeout while waiting for the receiver to respond, a routing loop, or a message that has been sitting in the queue so long the server is about to give up on it. These usually resolve themselves, and a healthy MTA retries them transparently. But a rising pattern of 4.4.x codes to a particular destination can signal something worth investigating — a receiver under load, a network path with trouble, or your own server holding connections badly. They rarely need urgent action, yet they are worth watching as a measure of how cleanly your traffic is reaching its destinations.

The mechanics of a 4xx: queues, retries and when your server gives up

Behind every 4xx is a retry schedule, and understanding it explains a lot of otherwise puzzling delivery behaviour. When a receiver returns a temporary failure, your MTA holds the message in a queue and tries again after a delay, lengthening the gap between attempts as failures accumulate — a few minutes at first, then tens of minutes, then hours. It keeps this up for a configured maximum, commonly somewhere between one and several days, after which it gives up and generates a permanent bounce of its own to the original sender. This is why a recipient sometimes receives a message hours late, and why a temporary problem at the receiver can eventually surface as a hard bounce even though no 5xx was ever returned by the far end. Tuning this retry behaviour — how long, how often, when to surrender — is part of running an MTA well, because retrying too aggressively annoys receivers and retrying too timidly loses mail that would have gone through.

Why codes carry more weight than two years ago

There was a time when a failed authentication check meant a trip to the spam folder, where a diligent recipient might still find the message. That cushion is mostly gone. Since the bulk-sender rules took hold and the providers moved from filtering to rejecting, an authentication failure increasingly means a 5xx at the connection — the message never arrives at all, in any folder. That shift changes what a bounce log is worth. It used to be a rough signal of deliverability problems; now it is a precise, real-time account of which messages were refused and exactly why, with the enhanced code naming the cause. Reading the codes carefully has moved from a nice-to-have for the curious to a basic operational discipline for anyone who depends on their mail arriving.

How to read a real bounce

A real bounce gives you everything you need if you read it in order. Start with the three-digit code to learn the verdict: 4 means watch and retry, 5 means fix and resend. Move to the enhanced code to learn the category: the middle digit tells you whether the problem is addressing, capacity, network or policy, and a 7 there points you at authentication and reputation. Then read the human-readable text, which often names the specific failure and frequently includes a URL to the provider’s help page for that exact code. Many providers also tag the response — gsmtp on Google’s SMTP rejections, for instance — which confirms which system generated it. Worked through in that sequence, even an unfamiliar bounce resolves into a clear statement of what went wrong and where to look.

Codes that get confused

A few codes are routinely misread, and the confusion costs time. The 421 and the 451 both signal temporary trouble but in slightly different ways — 421 typically means the service or connection itself is unavailable, while 451 means the action was aborted partway — and both deserve retries rather than panic. The 550 5.7.1 is a catch-all policy block whose real cause hides in the text, so reading it as a single specific problem leads people astray; it can be reputation, a blocklist, a relay denial or an administrator rule. And the authentication codes 5.7.26 and 5.7.515 are sometimes mistaken for content problems because the message “looks fine,” when the failure is entirely in the DNS and signing layer. When in doubt, trust the enhanced code and the text over your intuition about the message itself.

Yahoo, Apple and the long tail

Gmail and Microsoft get most of the attention because they generate most of the volume, but the rest of the inbox world has its own habits worth knowing. Yahoo, which includes AOL, leans heavily on temporary deferrals: rather than a crisp permanent code, it often returns a 421 that asks you to slow down and come back, using the deferral itself as a reputation throttle. A sender that respects the backoff and keeps complaints low usually recovers; one that hammers through the deferral makes things worse. Apple’s iCloud mail is comparatively quiet about its reasoning, returning fairly terse codes that reward clean authentication and good reputation without much explanation. And below the big names sits a long tail of regional providers, business mail systems and self-hosted servers, each free to phrase its codes in its own way within the standard. The standard is what makes this manageable: however a receiver words its reply, the first digit still means the same thing, and the enhanced code, where present, still reads as class, subject and detail. When you meet an unfamiliar receiver, you fall back on that grammar rather than memorising every provider’s dialect.

DMARCbis: what is coming

The authentication landscape that produces these codes is still moving. An update to the DMARC specification, often called DMARCbis, has been working its way through standardisation and refines how alignment and policy are expressed and how organisational domains are determined. For senders, the headline does not change: strong, aligned authentication remains the requirement, and the policy enforcement that drives 5.7.26 and its relatives is not going away. What the update does is tighten the edges, and it is worth tracking because the codes you see are downstream of exactly these rules. A sender who keeps their SPF, DKIM and DMARC in good order has little to fear from the refinement; a sender relying on loopholes has more reason to pay attention.

Bounce classification in practice

On a real sending platform, codes are not read one at a time by a person; they are sorted automatically into a handful of buckets, and getting that sorting right is most of the operational value. The first bucket is suppress-now: permanent failures that mean the address is dead or unwanted, like 5.1.1 for a nonexistent recipient, where the right move is to remove the address from future sends immediately so it never drags on your reputation again. The second is retry: temporary failures like 421 and 451 that the queue handles on its own, needing no human until they persist. The third is investigate: codes that signal a systemic problem rather than a per-recipient one, and here the authentication rejections — 5.7.26, 5.7.515 and their deferral cousins — belong, because a rising rate of them points at a configuration or reputation issue affecting everything, not one bad address. The fourth, smaller bucket is escalate: a sudden spike of permanent rejections to a major provider, which deserves an alert and a fast look. Sorting every code into one of these as it arrives is what turns a noisy bounce stream into a calm, actionable signal — and it is precisely what a well-configured MTA does without anyone watching.

Where to see codes before they arrive as a bounce

Waiting for codes to show up as bounces is the slow way to learn about a problem. The providers offer windows into your sending before that point. Google’s Postmaster Tools shows authentication pass rates, spam-complaint levels and reputation for domains you verify, which often reveals a brewing 5.7.26 problem days before it becomes a wall of rejections. Microsoft offers its own sender support and lists for legitimate bulk senders. And your own MTA’s logs and metrics are the richest source of all, recording every code in real time so you can spot a rising pattern while it is still a trickle. The discipline is to read these proactively rather than waiting for the bounce log to fill, because by then the reputation damage is already underway.

What not to do

Some reactions to rejection codes make things worse, and they are worth naming. Do not retry a 5xx unchanged: it cannot succeed and each attempt is a fresh bad signal. Do not ignore a repeating 4xx authentication deferral, because it is the warning before a permanent block. Do not keep sending to addresses that returned 5.1.1, since a list full of dead recipients drags down everything else you send. Do not treat an authentication rejection as a content problem and waste time rewriting the message. And do not assume that because most recipients got the mail, the bounces do not matter — the codes in those bounces are often the first sign of a reputation slide that will eventually reach everyone. The codes are advice from the receiver; the mistake is failing to take it.

If you run your own MTA

Operators who run their own infrastructure have both more control and more responsibility over how codes are handled. A well-run MTA classifies bounces automatically, suppressing the addresses that returned permanent failures and retrying the temporary ones on a sensible schedule, so that a 5.1.1 removes a dead address and a 421 simply waits. It feeds the codes into monitoring, so a rising rate of 5.7.26 to a particular provider raises an alert before it becomes a crisis. And it tunes the retry behaviour to the realities of the receivers, neither hammering a server that is asking for patience nor abandoning mail too soon. Getting this right is the difference between a sending platform that degrades gracefully under pressure and one that compounds a small problem into a reputation collapse. It is exactly the kind of work we do when we operate a PowerMTA or KumoMTA estate.

In short

SMTP codes are not obstacles, they are instructions. The three-digit code tells you whether to retry or to stop; the enhanced code tells you the category of problem; the text tells you the specifics and often where to fix them. The codes that matter most in 2026 are the authentication rejections — 5.7.26 from Gmail, 5.7.515 from Microsoft, the 4.7.26 deferrals that precede them — and all of them are fixed in your DNS and signing configuration, never in the message body. Read your bounces in order, act on the 4xx warnings before they harden into 5xx walls, and treat the bounce log as the real-time deliverability instrument it has become. Do that and the codes stop being a wall of noise and start being the clearest feedback your mail program receives. The providers are, in effect, telling you exactly what is wrong with every message they refuse, in a compact and standardised language that has not changed in its fundamentals for decades. The senders who struggle are usually the ones who never learned to read it, reacting to bounces by guessing or by resending blindly. The senders who thrive treat each code as a precise instruction and act on it the way the receiver intended — suppressing the dead address, fixing the authentication, respecting the deferral. None of it requires special tooling, only the discipline to read past the first digit and to trust what the receiver is plainly telling you.