Classify a bounce export
How it works
Read the export
CSV with any column names, or raw bounce lines. The tool finds the recipient, the sending inbox and the bounce text by header pattern, and falls back to the longest text column.
Classify each row
Enhanced status codes like 5.1.1 and 5.7.26, basic SMTP codes, and about 150 phrases receivers actually use are matched in order — auto-replies first so they never count as bounces.
Cross-tabulate
Counts by category, by sending inbox and by recipient domain. A single inbox with all the blocks is burned; a single domain with all the blocks is filtering you specifically.
Act
Each category carries its action. Export the classified CSV, or just the hard-bounce suppression list to upload back into the sending tool.
The number your tool gives you is not enough
Every sending platform reports a bounce rate, and every operator I work with reacts to it the same way: verify the list harder. Half the time that is the wrong fix. A 4% bounce rate made of 5.1.1 user unknown is a list that was never verified. The same 4% made of 5.7.1 blocked and 421 unusual rate is a domain or inbox that receivers have decided to refuse, and no amount of list cleaning touches it — you will verify a perfect list and bounce on it anyway. This tool exists to split those apart before you spend money on the wrong one.
Where the categories come from
Receivers speak in enhanced status codes — 5.1.1 for a missing mailbox, 5.2.2 for a full one, 5.7.26 for mail that failed authentication, 4.7.0 for rate limiting — and, less reliably, in prose. Google says “the email account that you tried to reach does not exist”; Microsoft says “Recipient address rejected: Access denied” for three different reasons; Proofpoint and Mimecast have their own vocabularies. The classifier matches codes first and phrases second, with auto-replies caught before either so an out-of-office never inflates the count. The bounce code decoder explains any single row in more depth.
Read the inbox table before anything else
When an export includes the sending account, the per-inbox breakdown is the most useful thing on the page. Bounces spread evenly across thirty inboxes are a list problem. Bounces concentrated on three inboxes, and mostly blocks, mean those three are burned and should be paused today, before they take the domain with them. The recipient-domain table answers the mirror question: if one company's mail server rejects everything as policy, that is their filter, and the fix is to stop sending to them rather than to change anything about your setup.
What to do with each pile
Hard bounces come out permanently — the suppression export gives you the list to upload. Soft bounces get a 30-day pause and one retry. Rate limits mean the daily volume is ahead of the inbox's reputation; the warmup calculator gives a ramp that does not trip them. Blocks are the only category that should stop a campaign: pause the affected senders, run the domain checker and blacklist checker on each, and resume at half volume once they are clean.
Frequently asked questions
Which exports does it understand?
Any CSV — Instantly, Smartlead, lemlist, Apollo, Woodpecker, Mailreach, or a raw list of bounce lines. Columns are detected by name, so as long as there is an email and the bounce text somewhere in the row it will parse.
What bounce rate is too high?
Over 2–3% hard bounces on a send tells Google and Microsoft the list was not verified, and repeated sends like that get the domain filtered. Blocks are worse at any percentage: they mean the receiver has already decided about you.
Why are auto-replies in the export at all?
Some tools log every non-delivery response as a bounce, including out-of-office messages. The classifier removes them first and reports percentages against real bounces only.
Is the file uploaded anywhere?
No. Parsing and classification run in your browser; the export never leaves your device.
A row is classified wrong — what then?
The full table shows the raw message next to the category so you can spot it. Rules match codes before phrases, so an unusual receiver message with a standard code will still be right; if you find a pattern I have missed, send it to me.
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 and Microsoft 365 inboxes
- 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.