How to Verify a B2B Email Address Before You Send

Verifying a B2B email address means confirming a specific mailbox actually exists and accepts mail, before you send anything to it. A plausible-looking address, like a first.last@company.com pattern guessed from a common naming convention, is not the same thing, and treating it as verified is one of the fastest ways to damage a sending domain’s reputation.

Why “looks right” isn’t good enough

Most companies follow a predictable email pattern, which makes guessing tempting: if you know the pattern and the person’s name, you can construct something that looks correct. The problem is that a meaningful share of guessed addresses are wrong, whether because the pattern has exceptions, the person has left, or the domain has changed. Every one of those wrong guesses becomes a bounce.

Why bounces matter more than one missed email

A single bounce is a minor, invisible failure. A sending domain that bounces regularly starts to look, to mailbox providers, like it’s sending badly-targeted or low-quality mail, which affects deliverability for every future email from that domain, including the legitimate ones. One bad guess is a wasted email. A pattern of bad guesses is a deliverability problem that outlasts the campaign that caused it.

How verification actually works

1. Syntax check. Confirms the address is formatted correctly. Catches typos, not wrong guesses.
2. Domain check. Confirms the domain has valid mail server records (MX records) and can receive mail at all.
3. Mailbox check.Uses the mail server’s own protocol (SMTP) to check whether the specific mailbox exists, without actually sending an email to it. This step is what actually distinguishes a real address from a good guess.
4. Catch-all detection. Some domains accept mail to any address regardless of whether a real mailbox exists behind it, which makes the mailbox check unreliable on its own. A proper verification process flags catch-all domains separately rather than reporting them as confirmed.

What “verified” should actually mean

A genuinely verified address has passed all four checks, with catch-all domains flagged rather than treated as a pass. Any process that stops at the syntax or domain check and calls the result verified is doing a fraction of the work and describing it with the full word.

What to do with an address that won’t verify

Don’t send to it, and don’t guess a variation instead. Either find a different, verifiable contact at the same company, or look for the correct address through a different route (a company’s own contact page, a recent press mention, a LinkedIn post with contact details). Sending to an unverified guess to see what happens is how deliverability problems start.

The four checks, in the order they run

1. Syntax. Is it a structurally valid address? Free, instant, and catches almost nothing worth catching, but it is the cheapest filter so it goes first.
2. Domain and MX records. Does the domain exist and does it publish mail exchange records? A domain with no MX record cannot receive mail at all, which immediately rules out a surprising number of scraped addresses.
3. Mailbox acceptance. The real check. A verifier opens an SMTP conversation with the receiving server and gets far enough to learn whether the specific mailbox is accepted, without delivering anything.
4. Catch-all and role detection. Is this a domain that accepts everything, and is this a shared function address rather than a person?

Why catch-all domains are the quiet risk

A catch-all domainaccepts mail to any address, existing or not. The SMTP check therefore returns “accepted” formadeupname@company.com exactly as it does for a real colleague.

The failure mode is worse than a bounce, because it is silent. Your metrics show delivery, nobody replies, and you conclude the message was wrong when the message was never read by anybody. Treat catch-all results as unverified, not as valid, and either confirm the person another way or drop the account.

What verification cannot tell you

• Whether the person still works there. A mailbox often stays live after someone leaves. Cross-check the role against a current source.
• Whether anyone reads it. Deliverable is not the same as monitored, which is most of what is wrong with role accounts.
• Whether you should be emailing them. Deliverability is a technical question; whether the contact is lawful and relevant is a separate one covered in GDPR and B2B cold outreach.

A working policy

Verify at the point of send, not at the point of import. Contact data decays continuously, because people change jobs, so a list verified three months ago is a list of guesses with a certificate attached. Re-verify anything that has been sitting, treat catch-all and role results as failures rather than passes, and accept a smaller list. A smaller verified list outperforms a larger unverified one on every metric that matters, including the one you cannot see until it is too late: your sending reputation.