How to Know If an Email Address Is Fake

Senders need to detect fake email addresses for three reasons: form spam that pollutes your CRM, fraudulent signups that abuse free trials, and dirty lead lists that destroy sender reputation when you mail them. The detection methods overlap but each fake-address category needs a slightly different check.

This guide is for senders — operators, growth teams, list buyers, and form owners. If you are a consumer wondering whether someone is catfishing you, the techniques are similar but the priorities differ.

The four categories of fake address

Category	Example	Detection method
Invalid syntax	johnatgmailcom	RFC 5322 regex
Typo of real address	[email protected]	Domain typo detection, MX lookup
Non-existent mailbox	[email protected]	SMTP RCPT TO probe
Disposable / throwaway	[email protected]	Disposable-domain database
Parked or non-mail domain	[email protected]	MX record absence

Each layer catches different fakes. A typo passes syntax but fails MX. A disposable address passes MX and SMTP but appears in a known-disposable list. You need all four.

Layer 1: Syntax validation

Use RFC 5322 to validate format. Most validation libraries (Python's email-validator, Node's email-validator) handle this. Common rejections:

• Missing @
• Multiple @ symbols
• Invalid characters in local-part
• Domain ending in . or starting with -
• Local-part over 64 characters

Syntax validation alone catches obvious junk but misses 99% of intentional fakes. It's a prerequisite, not a finish line.

Layer 2: MX record lookup

Resolve the domain's MX records. If no MX records exist, no mail server has been configured and the address cannot receive mail.

dig MX example.com +short

If the response is empty, the domain has no mail infrastructure. Some domains fall back to A records for mail (legacy behavior, RFC 5321 §5.1), but this is rare and worth flagging.

Practitioner note: Brand-new domains often have A records pointing at parking pages but no MX. Form spammers use these constantly — they register a throwaway domain, point it at parking, and submit to your signup form. An MX check catches them. So does a domain-age check (WHOIS or RDAP) flagging domains registered within the last 30 days.

Layer 3: SMTP RCPT TO probe

This is the definitive test. Connect to the domain's MX server on port 25, issue EHLO, MAIL FROM, and RCPT TO. The server responds with 250 (accept) or 550 (reject):

$ telnet aspmx.l.google.com 25
EHLO yourdomain.com
MAIL FROM:<[email protected]>
RCPT TO:<[email protected]>
550-5.1.1 The email account that you tried to reach does not exist.

A 250 means the mailbox accepts mail. A 550 means it does not exist. Some servers respond with 252 (cannot verify, will accept and try), which is ambiguous.

You do not need to run this manually. Commercial verifiers (Kickbox, ZeroBounce, NeverBounce, Clearout) automate it and handle edge cases — IP rotation, greylisting, rate-limiting, and partial-block ISPs. See our email validation tools comparison.

Layer 4: Disposable-domain database

Mailinator, Guerrilla Mail, Temp-Mail, 10MinuteMail, Yopmail, and hundreds of similar services exist to let users sign up without exposing a real address. Their domains pass MX, SMTP, and syntax — they are real mailboxes — but they're throwaway by design.

Detection requires a maintained list. Open-source lists exist (the disposable-email-domains repo on GitHub is updated regularly), but they lag behind new providers. Commercial verifiers maintain proprietary lists that update faster.

A few high-traffic disposable domains to know:

• mailinator.com (and 80+ rotating aliases)
• guerrillamail.com (multiple TLDs)
• temp-mail.org
• 10minutemail.com
• yopmail.com
• maildrop.cc

If your signup form does not block disposable domains, you will get them.

Catch-all: the case where you can't tell

Catch-all domains accept mail for every local-part. A SMTP probe against [email protected] returns 250 because the server accepts everything. You cannot tell from SMTP whether the mailbox is real.

This is increasingly common on Microsoft 365 and Google Workspace tenants. Enterprise verifiers (Clearout, ZeroBounce) detect catch-all domains by sending a random local-part RCPT TO and comparing the response. If both return 250, it's catch-all.

For catch-all domains, options are:

1. Accept the risk and send (high bounce risk)
2. Drop the address
3. Use engagement-based confirmation — send once, watch for bounce/complaint, then continue

Practitioner note: Catch-all domains on B2B lists are 30-50% real and 50-70% invalid. Treating them as "valid" inflates your bounce rate; dropping them throws away real prospects. The least-bad option is a low-volume send to catch-all addresses through a separate IP/subdomain so the bounces don't poison your main sending reputation.

Putting it all together

A practical fake-detection pipeline:

1. Syntax (RFC 5322)               → reject malformed
2. Typo detection (gmial → gmail)  → suggest correction or reject
3. MX lookup                        → reject no-MX
4. Disposable domain check         → reject or flag
5. SMTP RCPT TO probe              → reject 550, accept 250
6. Catch-all detection              → quarantine or low-volume
7. Domain age (WHOIS/RDAP)         → flag domains < 30 days

For inline form validation, layers 1-4 are fast enough for synchronous calls. Layers 5-7 are async and run server-side after submission.

For list cleaning, all seven run in batch through a verifier API. Cost: $5-15 per 1,000 addresses depending on tool.

Tools that automate the full pipeline

Tool	Syntax	MX	SMTP	Disposable	Catch-all
Kickbox	Yes	Yes	Yes	Yes	Yes
ZeroBounce	Yes	Yes	Yes	Yes	Yes
NeverBounce	Yes	Yes	Yes	Yes	Yes
Clearout	Yes	Yes	Yes	Yes	Yes
Hunter	Yes	Yes	Yes	Yes	Detection only

See individual reviews of Kickbox, ZeroBounce, and Clearout.

If you need help building a fake-detection pipeline for signups, cleaning a polluted list, or auditing a vendor's list quality before you import it, book a consultation. I do list audits weekly and can show you the categories of junk you're missing.

Sources

• RFC 5321 — SMTP
• RFC 5322 — Internet Message Format
• M3AAWG Email Address Validation BCP
• disposable-email-domains GitHub Repository
• Kickbox API Documentation
• ZeroBounce Email Validation API

---

v1.0 · May 2026