Recap
- Verify before you send. Bounces are the fastest way to burn a sending domain, and verification stops most of them.
- A full check runs four stages: syntax, domain and MX records, an SMTP probe of the mailbox, and catch-all detection.
- Accept-all domains say yes to every address, so a probe cannot confirm the mailbox. Treat those results as unknown, not valid.
- Run verification right before the first send, and re-verify any list older than a few weeks.
Verifying an email address before you send means confirming three things in order: the address is formatted correctly, the domain is set up to receive mail, and the specific mailbox actually exists. Do that and most of your bounces disappear before they ever happen. Skip it and you teach Gmail and Outlook that you mail dead addresses, which is exactly the reputation you do not want.
Why does list quality decide deliverability?
Because mailbox providers judge you by your bounces. Every send to a dead address comes back as a hard bounce, and a pile of hard bounces is the clearest signal that you did not build or clean your list. Providers respond by routing more of your mail to spam, including the messages to people who would have replied.
This is the trap that catches new senders. You buy or scrape a list, fire it off, and a third of it bounces. Now your domain is flagged, and the 70 percent of addresses that were real never see your message either. List quality is the input everything downstream depends on.
How does email verification actually work?
A verifier runs a sequence of checks, each one cheaper and faster than the next one down. It stops early when an address fails, so it does not waste an SMTP probe on an address that is already malformed. The four stages look like this.
| Stage | What it checks | Catches |
|---|---|---|
| Syntax | The address is well formed (one @, valid characters, a real-looking domain) | Typos, missing @, garbage entries |
| Domain and MX | The domain exists and publishes MX records that point to a mail server | Dead domains, parked domains, sites with no mail setup |
| SMTP probe | Opens a conversation with the mail server and asks if the mailbox exists, without sending anything | Mailboxes that were deleted or never existed |
| Catch-all detection | Tests a fake address on the same domain to see if the server accepts anything | Accept-all domains where the probe cannot be trusted |
The first two stages are quick and definitive. Bad syntax is always bad. A domain with no MX record cannot receive mail, full stop. The interesting work happens in the last two.
What does the SMTP probe really do?
The probe connects to the recipient's mail server and walks partway through the conversation a real send would have. It says hello, names a sender, then names the recipient and reads the server's response. A clean acceptance suggests the mailbox is live. A rejection at that step means the mailbox is not there. The probe never delivers a message, so the person is none the wiser.
It is not perfect. Some servers delay unknown senders on purpose, a tactic called graylisting, and some refuse to confirm anything to reduce their own spam load. Good verifiers retry, respect rate limits, and probe from warmed IPs so they are not mistaken for an attacker. That is the main reason to use a dedicated verifier instead of hammering mailboxes from your own sending IP, which can get that IP blocked.
Why are accept-all domains a problem?
An accept-all domain, also called catch-all, is configured to say yes to mail for any address on the domain, whether the mailbox exists or not. Plenty of companies run this way so nothing addressed to them ever bounces. The catch is that it blinds the SMTP probe. The server accepts a real mailbox and a typo with the exact same response.
So a verifier cannot mark a catch-all address as valid. The honest label is risky or unknown. The right move is to hold those addresses out of your first big send, mail a small test batch, and watch the result. The ones that stay quiet (no bounce) earn their way into the main campaign. The ones that bounce get cut. You are using a controlled send to learn what the probe could not tell you.
When should you verify, and how often?
Verify right before the first send to any list, every time. Verification is a snapshot, not a permanent stamp. B2B contacts churn fast: people change jobs, IT retires old mailboxes, and small-company domains lapse. An address that verified clean two months ago can be dead today, and you will not know until it bounces in front of a provider that is watching.
Build it into the workflow instead of treating it as a one-off. A simple discipline that holds up: verify on import, re-verify anything older than two or three weeks before it goes out, and stop sending to an address the moment it hard bounces once. This is the kind of housekeeping a tool like LaunchSurface runs on its own before every send, but the rule matters whether software or a person enforces it.
What good looks like before you hit send
A short pre-send checklist keeps you honest.
- Every address passed syntax and MX. No malformed entries, no dead domains in the batch.
- Hard bounces and known-bad addresses are removed, not just hidden. Keeping them on the list to mail later is how reputation slips back.
- Catch-all addresses are tagged and either held back or sent in a small test batch first.
- The list is fresh. Verified within the last couple of weeks, not last quarter.
- Your own sending is authenticated. Verification protects the list side, but SPF, DKIM, and DMARC protect the sender side, and you need both.
Verification will not make a weak offer land or fix a message nobody wants to read. What it does is protect the asset that every campaign rides on: a domain that providers still trust. Spend the few minutes to clean the list and you keep that trust. Skip it and you spend weeks earning it back.
