When Can a Hard-Bounced Address Come Off Your Suppression List?
Keep every 5.1.1 user-unknown bounce suppressed for good, but don't treat every hard bounce as permanent. Bounces caused by the recipient's domain, such as an expired domain, broken DNS or a mail server misconfigured for an afternoon, can recover. Re-check those after a wait, and release any address only on new evidence: the person signs up or orders again, or a fresh mailbox check comes back valid.
The usual rule, suppress on one hard bounce and never send again, is the right default. Its weakness came up in a recent marketing forum thread: a small business forgets to renew its domain, mail bounces for four days, they renew, and that customer never gets another email from you even after ordering again. Suppress too eagerly and you lose real people. Release too easily and you mail dead addresses.
Sort hard bounces by code first
RFC 3463 defines the enhanced status codes inside bounce messages. The ones that matter here:
| Code | Meaning | Can it recover? | Rule |
|---|---|---|---|
5.1.1 |
Bad destination mailbox: the user doesn't exist | Rarely. Mailboxes are seldom recreated, and a recreated one may belong to someone else | Suppress for good |
5.1.2 |
Bad destination system: the domain doesn't exist or has no mail route | Yes, if the domain was lapsed or DNS was broken | Re-check after a wait |
5.4.4 |
Unable to route: no usable MX or address for the domain | Yes, same reasons | Re-check after a wait |
5.2.1 |
Mailbox disabled | Sometimes, for example a returning employee | Re-check after a wait |
5.7.x |
Rejected for policy or security reasons | The address is often fine; the sender was refused | Not a list problem; don't suppress the address for this alone |
Microsoft's 550 5.4.1 Recipient address rejected: Access denied is the exception to reading by number: it's Directory-Based Edge Blocking, meaning the tenant has no such recipient. Treat it like 5.1.1. Our post on hard vs soft bounces covers the soft side, where repeated temporary failures should turn into suppression.
A release policy that holds up
- Store the code and date with every suppression. "Bounced" alone isn't enough to make this decision later. The suppression list merger combines exports from several tools into one file.
- Never release
5.1.1or Microsoft5.4.1automatically. - Re-check domain-level failures once, after a few weeks. Run the domains through the MX lookup first: no MX still means no mail. For domains that resolve again, verify the addresses.
- Release on a new signup or order. A customer who types the address into your checkout again is evidence. Verify at that moment, then release if valid.
- Suppress again on any new hard bounce, permanently. One second chance, not a loop.
Platform lists are sticky on purpose
Your sending platform keeps its own list. Amazon SES's account-level suppression list adds only hard bounces, and addresses "remain there until you remove them". SES also notes that a bounce from an address you removed from your list but that still sits on its global list "still counts toward the bounce rate for your account." Other platforms behave similarly. Releasing an address in your own database doesn't release it in your ESP, and the reverse is true too, so keep one master list and sync it. Our guide to the cold email suppression list covers building that master list.
Verify before you release
Re-checking is where this goes wrong in practice: someone exports "old bounces", decides they're probably fine, and mails them all at once.
- Upload the candidates for release on the verify page. Every address gets a live mailbox check, and valid, risky and invalid download as separate files.
- Release only the valid file. Leave risky and invalid suppressed.
- Mix released addresses into normal sends rather than one batch, so a bad pocket can't spike a single campaign.
Where SimpleVerifier fits
The merger and MX lookup are free. For mailbox checks, the first 100 are free with a Google sign-in on the verify page. Starter is $9 a month for 2,500 checks, and Pro is $39 a month with the first 100,000 checks a month at full speed, then slower, never cut off. One-time packs of 10,000 checks for $15 never expire, which suits an occasional re-check of suppressed addresses. See pricing.
Common questions
Should I ever remove a hard bounce from my suppression list?
Sometimes. A 5.1.1 user-unknown bounce should stay suppressed. A bounce caused by the domain (it expired, its DNS broke, its mail server was misconfigured) can be temporary. Re-check those after a few weeks and release the ones that verify as valid.
What if a suppressed customer buys again?
A new order or signup with the same address is new evidence the mailbox works. Verify the address at that moment and release it if it comes back valid. If it bounces again, suppress it for good.
How long should I wait before re-checking a domain-level bounce?
There is no standard. A few weeks gives a lapsed domain time to be renewed or a misconfigured server time to be fixed. Re-check once; if it still fails, keep it suppressed.
Does releasing addresses risk my sender reputation?
Only if you release without checking. Re-verify every address before release, send to them in a normal campaign rather than all at once, and suppress again on any new hard bounce.
Check your list before you send
Real mailbox checks over SMTP, and nothing is sent to the address. Sign in with Google and your first 100 email checks are free, no card. Plans for bigger lists are on the pricing page.