Verifying a B2B Email List: What Each Check Can Actually Prove
The short answer
A verification pass checks four things in order: syntax, whether the domain accepts mail, whether the mailbox exists, and whether the domain is a catch-all that accepts everything. Only the third is real confirmation. Treat catch-all results as unknown, and remove anything that fails syntax or has no mail server.
"The list is verified" is the most overworked sentence in outbound. Verification is not one check; it is a ladder of checks that produce four different kinds of answer, and only one of them means the mailbox probably exists. Understanding which result you have tells you how to use the list, what bounce rate to expect, and which addresses should never be sent to at all.
Step one: syntax, which is cheaper than it sounds
A syntax check confirms the address is shaped like an email address: something, an at sign, a valid domain. It catches typos in the local part and obvious transcription errors, and it is free to run on any list. It also catches nothing else.
The valuable part is the domain, not the local part. A misspelled domain is the common error in lists built by hand or copied from a printed page, and a domain that does not exist will hard bounce every time regardless of how plausible the mailbox looks.
Step two: does the domain accept mail at all
A DNS lookup for the domain's mail exchanger tells you whether the domain is set up to receive mail. No mail server means no mailbox, no matter what the address looks like. Domains that have expired or been parked also fail here, which is increasingly common on lists more than a year old.
This check is fast and it is the one people skip, because it is less exciting than a mailbox probe. It removes the addresses that could never have worked, and every one of those removed is a hard bounce prevented.
Step three: does the mailbox exist, and the limits of asking
The mailbox check is a conversation with the destination mail server: the verifier asks whether this address is valid and the server answers. When the answer is a clear acceptance or rejection, that is the strongest signal available without sending a message.
It is not a statement about permission, and it is not permanent. A mailbox can be closed the week after you verify it, and a server can answer differently depending on how many times you asked that hour. Verifying is a snapshot, which is why a list should be re-verified before each campaign rather than once a year.
Step four: catch-all, the answer that means "unknown"
A catch-all domain accepts mail for every address at the domain, valid or not, so the mail server cannot tell you whether a specific person exists. Verifiers report these as catch-all or unknown, and the temptation is to keep them because the address looks real.
Keep them, but keep them separate. Sending to a catch-all means accepting a share of hard bounces you cannot predict, and a campaign with many catch-alls will produce bounces that have nothing to do with your list hygiene. Segment them, send to a small sample first, and treat the result as an experiment rather than a delivery.
Worked example: 4,000 addresses, three passes, one campaign
A team assembles 4,000 addresses from three sources: a conference attendee list, a directory export and a set of enquiries from two years ago. They de-duplicate to 3,600, then run the domain check, which removes 210 domains that no longer resolve. That is 210 hard bounces avoided before anything else happened.
The mailbox check returns 2,700 valid, 340 invalid and 350 catch-all. The invalid addresses are dropped. The catch-alls are set aside rather than deleted: they are 350 names that might be real, but sending to them would produce bounces nobody could explain.
The campaign goes to the 2,700 valid addresses in verified batches, with the older enquiries segmented separately. The catch-alls are tested with a 40-address sample later, which produces a mix of delivery and silence. Nothing about the copy changed the outcome; the order of the passes did.
The four results, and what to do with each
| Result | What it proves | Send to it? | Expected behaviour |
|---|---|---|---|
| Valid | The server accepted the mailbox | Yes, if relevant and permitted | Normal delivery or filter decision |
| Invalid | The server rejected the mailbox | Never | Hard bounce, and a reputation cost |
| Catch-all / unknown | The server accepts everything, so nothing is known | Only as a small sample | Unpredictable bounces |
| No mail server on the domain | No mailbox can exist | Never | Certain hard bounce |
| Disposable domain | A temporary mailbox service | No | Address disappears, no reply possible |
| Role address, such as sales@ | A shared inbox, not a person | Sometimes, with different copy | Read by a team and often ignored |
Only the first row is confirmation. Everything else is a decision about risk rather than a fact about the mailbox.
The verification order that saves the most work
- 1De-duplicate first, by address and by domain where the same person appears twice.
- 2Remove anything without a valid domain before spending time on mailbox checks.
- 3Run the domain check for a mail exchanger, and drop the domains that cannot receive mail.
- 4Run the mailbox check and mark valid, invalid and catch-all separately.
- 5Flag disposable domains and remove them, whatever the result says.
- 6Tag role addresses so the copy can address a team rather than a person, or exclude them.
- 7Suppress everyone who has opted out or complained, across every list you hold.
- 8Re-verify anything older than a quarter before the next campaign.
- 9Attack your own list in a re-check and see whether the result is stable. It should be.
Where this connects on this site
- The checks described above run on the email verifier on this site
- For finding the contacts in the first place, see building a list before verifying it
- Segmenting valid from catch-all is a campaign setting on sending to the verified segments separately
What this will not do
- Verification tells you a mailbox exists, not that the person wants to hear from you. Consent is a separate obligation.
- No verifier catches every invalid address, and catch-all domains are structurally opaque. A zero bounce rate cannot be promised.
- Results decay. A list verified last year is not a verified list today.
- Verification does not make a purchased list acceptable. Where consent is required, a clean list of people who did not agree to hear from you is still a problem.
- Nothing here is legal advice on data protection or unsolicited email, which differ by country and by recipient type.
Questions this page gets asked
- Should I delete catch-all addresses?
- Delete them only if you cannot afford any bounces. Otherwise segment them and send a small sample first, because a catch-all result is unknown rather than invalid. Many are real people whose mail server is simply not answering questions.
- How often should a B2B list be re-verified?
- Before every campaign if the list is more than a quarter old. People change jobs, companies rename domains and mailboxes are abandoned. Re-verification is faster than the first pass and prevents the bounces that damage a sender.
- Does a verified address mean the email will reach the inbox?
- No. Verification is about existence; inbox placement is about your domain authentication, your sending reputation and whether the recipient engages. A verified list is the prerequisite, not the outcome.
- Are role addresses like info@ worth sending to?
- They are real but they are read by a team or a ticket system. They can work for a genuine enquiry about the company, and they usually fail for a personal pitch. Tag them and write differently, or exclude them.
- Can I verify a list I did not build?
- You can verify any list you are entitled to use. Verification will not fix the reason you should not have it: a list sold or shared without the recipients agreeing to it carries obligations that cleaning cannot remove.
Last reviewed 2026-10-26. Written for readers in the United States and elsewhere; rules about access, email and consent differ by country, and nothing on this page is legal advice.