Most cold senders treat bounces as a single number on a dashboard. That throws away the most useful diagnostic data you get. Every rejection comes with a reply code written by the receiving server, and that code tells you whether the address is dead, the mailbox is temporarily unavailable, or the provider simply does not trust you.
Those are three completely different problems with three different fixes. This guide shows how to read the codes and what to do with each.
The anatomy of a bounce message
A typical rejection line looks like this:
550 5.1.1 The email account that you tried to reach does not exist.
It has three parts:
- The basic reply code (
550), defined in the SMTP standard, RFC 5321. The first digit is what matters most:2means accepted,4means temporary failure,5means permanent failure. - The enhanced status code (
5.1.1), defined in RFC 3463. It is more specific and is where the real diagnosis lives. - Free text written by the provider. It is not standardised, but Google and Microsoft often include a help link or an internal reference that narrows things down further.
How to read an enhanced status code
Enhanced codes follow the pattern class.subject.detail. The class matches the first digit of the basic code (2, 4 or 5). The subject tells you which part of the system the problem is in:
| Subject | Area | Usually means |
|---|---|---|
| X.1.X | Addressing | The address is wrong or does not exist |
| X.2.X | Mailbox | The mailbox exists but is full, disabled or not accepting mail |
| X.3.X | Mail system | The receiving system has a problem |
| X.4.X | Network and routing | Timeouts, DNS or routing failures |
| X.5.X | Protocol | Something went wrong in the SMTP conversation itself |
| X.6.X | Content and media | The message format or size was not acceptable |
| X.7.X | Security and policy | Authentication, reputation or policy blocks |
For cold email, the two subjects you will see most are X.1 (bad data) and X.7 (you, not them).
Hard, soft and policy bounces
It is more useful to sort bounces into three buckets than the usual two:
- Hard bounces are permanent and about the address: it does not exist, the domain does not exist, or the mailbox is closed. Suppress the address and never send to it again.
- Soft bounces are temporary and about the recipient's side: a full mailbox, a server busy, a rate limit. Retry later; most sending tools do this automatically.
- Policy bounces are about your sender: failed authentication, low reputation, a blocklist listing, or content the provider will not accept. They can arrive as either 4xx or 5xx. Removing the recipient fixes nothing, because the next recipient at the same provider will get the same answer.
The third bucket is the one that should worry you. A rising policy bounce rate is often the earliest visible sign that a domain or IP is in trouble.
Common codes and what to do
The exact wording varies between providers and changes over time. Treat these as typical patterns rather than verbatim strings.
| Code | Typical meaning | Type | Action |
|---|---|---|---|
| 550 5.1.1 | Recipient address does not exist | Hard | Suppress. Validate the rest of that list. |
| 550 5.1.10 | Microsoft: recipient not found | Hard | Suppress. |
| 550 5.4.1 | Microsoft: recipient address rejected, access denied (often the address does not exist in that tenant) | Hard | Suppress and verify the address. |
| 552 5.2.2 | Mailbox full | Soft in practice | Retry a few times, then suppress if it persists. |
| 450 4.2.1 | Gmail: recipient is receiving mail too fast | Soft | Retry later. |
| 451 4.7.1 | Try again later, often greylisting or a temporary policy hold | Soft | Let your server retry. Repeated 4.7.1 from one provider can be an early reputation warning. |
| 421 4.7.0 | Temporarily deferred, often for low IP or domain reputation, or TLS issues | Policy | Slow down, check authentication and TLS, run a placement test. |
| 421 4.7.28 | Gmail: unusual rate of unsolicited mail from your IP or domain | Policy | Cut volume sharply and review targeting. |
| 550 5.7.1 | Message rejected by policy: spam, blocklist, or recipient-side rule | Policy | Read the text. Check blacklists and recent complaints. |
| 550 5.7.26 | Gmail: message failed authentication or the domain's DMARC policy | Policy | Fix SPF, DKIM and alignment before sending more. |
| 550 5.7.27 | Gmail: sender domain failed SPF | Policy | Add the sending source to SPF, check the lookup count. |
| 550 5.7.515 | Microsoft: sending domain does not meet the required authentication level | Policy | Publish passing, aligned SPF, DKIM and DMARC. |
| 550 5.7.606 | Microsoft: sending IP is banned | Policy | Request delisting through Microsoft's sender support portal. |
The authentication codes in more detail
Since Gmail and Yahoo tightened their rules for bulk senders in 2024, and Microsoft followed for Outlook.com consumer addresses in 2025, authentication failures show up as explicit rejections rather than silent spam-foldering. That is actually helpful: a 5.7.26, 5.7.27 or 5.7.515 tells you precisely what is broken.
The usual causes are a missing DKIM record for the sending service, an SPF record that exceeds the 10 DNS lookup limit, a second SPF record that invalidates both, or a From domain that does not align with either the SPF or DKIM domain. The SPF and DKIM checker will find most of these in a minute, and the sender requirements guide lists what each provider expects.
When the code means "we do not trust you"
Codes like 421 4.7.0, 421 4.7.28 and many 550 5.7.1 variants are reputation signals. The provider has looked at your IP, your domain or the content and decided to defer or refuse. What helps:
- Reduce volume on the affected mailboxes immediately. Do not retry harder.
- Check the domain and sending IP on the blacklist checker.
- Look at what changed: a new list source, new copy, a jump in volume.
- Run an inbox placement test before ramping back up.
- If you are listed, follow the delisting guide after fixing the cause, not before.
Turning bounce data into a routine
Track bounces by type, not just as a total. A campaign with a 3% bounce rate made entirely of 5.1.1 is a list problem; the same 3% made of 5.7.1 is a sender problem. The bounce rate calculator helps you see where a campaign stands.
In Sendbox, hard bounces are suppressed automatically and bounce patterns roll up into each mailbox's health status, so a mailbox that starts collecting policy rejections gets flagged before it drags the rest of a campaign down. The underlying rule holds anywhere: suppress hard bounces, retry soft ones, and treat policy bounces as a reason to stop and investigate.
