Email Verification Checks Explained: What Each Layer Actually Does

Email verification tools all talk about "validation," but they do not all check the same things.

That matters, because a result is only as good as the checks behind it. A tool that stops at domain/MX checks will confidently mark an address as valid while that address bounces hard on delivery. A tool that does SMTP probing but has no special handling for Microsoft 365 will return false positives on a large share of B2B lists.

Understanding what each check layer does — and what it misses — helps you evaluate tools based on what they actually measure, not what the marketing copy says.

Layer 1: Syntax validation

What it checks: Does the address parse as a structurally valid email address?

Syntax validation applies the rules from RFC 5321 and 5322: exactly one @ sign, a valid local part, a valid domain. It catches obvious garbage quickly.

What it catches:

• Missing @
• Multiple @ signs
• Invalid characters in the local part
• Malformed domains (missing TLD, double dots, etc.)
• Addresses that are just not email addresses

What it misses: Everything about whether the domain exists or the mailbox is real. [email protected] passes syntax validation. So does [email protected] even if the specific mailbox name does not exist.

Signal strength: High precision for what it measures, low coverage. You will not get false positives on syntax errors, but syntax-passing addresses can still be completely undeliverable.

Every tool does this. It is table stakes.

---

Layer 2: Domain existence and MX records

What it checks: Does the domain resolve in DNS, and does it have MX records configured to receive mail?

A domain without MX records cannot receive email, regardless of what the local part is. If DNS returns no MX records, the address is undeliverable — full stop. This check is reliable and fast.

What it catches:

• Addresses on domains that do not exist
• Addresses on domains with no MX records
• Addresses on expired or abandoned domains

What it misses: Whether any specific mailbox exists on a domain with valid MX records. A domain might have perfect MX configuration and thousands of completely non-existent mailbox names. MX passing means mail can theoretically arrive at the domain, not that it will be accepted for a specific address.

Signal strength: Reliable negative signal. Failing MX check = definitely undeliverable. Passing MX check = no information about the specific mailbox.

---

Layer 3: Typo detection

What it checks: Does the domain resemble a common provider misspelling?

Lists assembled from manual data entry, form submissions, or older CRM imports contain typos. gmial.com, yahooo.com, outloook.com, gnail.com — these look almost right, but they are not.

What it catches:

• Transposition errors (gmial.com)
• Repeated characters (yahooo.com)
• Common substitution errors (hotmial.com)

What it misses: Novel misspellings that do not match known patterns, and intentional throwaway addresses on real domains.

Signal strength: High precision when the pattern lists are comprehensive. Genuinely useful for cleaning data-entry-sourced lists.

---

Layer 4: Disposable and role address detection

What it checks: Is this address on a known temporary inbox provider, or is it a role address that exists but is not a personal inbox?

Disposable addresses are from services like Mailinator, Guerrilla Mail, Temp-Mail, and hundreds of similar providers. The addresses exist temporarily, then expire. They are useless for any list that needs ongoing reachability.

Role addresses — info@, noreply@, support@, admin@, contact@ — often technically exist but reach a shared inbox monitored by multiple people or a ticketing system. For cold outreach, they are a bad choice. For newsletter sends, they produce poor engagement metrics. For compliance reasons, they can also be risky: some organisations route abuse@ and postmaster@ directly to compliance monitoring.

What it catches: Addresses that exist but should be excluded for list hygiene reasons.

What it misses: Custom temporary domains not in the detection list, and role-like addresses at companies that use non-standard naming (team@, hello@).

Signal strength: Useful signal for outreach and marketing use cases. Lower value for pure deliverability checking.

---

Layer 5: SMTP mailbox verification

What it checks: Does this specific mailbox actually exist on the mail server, at the protocol level?

This is where the real deliverability signal lives. The verifier opens a TCP connection to the mail server, negotiates with EHLO, presents a MAIL FROM address, and then issues RCPT TO for the address being verified. The server's response code tells you directly:

• 250 OK — the server is willing to accept mail for this address
• 550 5.1.1 User unknown (or similar 5xx) — the mailbox does not exist
• 450 / 452 / 421 — temporary deferral (greylisting, rate limiting, server busy)

This is not guessing based on patterns. It is the same SMTP handshake a real sending mail server performs when delivering a message — except the verifier stops before the DATA command, so no actual email gets sent.

What it catches: Mailboxes that do not exist on domains that have valid MX records. This is the single largest category of bad addresses that pass layers 1-4.

What it misses: Catch-all configurations (where the server accepts RCPT TO for any address regardless of whether a real mailbox exists), and Microsoft 365's EOP accept-everything behaviour (see Layer 6).

Signal strength: High confidence for unambiguous responses. A hard 5xx is a reliable hard bounce indicator. A 250 OK on a non-catch-all server is a reliable deliverable indicator. Ambiguous 4xx responses require classification.

Modern considerations: Many servers now require the verifying client to present a valid HELO/EHLO hostname and a MAIL FROM from a domain with matching DNS. Verifiers that do not configure this correctly get rejected before they can probe anything. MailCull's engine sends a MAIL FROM with a properly configured domain and EHLO hostname that has matching PTR and A records — which is why it gets through where some cheaper tools do not.

---

Layer 6: Microsoft 365 HTTP enumeration

What it checks: Does this specific M365 account exist, using Microsoft's own authentication APIs rather than SMTP?

Microsoft 365 is the most important special case in modern email verification. M365's Exchange Online Protection (EOP) layer is designed to accept RCPT TO for any address on a tenant — even non-existent ones — and generate a non-delivery report internally. This means a raw SMTP probe against an M365 domain will return 250 OK for addresses that will hard-bounce when mail is actually sent.

For B2B lists, where a significant fraction of domains are on M365, this is not a minor edge case. It is a systematic false-positive problem.

The solution is to query Microsoft's authentication endpoints directly. These endpoints power Microsoft's own login flow, which means they accurately reflect whether a given username has an active account:

Step 1 — GetUserRealm: Confirms whether the domain routes to M365. If it does not, skip to SMTP. If it does, continue the cascade.

Step 2 — GetCredentialType: Queries whether the specific username (the local part of the email address) has an active M365 account. Returns structured JSON including account presence indicators.

Step 3 — Autodiscover v1: Cross-references account existence against Microsoft's Autodiscover service, which is used by email clients to locate mailbox configuration.

When all three cascade steps return signals consistent with an active account, the HTTP enumeration verdict is deliverable — with high confidence, because Microsoft's own infrastructure confirmed it.

What it catches: Non-existent M365 mailboxes that pass SMTP probing because EOP accepts everything. The false-positive rate on unverified M365 lists from SMTP-only tools is meaningful.

What it misses: Federated or heavily customised tenants where the cascade signals are ambiguous. MailCull handles these by cross-referencing against the SMTP result — if the cascade says deliverable but SMTP disagrees, the result is risky with a m365_smtp_disagreed flag rather than a false confidence in either direction.

---

Layer 7: Catch-all detection

What it checks: Is this mail server configured to accept all RCPT TO commands regardless of mailbox existence?

Some servers are configured as "catch-all" — they accept any address at the domain and handle routing (or dropping) internally. A catch-all server will return 250 OK for [email protected] and [email protected] identically.

A verifier that does not detect catch-all configurations will mark all addresses on catch-all domains as deliverable, even though they may have very high bounce rates in practice.

Catch-all detection works by probing with a mailbox name that is extremely unlikely to be real (a long random string), then observing whether the server accepts it. If it does, the domain is a catch-all and individual SMTP verdicts are unreliable.

What it catches: Domains where SMTP verification is systematically unreliable.

What it does with them: Typically marks all addresses on catch-all domains as risky (present, but with uncertain individual accuracy) rather than as deliverable.

---

How these layers combine in practice

The picture that emerges from all the layers together is significantly different from what any single layer sees:

The addresses in rows 7 and 8 are where tools that stop at SMTP without M365 handling get it wrong. Row 7 looks deliverable to an SMTP-only tool. It hard-bounces.

What MailCull checks

MailCull's deep-scan engine runs all of these layers: syntax, domain/MX, typo, disposable/role, SMTP mailbox verification, M365 HTTP enumeration (three-step cascade), and catch-all detection. Every deep-scan result includes an evidence chain that records which signals fired and how they combined into the final verdict.

The four-status output vocabulary — deliverable, risky, undeliverable, unknown — stays frozen across all check layers. What changes per address is the reason field in the evidence chain, which tells you specifically what the signal was: smtp_confirmed, m365_http_enum, m365_smtp_disagreed, smtp_catchall, smtp_greylisted, and so on.

That specificity is what lets you make decisions rather than just act on a black-box verdict.

---

Verify your list with MailCull's full check stack →