What does each step of the 11-step verification engine actually do?

The Valid Email Checker engine runs eleven distinct checks on every address before producing a final status. Each step examines a different failure mode, so the aggregated result tells you not just whether the address is good but which specific kind of bad it is when something is wrong. The list below walks through each step in order with the underlying mechanic.

The eleven steps in order

1. Syntax validation. The address has to follow RFC 5322 formatting rules: a local part, an @, a domain, a dot, a top-level domain. The check catches typos like gmial.com, missing @ signs, double dots, and forbidden characters. Addresses that fail here return invalid immediately without burning provider quota.
2. Domain DNS lookup. We resolve the domain (the part after the @) to confirm it exists in DNS at all. A domain that does not resolve returns invalid — typos like outlok.com typically fail here.
3. MX record check. The domain may exist but have no mail server configured. Many parked domains and website-only domains land here. No MX means no mailbox can possibly receive mail; the result is invalid.
4. SMTP handshake. We open a TCP connection to the recipient mail server (the one listed in the MX record) and exchange the opening SMTP commands. Failures here often come back as unknown (connection refused, timeout, TLS handshake failure) and trigger the fallback provider path.
5. Mailbox existence (RCPT TO). With the handshake established, we issue RCPT TO: <address> and read the response. A 250 response confirms the mailbox exists; a 550 confirms it does not; a 4xx temporary error often leads to retry or fallback.
6. Catch-all detection. Before trusting a 250 RCPT TO response, we probe with a deliberately-fake address on the same domain. If that also gets a 250, the domain is catch-all and we cannot trust the original 250 as proof the specific mailbox exists.
7. Disposable provider check. We match the domain against a maintained list of throwaway-mail providers like Mailinator, 10MinuteMail, and GuerrillaMail. A hit produces a disposable status regardless of whether the underlying mailbox exists.
8. Role-account detection. The local part is matched against role prefixes (info, sales, support, admin, contact, webmaster, marketing, hr, billing, and around forty more). A hit produces role_account, which is informational rather than disqualifying — the mailbox is real but the engagement risk is higher.
9. Spam-trap detection. We consult provider-maintained databases of known spam-trap addresses and patterns. A hit produces spamtrap, which you should treat as a hard remove from any sending list.
10. Inbox-full detection. Specific SMTP response codes (552, 422, sometimes 452) indicate the mailbox exists but is over storage quota. The result is inbox_full, which is recoverable — re-verify in a week or two.
11. Disabled-account detection. Some servers signal deactivated mailboxes through error codes like 550 5.2.1 or provider-specific reply patterns. The result is disabled, distinct from invalid because the mailbox previously existed.

How the steps combine into a final status

The eleven steps do not all weigh equally. The first three (syntax, domain DNS, MX) gate the rest — if any fail, the engine returns invalid immediately without running steps 4 through 11. Steps 4 to 5 (SMTP handshake, RCPT TO) are the main mailbox check. Steps 6 to 11 are signal-additions that refine the verdict, deciding between safe, catch_all, risky, role, disposable, spamtrap, disabled, and inbox_full based on what each detected.

When the engine cannot reach a definitive verdict despite running all eleven checks (server refused to confirm, provider rate-limited, persistent timeout), the result is unknown and the credit auto-refunds. See the Unknown refund for that mechanic.

Why eleven and not three

A cheap verifier runs only steps 1, 2, and 5 (syntax, DNS, mailbox existence). That catches the obvious failures but misses catch-all domains, disposables, spam traps, and disabled accounts entirely. Customers using a three-step verifier often see clean-looking lists that produce poor results because the engine never flagged the structural risks. Running the full eleven is what produces the 99%+ accuracy figure across the full status set, not just on hard Invalid.

For the broader walk-through of why each step exists see the full how verification works guide.