How email verification works, step by step

An email verifier runs a short, mechanical sequence against each address and then classifies the result. There is no intelligence in the core of it, which is good news: once you know the steps, you know exactly how much to trust each status.

The sequence

1. Syntax. Parse the local part and domain against the rules for an address. Catches typos in format, not typos in names. jane.smtih@example.com is perfectly valid syntax.

2. Domain and MX. Resolve the domain and look for MX records. No MX and no fallback A record means the domain cannot receive mail at all — a definite invalid. This step also catches expired and parked domains, which is where a lot of an old list goes.

3. The SMTP probe. Connect to the MX host and start a transaction without ever sending the message:

220 mx.example.com ESMTP ready
EHLO verifier.example.net
250-mx.example.com
250 STARTTLS
MAIL FROM:<probe@verifier.example.net>
250 2.1.0 Sender ok
RCPT TO:<jane@example.com>
550 5.1.1 User unknown
QUIT
221 Bye

The answer to RCPT TO is the whole test. A 250 suggests the mailbox exists; a 550 5.1.1 says it does not. The probe stops before DATA, so no mail is sent.

4. Catch-all detection. Probe a random address that certainly does not exist, such as zz-no-such-user-9471@example.com. If the server accepts it too, the domain is accept-all and the probe proves nothing about your real address. Plenty of corporate domains are configured this way deliberately.

5. Pattern classification. Role accounts (info@, sales@, support@, admin@), disposable and throwaway domains, and free-mail domains are identified from lists and patterns rather than from the server. Useful, and only as current as the list behind it.

Why so much B2B data comes back "unknown"

The probe depends on the receiving server answering honestly, and the large providers have good reasons not to. Google Workspace and Microsoft 365 both rate-limit and in places answer uniformly to probing connections, precisely because address harvesting uses the same technique. Greylisting adds a temporary 4xx on first contact; tarpitting slows the connection down. A verifier that respects all of that will back off and report "unknown" rather than guess.

So on a B2B list, expect a meaningful share of accept-all and unknown results. That is the mechanism working correctly, not a weak vendor.

What each status means, and what to do

What verification cannot do

• It cannot detect spam traps. A trap is a syntactically perfect address on a real domain that accepts mail. No probe distinguishes it from a person. Any vendor claiming trap detection is claiming something the protocol does not support.
• It cannot predict complaints. A valid, deliverable address belonging to someone who never asked to hear from you is exactly the address that generates a spam report.
• It cannot tell you whether someone still works there. The mailbox often stays active after the person leaves, sometimes as a catch-all for their replacement.
• It cannot clean a purchased list into a good one. It reduces hard bounces, which is the smaller half of the problem.

Where this fits in a sending process

1. Normalise and deduplicate first — lowercase, trim, drop obvious malformations. Free, and it reduces how much you pay to verify.
2. Pull your platform's existing suppression list (Amazon SES's account-level list, SendGrid's five suppression lists, Mailgun's per-domain suppressions) and remove those addresses from source before verifying. No point paying to check an address you may not mail.
3. Verify, then route by status as in the table above.
4. Send to verified-valid, engaged recipients first on any new domain. Bounce rate is a ratio, and good traffic early keeps it low.
5. Re-verify on a schedule, and remove hard bounces from the system of record every time — not just from the sending tool.

What not to do

• Do not delete everything marked risky. On B2B domains that bucket is mostly catch-all corporate servers, including real buyers.
• Do not run your own bulk SMTP probes from your sending IP. You will be rate-limited, and the pattern looks like harvesting.
• Do not verify and then import at full volume the same day. Clean data still has to be ramped.
• Do not treat a verification pass as a deliverability fix. Authentication, reputation and consent are separate problems with separate solutions.

MailPilot does not verify lists; it works on the sending side. It warms mailboxes over OAuth (Gmail, Outlook) or SMTP and IMAP (SendGrid, Amazon SES, Mailgun, Postmark, custom SMTP), checks SPF, DKIM and DMARC, measures real inbox placement per provider, and tracks per-mailbox reputation daily — so when bounces or complaints move after an import, you can see which mailbox and which provider it started with.