How to Validate an Email Address Without Sending a Message

Every signup form, CRM import, and outbound campaign eventually asks the same question: is this email address actually valid? The naive answer is to send a test message and see if it bounces. That works, sort of — but it's slow, it costs you sender-reputation points every time the address bounces, and it doesn't scale to validating ten thousand addresses imported from a spreadsheet. There are better ways. None of them is perfect alone. Stack the right ones together and you can sort an arbitrary list of email addresses into "almost certainly deliverable," "probably bogus," and a small middle bucket that needs human judgment — without sending anything.

This is what the email validator does, and what every commercial list-cleaning service has been doing for a decade. Five distinct checks, each catching different categories of bad address, combined into a score. Here's what each layer actually does, what it can and can't tell you, and how the layers fit together.

Why this matters

The cost of validating an address is small. The cost of not validating one is large and ongoing:

• Bounce rates damage sender reputation. Mailbox providers grade you on what percentage of your messages bounce. A spike in hard bounces (the receiving server saying "no such address") tells Gmail or Outlook you have a low-quality list, which lowers the inbox-placement of every legitimate message you send after that. Keep this above ~5% for any meaningful campaign window and your deliverability craters.
• Typos at signup are a usability tax. Someone types gmial.com into a signup form. Their welcome email goes to nowhere. They never come back. The fix — a "did you mean gmail.com?" prompt before the form submits — costs almost nothing.
• Disposable addresses don't convert. Mailinator and Guerrilla Mail accounts exist so users can clear a signup gate without giving you a real address. They never read your follow-ups. They never become customers. Letting them through inflates your active-user counts and depresses every conversion metric that depends on email engagement.
• Outbound to abandoned domains is wasted work. A B2B prospect list with addresses at domains that have no MX record is a list of guaranteed bounces — better to catch them before they hit your CRM than after they wreck a week of sender reputation.

Layer 1: Syntax (RFC 5321 / 5322)

The cheapest check, and the one most validators get subtly wrong. The internet email standards define what a syntactically valid address looks like: an optional local part of up to 64 characters, an @, and a domain of up to 255 characters total. The local part allows letters, digits, dots, plus signs (the user+tag trick for filtering), hyphens, and — in theory — a lot of more exotic characters wrapped in quotes. The domain part has to be a syntactically valid hostname (labels, dots, no leading hyphens, all the usual DNS rules).

The temptation is to write a regex. The regex that handles every edge case correctly per the RFC is famously about 6,000 characters long and almost nobody actually deploys it. What everyone deploys instead is a tractable subset — something like ^[^\s@]+@[^\s@]+\.[^\s@]+$ — which rejects the obvious garbage and accepts almost everything you'd see in practice, while quietly being slightly wrong about edge cases involving quoted local parts and IP-literal domains (user@[192.0.2.1]). For most validators the tradeoff is fine. The pragmatic rule is: if the address can't even pass loose syntax, stop here. If it does, move on to the checks that actually matter.

Layer 2: MX record check

Syntax tells you the address could be valid; MX records tell you the domain is set up to receive mail. This is the single highest-signal check after syntax, and it costs one DNS query.

Look up the MX records on the domain. If one or more are published, the domain owner has explicitly designated mail servers — the domain is in the mail-receiving business. If there are no MX records but an A or AAAA record exists, RFC 5321 §5.1 says mail clients should fall back to delivering at the host's IP address; the domain technically can still receive mail, just without an MX (this is the "implicit MX" rule). If there's neither, the domain literally cannot receive email. Done.

An MX check immediately catches typos like gmail.cm (no such TLD) and contoso.invalid (the .invalid TLD is reserved precisely to never have MX). It also catches abandoned domains — companies that let their domain expire, brands that got rebranded years ago — without needing to know anything else about the address. The DNS records lookup can do the same check manually for one-off curiosity.

Layer 3: Disposable email detection

Disposable email services — Mailinator, Guerrilla Mail, Temp Mail, Yopmail, 10minutemail, and a hundred smaller ones — let users generate a working mailbox that lives for a few hours and then disappears. They have legitimate uses (signup gates that you don't want to give your real address to) and problematic ones (creating throwaway accounts in bulk, evading per-user limits, fraud). For a business validating signups, a disposable address is almost always a sign that this signup isn't going to convert.

Detection is a list problem. There's no syntactic distinction between user@mailinator.com and user@gmail.com — both pass syntax and have valid MX. The only way to know is to maintain a list of known disposable domains and check the address's domain against it. Open-source lists (the disposable-email-domains package on npm, and similar) track between 100,000 and 200,000 known disposable domains, updated continually as new ones get spun up. Our email validator bundles the disposable-email-domains list directly — 121,000+ exact-match domains plus 399 wildcard patterns — and checks every input against it.

This is one of those checks where the list quality matters more than the algorithm. A six-month-old list misses thousands of new disposable services; a stale list waves bad addresses through. The trade-off is keeping the list small enough to ship to the edge versus comprehensive enough to be useful. 121k entries fits in a couple of MB and covers approximately every disposable service anyone actively uses.

Layer 4: SPF and DMARC posture

This one is indirect. Whether the address's domain publishes proper email authentication tells you something about how seriously the domain operator takes email — and by extension, how likely the address itself is to be a real, monitored mailbox versus a forgotten parked domain.

A domain with a working SPF record and a meaningful DMARC policy (especially p=quarantine or p=reject) is one where someone is actively managing email. A domain with no SPF, no DMARC, and no MX record other than a hosting provider's default is almost certainly abandoned. The presence or absence isn't a hard pass/fail — plenty of legitimate small-business domains still don't have DMARC — but it's a meaningful quality signal that nudges the verdict.

For deeper context on what those records mean and why they matter, see our SPF explainer, DMARC explainer, and DKIM explainer — the three legs of the email authentication stool that every well-run sending domain has in place.

Layer 5: Typo detection

The pattern is familiar: gmial.com, gmai.com, gmal.com, outlok.com, yaho.com, hotmial.com. These pass syntax. They sometimes even resolve to something — squatters register the common typos and serve placeholders. The user thought they were typing their real address and didn't notice.

Detection is a Levenshtein-distance or similar edit-distance comparison against a list of the few dozen domains that account for the overwhelming majority of personal email: gmail.com, outlook.com, yahoo.com, hotmail.com, icloud.com, aol.com, proton.me, fastmail.com, and a handful of regional providers. If the input domain is within one or two edits of a known popular domain — and isn't exactly one of them — surface a "did you mean gmail.com?" suggestion before the form submits.

This is the highest-leverage check at signup. The user accepts the correction, you get a real address, the welcome email actually arrives. The validator does this with a small built-in typo map for the most common cases and edit-distance for the long tail.

What validation can't tell you

Worth being upfront about the limits, because vendors who sell email validation routinely overstate them:

• Whether the specific mailbox exists. Validation tells you the domain accepts mail. It doesn't tell you that specific-user-name@ at that domain is a real mailbox. asdf@gmail.com passes every check in this article but might still bounce.
• SMTP VRFY is mostly off. The original mail protocol had a VRFY command for asking a server "is this address valid?" Almost every modern mail server refuses to answer (responses are universally either "I don't know" or "yes" regardless), specifically because spammers used VRFY for harvesting. Don't rely on it.
• SMTP "ping" verification is risky. Some validators actually open an SMTP connection to the recipient server, run through HELO, MAIL FROM, RCPT TO, and watch the response code without ever sending DATA. It works, but you're making aggressive connections to other people's mail servers, and large providers (Gmail, Office 365) treat repeated RCPT probing as bulk-recipient harvesting — your IP gets blacklisted. We don't do this.
• Catch-all domains. Some domains accept any address at the domain (anything@example.com succeeds), so no test short of actually sending mail can tell whether the address points at a real human or just gets quietly archived.

The honest summary is that only sending a message truly confirms deliverability. Every other check is a probability adjustment. Stack enough of them and the probability gets high enough that for practical purposes you can treat the address as valid — but the only ground truth is a successful (or bounced) delivery.

Scoring all five layers together

The validator's job is to combine those five signals into a single score and verdict. The tool scores 0–100:

• 80+ — Valid. Syntax fine, MX exists, not disposable, domain has at least some email-auth posture, no typo. Treat as deliverable.
• 40–79 — Risky. Passes the basics but has something off — disposable, weak email-auth, suspicious TLD, or a possible typo. Either send with reduced confidence or surface the warning to the user at signup.
• Under 40 — Invalid. Failed at least one structural check (no MX, bad syntax, exact disposable match, no domain at all). Don't add to a list.

You can also check the sending server's reputation separately if the address is one you'd be replying to: paste its likely outbound IP into the IP blacklist tool to see whether the mail server is on any DNSBLs. None of these checks fully replaces "send the message and see what happens" — but if you're pre-validating a CRM import or rejecting obvious garbage at signup, this stack catches the overwhelming majority of bad addresses before they cost you anything.