Decode the bounce
Paste the whole NDR if you have it — the tool finds the codes wherever they are and reads the provider's wording around them.
How it works
Extract
Every three-digit SMTP reply and every X.Y.Z enhanced status code in the text is found, wherever the provider put it.
Decode
Codes are matched against RFC 3463 and RFC 5248 meanings plus Google's, Microsoft's and Yahoo's documented extensions.
Read the words
The receiver's wording is scanned for the phrases that identify reputation blocks, DMARC rejections, blocklist references, greylisting and directory rejections.
Verdict
Hard, soft or policy block — and the one decision that matters: remove the address, retry, or stop and fix the sending side.
The one distinction that matters
Every bounce looks the same in the sending tool: a red row and a number. The number hides two entirely different situations. A 5.1.1 means the address does not exist; keep sending to it and your hard-bounce rate climbs until Google throttles the domain. A 5.7.1 means the address is fine and the receiver rejected you; remove it and you have thrown away a good lead while the actual problem — reputation, authentication, a blocklist — carries on breaking the next thousand sends. Most tools treat both as "bounced". This decoder does not.
Reading the three parts
The three-digit code is the SMTP reply: 2xx accepted, 4xx try again, 5xx never. The dotted code is the enhanced status from RFC 3463: the first digit repeats temporary or permanent, the second names the area — 1 is addressing, 2 the mailbox, 4 routing, 7 security and policy — and the third is the specific reason. The text after is the receiver's own explanation, and it is often more useful than either code: Gmail says "very low reputation of the sending domain" in so many words, and Microsoft's S3150 and SC-001 strings are documented on their postmaster site.
Provider dialects
Google, Microsoft and Yahoo each extend the standard codes. Gmail's 5.7.26 is its bulk-sender authentication requirement; 4.7.28 means it is throttling on rate. Microsoft 365 uses 5.4.1 Recipient address rejected: Access denied for an address not in the tenant, which is a hard bounce dressed as a policy block, and 5.7.606 through 5.7.708 for IP blocks you clear at sender.office.com. Yahoo's TSS04 is a reputation block that no amount of retrying fixes. The table carries all of these.
What to do with each class
Hard: remove the address, and if more than two percent of a send bounced hard, verify the rest of the list before touching it again. Soft: leave it to the sending tool's retries; remove after three consecutive failures. Block: stop sending from that domain, run the deliverability score and blacklist checks, fix authentication or request delisting, and only then resume — slowly. The block class is the one where people do the most damage by doing the obvious thing.
Frequently asked questions
What does 550 5.1.1 mean?
The mailbox does not exist. It is the standard hard bounce for a bad address. Remove it from the list.
What does 550 5.7.1 mean?
The receiver refused the message on policy — reputation, blocklist, content or a rule. The address is fine; your sending setup is the problem. Do not remove the address; fix the sending side.
Is a 421 a bounce?
It is a temporary rejection, usually rate limiting. The sending server retries automatically. If it persists for hours, the receiver is soft-blocking you on reputation.
Why does Microsoft 365 return 5.4.1 for a bad address?
Directory-Based Edge Blocking rejects any address not in the tenant's directory with 'Recipient address rejected: Access denied'. Despite the 5.4 class, treat it as user-unknown.
How many bounces are too many?
Gmail and Microsoft start throttling above roughly a two percent hard-bounce rate. A verified list should run well under one.
Last reviewed
What to run next
The checks that most often follow this one.
More in this category
Guides that go deeper
When the tools tell you something is wrong
The diagnostics here are free and always will be. When the fix is bigger than a DNS record, this is the work I do.
Deliverability rescue
Mail landing in spam, replies gone quiet, or a domain suddenly blocked. I find the actual cause rather than guessing, and fix it.
- Authentication and alignment failures
- Blocklist delistings and reputation repair
- Gateway and filter-level blocks
- A written report on what broke and why
Email & sending infrastructure
Sending domains, inboxes, authentication and warmup, built to survive volume instead of burning down in a month.
- Domain and inbox fleets at any scale
- SPF, DKIM, DMARC and tracking domains
- Google Workspace — Silver Partner
- Handover documentation you actually own
Domain, DNS & migration
Changing registrar, mail provider or host without a day of downtime or a week of mail silently failing.
- Registrar and nameserver moves
- Workspace and Microsoft 365 migrations
- MX, SSL and subdomain cutover
- Staged rollout with rollback at every step
Monitoring & retainer
Infrastructure drifts. Records get edited, certificates expire, domains get listed. Ongoing eyes on the fleet.
- Scheduled checks across every domain
- Alerts before your clients notice
- Monthly reporting
- Priority response when something breaks
Start with a call
Bring a domain and the symptom. I will tell you what is actually wrong and whether you need me at all — plenty of people leave that call able to fix it themselves.
Thirty minutes, no pitch
We will run the checks together on your actual domains, and you will leave knowing what is broken, what it takes to fix, and what it should cost. If that is a job you can do in-house, I will say so.