Email list verification means checking every address before you send to it: that it’s well-formed, isn’t a typo of a big provider, isn’t disposable, sits on a domain that accepts mail, and doesn’t belong to someone who already bounced or opted out. Some services also ask the recipient’s mail server whether the mailbox exists. It matters because bounces tell providers your list isn’t maintained — Gmail may stop a personal account from sending for 24 hours when many of its messages bounce. No check proves a person reads an inbox; aim to keep cold-campaign bounces under about 2%.
Key takeaways
- Hard bounces (5.x.x) are permanent: suppress the address. Soft bounces (4.x.x) are temporary: retry, and suppress if they persist.
- Syntax, typo, disposable and DNS checks catch the cheap failures. Mailbox probes catch more, but many servers block them or answer “unknown”.
- Catch-all domains accept every address at first, so “unknown” doesn’t mean “valid”.
- No provider publishes a bounce limit. Keep cold campaigns under about 2%, and stop at 5%.
- A suppression list of bounces, unsubscribes, complaints and objections must cover every mailbox and every future import.
Hard bounces and soft bounces
When a message can’t be delivered, the receiving server answers with a status code defined in RFC 3463. The first digit matters most: 5 means a permanent failure (a hard bounce) and 4 a temporary one (a soft bounce). The rest says why. The examples below are quoted from Google’s Gmail SMTP error reference, except the last row, which groups policy codes from Gmail and Outlook.com:
| Code | What the server says | What to do |
|---|---|---|
550 5.1.1 | “The email account that you tried to reach does not exist.” | Hard bounce: suppress the address. |
553 5.1.2 | “We weren’t able to find the recipient domain.” | Hard bounce: suppress, and check the domain for a typo. |
550 5.2.1 | “The email account that you tried to reach is inactive.” | Hard bounce: suppress. |
452 4.2.2 | “The recipient’s inbox is out of storage space.” | Soft bounce: retry later; suppress if it keeps happening. |
552 5.2.2 | “The recipient’s inbox is out of storage space and inactive.” | Hard bounce: suppress. |
421 4.4.5 | “Server busy, try again later.” | Temporary: retry automatically with a delay. |
4.7.28, 5.7.26, 5.7.515 | Rate limiting, or authentication and policy failures | Not the address’s fault. Fix your sending before you send more, and don’t suppress the address. |
The last row matters. A policy rejection looks like a bounce in most tools, but it tells you something about your own setup — failed authentication, a rate limit, a blocklisting — not about the recipient. Counting it as a bad address hides the real problem.
Why your bounce rate matters
A hard bounce tells the receiving provider you sent to an address that doesn’t exist, which people mailing their own contacts rarely do. Providers act on it:
- Gmail’s help says that if a large number of your messages can’t be delivered because addresses are invalid, you may have to wait 24 hours before sending again.
- Google’s sender guidelines tell senders to reduce volume when messages start bouncing and to unsubscribe recipients who have bounced several times.
- Microsoft asks high-volume senders to “remove invalid addresses regularly”, and Yahoo asks senders to monitor hard and soft bounces and remove invalid recipients promptly.
The law takes an interest too. Australia’s Spam Act 2003 prohibits sending a commercial message to a non-existent address unless you had reason to believe it existed. Under the US CAN-SPAM Act, using addresses generated automatically “by combining names, letters, or numbers” makes any other violation an aggravated one.
What bounce rate is acceptable?
No mailbox provider publishes a bounce-rate threshold. These are the working levels we suggest for cold email, measured per mailbox over the past week:
| Bounce rate | What it suggests | What to do |
|---|---|---|
| Under 2% | A verified list with normal decay | Keep sending; suppress each bounce as it arrives |
| 2–5% | Stale data, a poor source, or unchecked addresses | Pause new enrollments and re-check what’s waiting |
| Over 5% | A list problem big enough to hurt the sending domain | Stop sending to that list until it has been cleaned |
What each check catches — and what it misses
| Check | Catches | Can’t tell you |
|---|---|---|
| Syntax | Addresses that can’t exist: a missing @, spaces, illegal characters, addresses that are too long | Whether a well-formed address is real |
| Provider rules | Addresses a big provider could never have issued. Gmail usernames are 6–30 characters of letters, numbers and periods, so a@gmail.com can’t exist | Anything about other domains |
| Typo domains | Slips such as gmial.com or hotmial.com, which can still have mail servers because someone registered the typo | Typos of smaller company domains |
| Disposable domains | Throwaway inbox services | New services not yet on any list |
| Role addresses | Shared mailboxes such as info@, sales@ and support@ (see RFC 2142) | Whether a person reads them. They deliver, but rarely suit one-to-one outreach |
| DNS and MX | Domains with no mail servers, domains that publish a null MX to say they accept no mail, and MX hosts that don’t resolve | Whether a particular mailbox exists |
| SMTP mailbox probe | A server that answers 550 5.1.1 for the address during a test conversation that stops before any message is sent | Anything on catch-all servers, which accept every address; graylisting servers, which defer strangers at first; or providers that block probes |
| Suppression and history | Addresses that already bounced, unsubscribed or complained | Problems with addresses you’ve never sent to |
A domain with no MX record but an address (A) record can technically still receive mail: RFC 5321 treats the domain itself as an implicit mail server. It can’t be ruled out, but treat it as risky rather than valid. The SMTP standard’s own VRFY command, designed for checking addresses, is often switched off; RFC 5321 allows sites to disable it for security reasons.
One limit applies to syntax and DNS checks alike: they can’t see that someone left the company last month and their mailbox was deleted. The domain is healthy and the address looks perfect. Only the receiving server knows — through a probe, if it answers honestly, or through a bounce. That is why verified lists still bounce, and why every bounce must feed straight back into suppression.
Email validation vs verification
The two words are used loosely, and many services treat them as the same thing. A useful distinction:
- Validation
- Checks you can make without contacting the recipient’s mail server: syntax, provider rules, typos, disposable and role addresses, DNS, and your own history. Fast and safe, and the recipient’s server never hears from you.
- Verification
- Validation plus a test conversation with the recipient’s server, stopped before any message is sent, asking whether it would accept mail for the address. More informative where servers answer honestly; inconclusive on catch-all and graylisting servers.
Neither proves a human reads the inbox. Both reduce bounces; neither eliminates them.
Catch-all domains and unknown results
A catch-all, or accept-all, domain accepts mail for any address at first, real or not, and then delivers it to a shared mailbox or bounces it later. A probe gets the same yes for a real address and an invented one, so results come back as “unknown” or “accept-all”. Treat them as unverified, not valid:
- Send to them after the verified part of the list, in small batches.
- Track their bounce rate separately, so a bad batch doesn’t hide in the average.
- Prefer addresses you have a source for — the company website, a reply, an introduction — over guessed patterns such as first.last@.
A list-cleaning workflow
This is how to verify email addresses before sending. Run it before every campaign, cheapest checks first, to reduce your email bounce rate before it can cost you anything.
- Start from a lawful, relevant source. Don’t buy lists; Google and Yahoo both say not to. Note where each contact came from, since several countries’ laws expect you to know — see cold email laws.
- Normalize and de-duplicate. Trim spaces, lowercase the domain, and remove duplicates across every sheet and import.
- Fix or remove typos. Correct an obvious slip such as
gmial.comonly when you’re sure what was meant; otherwise remove the address. - Remove what can’t deliver. Invalid syntax, disposable domains, and domains with no mail servers or a null MX.
- Decide on role addresses. Keep info@ or sales@ only if a shared inbox is genuinely the right recipient.
- Apply your suppression list. Remove everyone who has bounced, unsubscribed, complained or asked not to be contacted, at every address you hold for them.
- Set the unknowns aside. Catch-all and unverifiable addresses go into a separate, later batch.
- Send a small first batch and watch it. If the first hundred sends bounce above 2%, stop and look at the source before sending the rest.
- Feed results back. Suppress every hard bounce immediately, and re-check any list that has sat unused for a few months — people change jobs, and B2B data goes stale.
Suppression lists: the list you never send to
A suppression list is the set of addresses that no campaign, sequence or mailbox in your company may email. It should hold:
- hard bounces;
- unsubscribes, whether from a link in the email or a one-click header;
- spam complaints;
- replies asking you to stop, however they’re worded;
- objections and “do not contact” requests that arrive any other way.
Three rules make it work. It applies everywhere — every mailbox and every sequence, not just the campaign where the person opted out. It survives imports, so a new spreadsheet never brings a suppressed address back. And it is kept: under the GDPR, once someone objects to direct marketing, their data “shall no longer be processed for such purposes”, which in practice means keeping just enough to make sure you never contact them again. In the US, the FTC’s CAN-SPAM guide requires opt-outs to be honored within 10 business days and prohibits selling or transferring the addresses of people who opted out.
How SalesScope handles this
In SalesScope, every address is checked before any bulk send: a campaign or sequence won’t enroll or send to addresses nobody has checked, and one press validates the ones that are waiting. Validation runs in the background across tens of thousands of addresses, and it checks:
- syntax and the signup rules of major providers;
- typos of major provider domains, such as
gmial.com; - disposable domains and role addresses;
- DNS: whether the domain has mail servers or publishes a null MX (RFC 7505). Domains whose mail servers don’t resolve, or that have only an address record, are held back from bulk sends rather than marked invalid;
- history: your workspace’s suppression list of bounced, unsubscribed and complaining addresses, and domains where a third of your mail has bounced or a bounce said the domain itself is gone.
SalesScope checks the address and its domain. It does not probe individual mailboxes over SMTP, so it can’t promise that a specific inbox exists. What holds bounces down after that is the feedback loop: one bounce suppresses the address across the workspace, and the bounce circuit breaker puts a mailbox on hold for a 48-hour cooldown — pausing every active sequence on it until the rest of their audience is validated and someone resumes them — when its bounce rate over the past 7 days passes the workspace limit (5% by default, once it has at least 50 sends). See email verification.