How to Verify an Email Address Is Real Without Sending One
A regex that checks for an @ and a . will happily accept [email protected]. It’s syntactically valid — and completely useless. If you’re building a signup form, a lead capture flow, or anything that emails users, “looks like an email” and “is a deliverable email” are two very different checks, and conflating them is how you end up with a database full of bounced addresses.
This post walks through the actual layers of email verification, what each one catches, and where each one breaks down.
TL;DR
Email verification happens in layers, each one more expensive and less reliable than the last:
_
**_Syntax check — does it look like an email? (cheap, catches typos)**
Domain/MX check — can this domain even receive mail? (catches fake domains)
SMTP handshake — does this specific mailbox exist? (catches typos in the username, but unreliable — many providers block it)
Disposable/catch-all detection — is this a throwaway address or a domain that accepts everything? (catches abuse)
For a quick manual check without writing any code, FastestChecker’s Email Validator runs through these layers for you.
Layer 1: Syntax Validation
This is the bare minimum — confirming the string is shaped like an email address.
javascriptfunction isValidSyntax(email) {
const regex = /^[^\s@]+@[^\s@]+\.[^\s@]+$/;
return regex.test(email);
}
Enter fullscreen mode Exit fullscreen mode
Don’t reach for an exhaustive RFC 5322-compliant regex here — it’s notoriously long, hard to maintain, and still won’t tell you if the address is deliverable. A simple pattern that catches obvious mistakes (missing @, no domain, no TLD) is enough at this layer. The real verification work happens next.
*Layer 2: Does the Domain Even Accept Mail?
*
This is the layer most signup forms skip, and it’s the one that catches the most fake submissions. Every domain that can receive email publishes an MX (Mail Exchange) record in DNS. If there’s no MX record, no mail is getting delivered there — full stop.
Node.js
javascriptconst dns = require('dns').promises;
async function hasMxRecord(email) {
const domain = email.split('@')[1];
try {
const records = await dns.resolveMx(domain);
return records.length > 0;
} catch {
return false; // No MX record = domain can't receive mail
}
}
Enter fullscreen mode Exit fullscreen mode
Python
pythonimport dns.resolver
def has_mx_record(email):
domain = email.split('@')[1]
try:
records = dns.resolver.resolve(domain, 'MX')
return len(records) > 0
except Exception:
return False
Enter fullscreen mode Exit fullscreen mode
This single check eliminates most typo’d domains (gmial.com, yaho.com) and made-up ones — with zero risk of tipping off the mail server that you’re probing it.
Layer 3: SMTP Handshake (Use With Caution)
This is the layer that theoretically checks whether the specific mailbox exists, not just the domain. It works by opening an SMTP connection to the mail server and issuing a RCPT TO command without actually sending a message — the server’s response tells you whether it would accept mail for that address.
In practice, this is unreliable:
Gmail, Outlook, and most major providers reject or rate-limit this to prevent exactly this kind of probing.
Greylisting can cause a valid address to temporarily look invalid.
Catch-all domains (common on custom business email setups) will report every address as valid, even ones that don’t exist.
Treat SMTP verification as a weak signal at best, not a source of truth. Most production systems either skip it entirely or use a third-party verification API that maintains reputation and IP rotation to avoid getting blocked.
Layer 4: Disposable Email Detection
Services like Mailinator or Temp-Mail let users generate throwaway addresses that pass every check above but exist only to receive one confirmation email. If you’re trying to reduce fake signups (not just bounces), cross-reference the domain against a maintained list of disposable email providers — there are several open-source lists on GitHub you can pull into your validation pipeline.
What Actually Matters for Most Apps
You almost never need all four layers. A practical default:
Signup forms: syntax + MX check. Fast, free, catches 90% of garbage input.
Email marketing lists: add disposable-domain filtering to protect sender reputation and deliverability.
High-value transactional flows (password resets, payment receipts): consider a paid verification API for the SMTP-layer confidence, since a bounced reset email is a real support problem.
답글 남기기