Published on June 14, 2026 • By Kaiju Team
Email bounce verification is the practice of checking every address against a live mail server before you send — so the messages that would have bounced never leave your queue. It is the single most effective lever you have for cutting hard bounces, keeping your bounce rate under the 2% danger line, and protecting the sender reputation that decides whether Gmail and Outlook drop your mail in the inbox or the spam folder. This guide explains what bounces are, why hard bounces are so corrosive to your domain and IP, how pre-send verification stops them, and how to clean a list that is already bouncing.
A bounce is a non-delivery report (NDR) returned by the recipient's mail server when it refuses to accept your message. The server answers your SMTP handshake with a failure code instead of a 250 OK, and your sending platform logs it as a bounce. Bounces come in two flavours that you must treat completely differently.
Hard bounces are permanent. The address simply cannot receive mail — the mailbox was deleted, the domain has no MX record, or the recipient never existed. The server replies with a 5xx code and the enhanced status code starts with 5. (for example 5.1.1, "bad destination mailbox address"). A hard bounce never resolves itself, so retrying it just generates another bounce and more reputation damage.
Soft bounces are temporary. The mailbox exists but the message could not be delivered right now — the inbox is full, the server is overloaded, the message is greylisted, or it tripped a content filter. These return a 4xx code (4. enhanced status) and most ESPs retry them on a schedule for 24-72 hours before giving up. A soft bounce that keeps failing eventually converts to a hard bounce.
Mailbox providers read your bounce rate as a proxy for list hygiene. A clean sender knows who they are mailing; a spammer blasts scraped or purchased lists full of dead addresses. When a meaningful share of your sends hit non-existent mailboxes, providers conclude you do not maintain consent or hygiene — and they act on it.
Google's bulk-sender program enforces this progressively. Non-compliant senders first see temporary 4xx deferrals, then spam-folder placement, then outright 5xx rejection. Since late 2024 many non-compliant domains have been at that final rejection stage. Google asks bulk senders to keep their spam-complaint rate below 0.10% and to never reach 0.30%; rising hard bounces are one of the fastest ways to push a domain into that enforcement territory, because dead addresses correlate with dirty lists and often sit alongside recycled spam traps.
The damage is sticky. Reputation is scored at both the IP and the domain level, and on shared IP pools your bounces can drag down other senders too. In B2B the stakes are higher still: corporate filters evaluate signals at the domain level across every rep mailing that company, so one rep's dirty list can throttle the whole team. Rebuilding a burned domain reputation takes weeks of careful, low-volume warm-up — far more expensive than verifying upfront.
Every bounce carries an SMTP reply code and, usually, an RFC 3463 enhanced status code (three digits separated by dots). The first digit is the class: 2 = success, 4 = temporary failure (soft), 5 = permanent failure (hard). The table below maps the codes you will see most often to what they mean and what to do.
| Enhanced code | Type | Meaning | Action |
|---|---|---|---|
5.1.1 | Hard | Bad destination mailbox — address does not exist | Remove immediately |
5.1.2 | Hard | Bad destination system — domain has no valid MX | Remove immediately |
5.2.1 | Hard | Mailbox disabled, not accepting messages | Remove |
5.2.2 | Soft | Mailbox full (over quota) | Retry, then suppress if persistent |
5.4.1 | Hard | No answer from host / no route to mailbox | Remove |
4.2.2 | Soft | Mailbox full, temporary | Let ESP retry |
4.4.1 / 4.7.x | Soft | Host unavailable, greylisting, temporary policy block | Let ESP retry |
5.7.1 | Hard | Delivery refused on policy — blocked / blacklisted / SPF-DMARC fail | Investigate reputation |
A practical rule: treat any 5.x.x as a permanent removal, and let your ESP handle 4.x.x retries. The exception is 5.7.1 — that is usually about your reputation or authentication, not the recipient, so it signals a deliverability problem to fix rather than an address to delete. For more on the authentication side, see our guide to SPF, DKIM and DMARC.
The thresholds tightened after the Google and Yahoo bulk-sender rules took effect. Here is where the lines sit today for a legitimate sender:
| Total bounce rate | Health zone | What it means |
|---|---|---|
| < 1% | Excellent | Clean list, healthy reputation |
| 1% - 2% | Acceptable | Normal; keep an eye on the trend |
| 2% - 5% | Concerning | Investigate and clean now |
| > 5% | Dangerous | ESP suspension and blocklisting risk |
Two numbers matter most. Total bounce rate under 2% is the broad target for any legitimate program. And hard bounces specifically should stay below roughly 0.5% — hard bounces are the ones that hit dead addresses and signal poor hygiene, so they are weighted heavily. Most major ESPs (Mailchimp, SendGrid, HubSpot and peers) will restrict or suspend an account whose bounce rate climbs past 5%, and Google treats persistent hard-bounce problems above 2% as grounds for deferral and domain-level blocking.
Cold-outreach and B2B prospecting lists tend to bounce harder than opt-in newsletters because the data is colder, which is exactly why verification matters more there, not less.
Bounce verification works by simulating the start of a delivery — without ever sending the message — and reading the server's answer. KaijuVerifier runs this as a layered check, and each layer catches a different class of would-be bounce:
A grammar parser rejects malformed addresses — double dots, missing TLDs, illegal characters — before any network call. This catches typos that would otherwise produce a 5.1.1 hard bounce. KaijuVerifier also runs a Levenshtein "did you mean" check, so user@gmial.com surfaces a suggested correction instead of bouncing.
The verifier queries the domain's DNS for MX records, with an A/AAAA fallback. No mail server means no inbox, which is a guaranteed 5.1.2 hard bounce. KaijuVerifier also scores the health of the MX configuration so you can spot fragile or misconfigured domains.
This is what separates real verification from a regex check. The verifier opens a connection to the recipient's MX server and walks through EHLO, MAIL FROM and RCPT TO <target>, reading the response code without sending the actual message. A 250 means the mailbox accepts mail; a 550 means it would bounce. You learn the verdict at zero reputation cost. KaijuVerifier returns this in sub-second time per address.
Some servers accept every address at the SMTP layer (catch-all / accept-all) and only bounce later, so KaijuVerifier flags these as "risky" rather than valid. It also checks the address against a list of 72,000+ disposable domains (10-minute inboxes that vanish and bounce), and flags role-based aliases like info@ and admin@ that drive complaints. Each flag is a bounce — or a spam complaint — you avoid.
If your list is already bouncing, you do not need to start over — you need to clean and then maintain. Here is the workflow that brings a list back into the safe zone.
For teams syncing a CRM, KaijuVerifier's signed webhooks (HMAC) let you re-verify a record automatically whenever an address changes, closing the loop without a manual export.
5xx is permanent; retrying it stacks reputation damage. Suppress on the first hard bounce.A hard bounce is a permanent failure — the address or domain does not exist, signalled by a 5.x.x SMTP code. A soft bounce is temporary — a full inbox, server timeout or greylist, signalled by a 4.x.x code. Hard bounces should be suppressed immediately; soft bounces are retried automatically by your ESP.
Keep your total bounce rate under 2%, and ideally under 1%. Hard bounces specifically should stay below about 0.5%. Above 2% is concerning and above 5% risks ESP suspension and blocklisting.
It stops nearly all hard bounces caused by dead or invalid addresses, reaching about 98% accuracy on non-catch-all domains. It cannot guarantee zero soft bounces — a mailbox can fill up or a server can go down after you verify — but those are temporary and far less harmful to reputation.
Every 30-90 days for active lists, plus a verification immediately before any large send, and a real-time check at the point of signup. B2B data decays roughly 2% per month, so the gap between cleans matters.
Yes. Mailbox providers use bounce rate as a hygiene signal. Persistent hard bounces push you into Google and Yahoo enforcement (deferral, spam placement, then rejection), and most ESPs suspend accounts above a 5% bounce rate.
Clean a whole list with the bulk cleaner, or check a single address free on the real-time validator. Free for 500 verifications every month — no credit card.
See plans & pricing