SMTP error codes: what the bounce is telling you

If your mail has bounced, the bounce carries a code and the code already tells you whose problem it is. Codes starting with 4 are deferrals: the receiving server will not take the message now, but it will later, and your server retries on its own. Codes starting with 5 are definitive rejections: nothing is retried, the cause gets fixed. And if the code continues with 5.7 (550 5.7.26 or 550 5.7.515, for instance), the cause is almost never the recipient: it is that your domain does not identify itself the way it has been required to since 2024.

This guide is, above all, a table. Find the exact code you were sent and go down to its section. Every one of them is reproduced as Google and Microsoft return it, with a link to the page that documents it.

How to read a bounce in ten seconds

A bounce carries three parts: the three digits say whether it is temporary or definitive, the enhanced status code says which family the problem belongs to, and the server text usually states outright what is missing.

550 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level

   │   │       └── server text: the cause is here, blunt and unadorned
   │   └── enhanced status code: family 5.7 = policy and authentication
   └── three digit code: 5xx = permanent rejection, do not retry

The table: what each code means and what to do

The 5.7.x family: why mail suddenly bounces

Until 2024, badly authenticated mail ended up in the spam folder. Google set 1 February 2024 as the date its bulk sender requirements came into force, and began enforcing them with temporary errors. On 5 May 2025 Microsoft announced that SPF, DKIM and DMARC would be required of anyone sending more than 5,000 messages a day to outlook.com, hotmail.com and live.com: Junk Email folder first, then rejection with 550 5.7.515.

That sentence is the change: from deferring to rejecting. It is why a flow that has worked for years starts bouncing without anybody touching anything. Your mail has not changed, what the receiver accepts has.

421-4.7.26, 421-4.7.30 and 421-4.7.32

All three are Google’s and all three are deferrals: the mail is still queued and will be retried. They are the cheapest warning you will ever get, because they tell you the authentication is wrong before the 550s start. 4.7.26 means SPF and DKIM failed together. 4.7.30 means DKIM failed on a bulk sender. 4.7.32 is the most misread of the three: SPF or DKIM may well be passing, but they do not align with the domain the user sees in the From:.

550-5.7.26: the same problem, now without retries

This is 4.7.26 once the patience runs out: permanent rejection on authentication. There is no queue and no retry here, every message is lost on the spot. Resending the same campaign without touching DNS only piles up hard bounces, which is the metric your sending provider uses to suspend your account.

550 5.7.515: the Microsoft one

550; 5.7.515 Access denied, sending domain [domain] does not meet the required authentication level

Microsoft requires all three things here: SPF, DKIM and a published DMARC record, with the From: aligned by either SPF or DKIM. And there is a detail that catches people out: once you have gone past 5,000 messages a day with the same domain in the From:, every subsequent message has to comply, whether you send five thousand or five. Google uses the same threshold, with a twist that breaks whole architectures: subdomains count towards the main domain’s threshold, so splitting the sending across news1, news2 and news3 does not get you under 5,000, it just shares out the same total.

550 5.7.1, 421 4.7.0 and 4.7.28: reputation and pace

These three say nothing about your DNS records. They are about where you send from and how fast. 550 5.7.1 means the IP is on Google’s suspended list, and in practice that is almost always the reputation of a shared IP you do not control. 421 4.7.0 and 4.7.28 are rate limiting: you are going too fast for what that receiver will tolerate today, and for 4.7.28 Google says to wait 10 minutes before retrying. The right response to a sustained 4.7.0 is not to change provider: it is to slow down, because Google explicitly asks for a consistent rate and no bursts.

Hard bounce, soft bounce, and what to do with each

The thresholds that shut your account before Gmail does

Bounces do not just cost you delivery: they cost you the provider. These thresholds are published in each provider’s own terms, so they apply automatically and there is nothing to argue about.

Look at the order of those figures: the complaint threshold at Mailgun and Resend (0.08 %) is stricter than Google’s (0.10 % recommended, 0.30 % for exclusion). They shut your account before Gmail penalises you, so the primary risk of a badly run campaign is not the spam folder, it is losing your provider halfway through a send. And the arithmetic of 0.30 % is worth writing down: it is 3 complaints per thousand delivered messages. On a send to 5,000 recipients, fifteen people hitting the spam button take you out of Google’s delivery mitigation system, and you only get your eligibility back after seven consecutive days below the threshold.

The failure that gives you no code at all

The worst failure does not bounce. When your mail is delivered and lands in the spam folder, the receiver answers 250 (accepted) and you never find out: no code, no bounce, no warning. Only a rejection with a code leaves you evidence in hand. And the Postmaster Tools spam rate does not fill that gap either, because Google defines it as the percentage of messages recipients mark by hand: automatic filtering does not show up there. You can have a 0.05 % spam rate and still be landing in the folder at scale.

What to do now, in order

1. Copy the exact codeFrom the original bounce, not from your mail client’s summary, with the domain and the date next to it.
2. Check whether it is 4xx or 5xxWith a 4xx you have some room and the mail is still being retried. With a 5xx, stop sending.
3. Check your domain’s public recordsSPF, DKIM, DMARC and the MX are visible from outside in thirty seconds, and that is where almost every 5.7.x is explained.
4. Fix the alignment, not just the recordsMake the From: domain match the one that signs with DKIM or the one in the Return-Path. It is the fault behind most 4.7.32s.
5. Restart slowlyGoing straight back to your previous volume after a block is the fastest way to get blocked again.

If nothing bounces, but the mail is delivered and nobody reads it, the guide that carries this thread on is «My mail goes to spam». If the bounce is in the 5.7.x family, the one that fixes it at the root is «SPF, DKIM and DMARC», which explains alignment at a proper pace. And if you are starting to send again after a block, read «Domain warm-up» first: restarting is what most people get wrong.