How verification works: the 11-step verification engine

When you paste an address into the dashboard verifier and click Verify, or push a list through the bulk pipeline, or hit the API — every single address goes through the same engine. It is not a single test; it is a chain of 11 distinct checks, each looking at a different way an email address can fail. The aggregate result becomes the status you see in your results, and the score comes from how clean the chain ran.

This page is the long version. If you just want the short version: 11 checks, real SMTP-level handshakes, no emails ever sent to your contacts, results in seconds, never store the raw list past 15 days, never share or resell.

The 11 checks

Every address flows through these in order. The first one that produces a definitive negative result short-circuits the rest — there is no point checking the mailbox on a domain that does not exist. Each check maps to one of the canonical status values you see in your results.

Check 1 — Syntax validation

First, the address has to actually look like an email. There is a formal spec for what email addresses can contain (RFC 5321/5322), and a lot of typos break it before any network call is even attempted. We check the local part (the bit before @), the @ itself, and the domain structure.

• ✅ john.smith@company.com — well-formed
• ❌ john.smith@company — missing the top-level domain
• ❌ john.smith.company.com — no @
• ❌ john @company.com — whitespace inside the local part
• ❌ john@@company.com — duplicated separator

You would be surprised how often gmial.com, yahooo.com, or hotmial.com slip into a list from form submissions. Syntax catches the obvious mistakes; the deeper checks below catch the subtle ones.

Syntax-invalid addresses come back with status invalid.

Check 2 — Domain DNS lookup

Once the syntax passes, we ask the internet whether the domain exists at all. john@totally-fake-company-12345.com is well-formed but the domain has no DNS records — there is no server out there to ask. This check confirms the domain is registered and resolving.

Failing this check returns invalid (the address cannot exist if the domain does not).

Check 3 — MX record check

A domain can exist for a website but never accept mail. The MX (Mail Exchange) record is the DNS entry that says "send mail for this domain to *this* server". If a domain has no MX records, no mailbox there can receive mail, regardless of how the address is spelled.

No MX records → invalid. This is also where the provider catches "dead server" cases — MX records pointing at a server that no longer responds.

Check 4 — SMTP handshake

SMTP is the protocol mail servers speak to each other. Now that we know there is a server, we open a TCP connection to it and start a real SMTP conversation. The server responds with capabilities, we say hello (EHLO), and the connection is established.

Sometimes this step fails on its own — the server is unreachable, behind an aggressive anti-spam system, or temporarily throttling. In those cases the result is unknown and the credit is refunded automatically. We do not bill for answers we could not produce.

Check 5 — Mailbox existence (RCPT TO)

This is the heart of verification. Once we are in an SMTP conversation, we ask the server about the specific recipient using RCPT TO. The server checks its mailbox table and tells us whether that exact address exists. The actual exchange looks something like this:

> EHLO verifier.example.com
< 250 mx1.recipient.com Hello
> MAIL FROM:<probe@verifier.example.com>
< 250 OK
> RCPT TO:<john@company.com>
< 250 OK   ← mailbox exists
> QUIT
< 221 Bye

A 250 OK on the RCPT TO line means the mailbox is accepting mail. A 550 or 551 response means it does not exist or is rejecting. Either way, we close the connection without sending an actual message. Your contacts never see anything from us — no test email, no probe message, nothing.

Result mapping: mailbox accepts → safe. Mailbox rejected → invalid.

Check 6 — Catch-all detection

Some domains are configured to accept mail addressed to any local part, even ones that do not correspond to a real mailbox. The classic example: a small business that wants to make sure no email ever gets lost, so they tell their server to accept everything addressed to the domain.

> RCPT TO:<does-not-exist-zzz-1234@catchall-company.com>
< 250 OK   ← server says yes to anything

On a catch-all domain, the mailbox-existence check above always returns OK — so we cannot tell whether the specific recipient is real or whether the server would just accept anything. We detect this by probing with a randomly generated local part on the same domain and seeing if the server still says yes. If it does, the domain is catch-all and the original result is downgraded from safe to catch_all.

See the catch-all guide for the full breakdown of how to handle these in your campaigns.

Check 7 — Disposable provider check

A disposable email address is a throwaway — Guerrilla Mail, 10MinuteMail, Mailinator, Temp Mail, and a long tail of similar services. People use them to get past signup walls without giving a real address. The mailbox is real but the person behind it has no intention of staying reachable.

We maintain a regularly updated list of disposable domains and check every address against it. Any hit comes back as disposable. Reasoning: even though these mailboxes technically accept mail, the recipient is gone within minutes to days, and sending campaigns to them inflates your bounce rate and drags down deliverability.

Check 8 — Role-account detection

Role accounts are addresses tied to a job function rather than an individual person — info@, support@, sales@, admin@, billing@, hr@, webmaster@, and so on. They are real, deliverable addresses, but they behave differently from personal mailboxes:

• Multiple people may read them (or no one in particular).
• They are often routed into ticketing systems.
• Marketing email sent to a role account tends to get marked as spam more aggressively than to a personal address.

We flag these as role_account (or role in some provider modes) so you can segment them — they are still safe to send to, but expectations should be lower.

Check 9 — Spam-trap detection

Spam traps are honeypot addresses used by ISPs, anti-spam consortia, and email-deliverability watchdogs to catch spammers. They look like ordinary mailboxes but no human reads them — they exist purely to identify senders who are mailing addresses they should not have.

Two flavors exist:

• Pristine traps. Addresses created specifically as traps, never used by a person. If your list hits one, you likely scraped data or bought a list from a sketchy source.
• Recycled traps. Real addresses abandoned long enough that ISPs repurposed them. That old 2018 contact who left the company? Their address might be a recycled trap now.

We compare against known trap lists and flag any hit as spamtrap. See what is a spam trap for the longer breakdown. Hitting traps causes serious deliverability damage, so the right move is to drop them immediately.

Check 10 — Inbox-full detection

The mailbox exists, but the server reports it is over quota and not accepting new messages right now. This usually means the account is abandoned (the owner stopped clearing it years ago) or temporarily inundated.

Returns inbox_full. Practically: try again in 30 days, or drop the address. Persistent inbox_full is a strong signal of an inactive account.

Check 11 — Disabled-account detection

A mailbox that existed at some point but the provider has deactivated — terminated employee, account suspended for terms-of-service violation, dormancy timeout, security incident. The server still knows about the address but explicitly rejects mail to it.

Returns disabled. Different from invalid (mailbox never existed): disabled means it was real, it just is not anymore. The action is the same — drop it.

How the checks combine into a status and score

Each address runs through all the checks that apply (the engine short-circuits when a definitive answer is reached — no need to check spam-trap status on a syntax-invalid address). The first definitive result becomes the status. Confidence score sits on a 0–100 scale and reflects how cleanly the chain ran:

For the action you should take with each one, see result types explained.

What we never do

Never send test emails to your contacts

Some lower-tier services literally send a test email and watch what happens. That is a terrible idea: it triggers spam filters, hurts your sender reputation, and reveals to recipients that they are on a list being checked. Our verification is entirely passive — TCP handshakes and DNS lookups. Your contacts have zero idea anything happened.

Never store the raw list past 15 days

Bulk uploads are auto-deleted from our servers 15 days after the job completes. The deletion is automatic, not "we might get around to it" — a scheduled cleanup function (gdpr-cleanup) wipes verified data when retention expires. The verification results stay accessible in your account so you can review history; the raw uploaded list does not.

See how we protect your data for the full data-handling story.

Never share or resell your lists

Your data is yours. We do not sell it, share it, train models on it, or use it for any purpose beyond running the verification you asked for. Our business is selling verifications. We have no incentive to do anything else with your data and no plan to start.

Why distributed verification matters

We route verifications across multiple verification providers and multiple verification servers. This is not for theatre — it has direct accuracy and reliability benefits.

• Speed. Big bulk jobs finish faster when work is parallelized across servers.
• Accuracy. Different servers occasionally get different responses from the same target (rate limits, anti-spam quirks, geographic routing). Two opinions on edge cases beats one.
• Reliability. If one provider is having a bad hour, the other picks up the slack — your verification keeps running.

This is also why our unknown rate stays low. When one provider says unknown, the other often has a definitive answer.

The accuracy question

"How accurate is your verification?"

Honestly: no verification service is 100% accurate, ever, and any one that claims to be is lying. Email is messy. Servers behave inconsistently. Configurations change between verification time and send time. What you want from a verifier is high accuracy with honest signalling on the cases where certainty is not possible.

Valid Email Checker hits 99%+ accuracy on every list verified. The 11 checks above are how we get there, the distributed provider stack is how we keep it stable, and the unknown + credit-refund pattern is how we stay honest when we cannot give a definitive answer.

See our guarantee for the specific commitments around accuracy, data handling, and the Unknown auto-refund.

Why 100% is mathematically impossible

Even with a perfect engine running on perfect data, some situations make verification inherently uncertain:

When the engine cannot reach certainty, the status comes back as unknown or catch_all. Both are honest signals, not a failure. The credit auto-refunds on unknown.

How long verification takes

Single email — usually under 2 seconds. The slowest mainstream domains can take up to ~10 seconds when they greylist or throttle.

Bulk verification — depends on list size:

Speed depends on how quickly recipient servers respond. Gmail is fast. Some corporate servers and government domains are slower because they greylist aggressively (intentionally delaying responses to fight spam). The engine waits — accurate answers matter more than fast ones.

No "quick mode" cutting corners

Every verification runs the full 11-step chain. We do not offer a "quick mode" that skips the SMTP handshake to claim faster results — that pattern tells you an address is valid when only the domain was checked, which produces the kind of bouncy "verified" list nobody wants.

What you get back

After verification, each address has:

1. A status (safe, invalid, catch_all, etc.) from the 11-check chain above.
2. A confidence score from 0–100.
3. A set of detailed flags (free-email provider, role account, MX-found, etc.).

In the dashboard you see all of this in the results table; you can filter by any of them. See understanding your results for how to read the columns, and downloading your results for the export formats (CSV, XLSX, JSON, TXT).

Summary

Everything happens server-side in seconds. Nothing ever lands in your contacts' inboxes. The 11-check engine is the same on the dashboard, in bulk uploads, and on the API.

Next steps