Sending email to an invalid or undeliverable address is one of the most avoidable causes of poor deliverability, high bounce rates, and eventual blacklisting. Validation isn't one check. It's a layered process covering format, domain infrastructure, and address hygiene. This guide walks through each layer in order, explains the reasoning behind it, and shows what to do (and what to skip) at each step.
Overview
Email validation verifies that an address is correctly formatted, points to a domain with working mail infrastructure, and isn't a known throwaway or role-based address. Doing this before an address lands in any system, registration forms, contact capture, checkout flows, protects your sender reputation and makes sure your messages actually reach people.
A fully validated address has passed four tests: syntax format (RFC compliance), domain existence (DNS lookup), mail server existence (MX record), and address hygiene (not disposable, not role-based). The Email Validator tool on this site runs all four automatically.
What You Need
- The email address to validate
- A sense of which validation layers apply to your case (a simple form? a marketing list? a transactional system?)
- For programmatic validation: a regex library and DNS resolution access, or a third-party validation API
- For bulk list cleaning: a CSV of addresses and a batch validator
Step 1: Check Email Format
The first check is purely syntactic. Does the address conform to the structure defined in RFC 5321 and RFC 5322?
A valid email address has exactly one @ symbol separating a local part and a domain:
local-part@domain.tld
Local part rules (before the @):
- Maximum 64 characters
- Valid characters: letters (a-z, A-Z), digits (0-9), and the special characters
.,+,-,_,% - Can't start or end with a dot
- Can't contain two consecutive dots
Domain rules (after the @):
- Maximum 255 characters (domain + TLD)
- Must contain at least one dot
- Labels (parts between dots) can contain letters, digits, and hyphens
- Labels can't start or end with a hyphen
- TLD must be at least 2 characters (
.io,.com,.museum)
Overall length: the complete address must not exceed 254 characters.
Here's a practical regex that covers the common valid cases without trying to be RFC-complete, which would be unreadably complex:
/^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$/
It correctly accepts user+tag@domain.co.uk and firstname.lastname@company.org while rejecting @nodomain, nodomain@, and two@@atsigns.
What format checking won't catch: a syntactically valid address like test@fakedomainthatdoesnotexist.com passes this check but bounces on delivery. Format checking is only the first step.
Step 2: Validate the Domain and MX Records
Format validation confirms the address is structured correctly. DNS validation tells you whether the domain actually exists and can receive mail.
Two DNS lookups matter here:
A/CNAME record lookup confirms the domain resolves to a server.
nslookup example.comordig example.com Ashould return an IP address.MX record lookup confirms the domain has a designated mail server.
nslookup -type=MX example.comordig example.com MXshould return one or more mail exchanger records with priority values.
If the domain has no MX record, mail sent to any address on it bounces with a "550 No MX record" error or similar. A domain can run a website perfectly well without any email infrastructure behind it, which is common for placeholder domains, parked domains, and single-page sites.
Here's what an MX lookup returns for a valid domain:
example.com MX preference = 10, mail exchanger = mail1.example.com
example.com MX preference = 20, mail exchanger = mail2.example.com
And what a missing MX record looks like:
*** No MX records found for thisdomain.example
No MX records means the domain can't receive email, so don't add it to your list.
The Email Validator runs this DNS lookup automatically, so you don't need to run dig commands by hand for individual addresses.
Step 3: Check for Disposable Email Domains
Disposable email addresses are temporary inboxes. They accept messages for a short window, minutes to hours, then expire. People create them specifically to avoid handing out a real address.
Some well-known disposable providers:
- mailinator.com
- tempmail.com and temp-mail.org
- guerrillamail.com
- yopmail.com
- 10minutemail.com
- throwam.com
Over 3,000 known disposable providers exist, and new ones show up regularly. Detection means checking the submitted address's domain against a continuously updated blocklist.
Why it matters: a user who signs up with a disposable address never intended to be contacted. Their "inbox" expires before your welcome email even lands. Adding them to a list inflates your subscriber count, produces hard bounces, and skews your campaign analytics.
What to do with disposable addresses: reject them at sign-up with a clear message ("Please use a permanent email address"), log the attempt for fraud pattern analysis, and don't silently accept then bounce later. That wastes send credits and hurts your sender score.
Step 4: Check for Role-Based Prefixes
Role-based email addresses are tied to a job function, not a person. Common examples:
| Prefix | Why it's problematic |
|---|---|
| admin@ | Often shared; high complaint rate |
| info@ | Monitored by multiple staff or an auto-responder |
| support@ | Ticketing system; unsubscribes often missed |
| sales@ | CRM routing; personal emails preferred for consent |
| noreply@ | Can't receive replies; consent unclear |
| postmaster@ | Technical role; not a marketing contact |
| abuse@ | Used specifically to report spam |
Role-based addresses aren't invalid. They follow RFC format and often have working MX records. But they carry more risk for marketing and transactional email: they aren't tied to one consenting individual, which raises GDPR and CAN-SPAM issues, shared inboxes mean spam reports can come from staff who never signed up, and many ESPs score these addresses negatively or reject them at import.
The practical approach is to flag role-based addresses rather than silently accept them. For B2B lead capture, you might accept info@ and sales@ while blocking noreply@ and abuse@. For consumer sign-up forms, reject all of them.
Step 5: Never Validate by Sending a Test Email
A common misconception holds that the most reliable way to validate an address is to send a test message and watch for a bounce. This runs into real problems.
SMTP probing is largely blocked now. Connecting to a mail server's SMTP port and running the handshake (RCPT TO:<address>) without sending a real message used to work for validation. Today, major providers like Google, Microsoft, and Yahoo return a 250 OK to any address to stop directory harvesting, which makes the check useless. Others reject the probe outright and flag your IP as suspicious.
Catch-all domains accept everything. Many corporate domains configure their mail server to accept all addresses at @company.com and route them to a central inbox or discard them. A bounce test against these domains always returns success, even for addresses that don't exist.
There's a cost too: probe messages, even without a body, generate SMTP activity from your IP. Repeated probing gets your IP or domain flagged by spam filters, which hurts deliverability for your legitimate sends.
The better approach: use MX record validation (Step 2) plus a double opt-in confirmation email. The confirmation email sent to the address is the only reliable end-to-end test, and it doubles as your consent record.
Common Mistakes to Avoid
Accepting typo domains. user@gmail.con, user@hotmial.com, and user@yahooo.com all pass format validation but bounce. Fuzzy matching for common provider typos, suggesting the corrected domain instead of silently accepting the mistyped one, catches a surprising number of these.
Not checking MX records. Format validation alone lets through addresses on non-email domains. Add the DNS MX lookup step for any system where deliverability matters.
Overly strict regex blocking valid addresses. Plus addressing (user+tag@domain.com) is valid under RFC 5321, and so are hyphens in the local part and TLDs longer than 3 characters (.museum, .photography). A custom regex that's too narrow will reject legitimate addresses, so test yours against a corpus of known-valid edge cases before shipping it.
Not normalising before storage. Lowercase the domain part at minimum before saving to a database. RFC 5321 treats the domain as case-insensitive, so User@Domain.COM and user@domain.com are the same address, and storing them unnormalised causes duplicate accounts and failed login lookups.
Treating validation as one-time. Addresses valid at sign-up can go stale later: people change jobs, domains expire, providers shut down. Regular list hygiene, removing addresses that hard-bounce or haven't opened anything in 12+ months, matters as much as validation at the point of capture.
Formula & Methodology
Email validation follows a layered model, where each layer catches a class of invalid addresses the previous layer misses:
Layer 1: Syntax (regex)
Catches: malformed addresses, missing @, invalid characters
Misses: valid format but non-existent domains
Layer 2: DNS / MX Lookup
Catches: domains with no mail infrastructure
Misses: valid domains with catch-all servers
Layer 3: Blocklist (disposable + role-based)
Catches: throwaway providers, functional role addresses
Misses: newly created disposable providers
Layer 4: Double Opt-In
Catches: everything else, non-existent local parts, catch-all domains
Cannot be bypassed
The regex pattern follows RFC 5321 section 4.1.2 (local-part) and RFC 5322 section 3.4.1 (addr-spec). A simplified but production-suitable version:
^[a-zA-Z0-9._%+\-]{1,64}@[a-zA-Z0-9.\-]{1,255}\.[a-zA-Z]{2,}$
For MX validation, the DNS query type is MX (type 15 in the DNS protocol). At least one MX record with a valid priority integer and mail exchanger hostname is enough for this layer to pass.
Double opt-in remains the definitive validation method. It proves the address is real, accessible, and controlled by whoever submitted it. Every other layer is a pre-filter that improves list quality before that confirmation email goes out.
The Email Validator runs all four layers on any address in one pass.