Sending email to an invalid or undeliverable address is one of the most avoidable causes of poor email deliverability, high bounce rates, and eventual blacklisting. Validation is not a single check — it is a layered process covering format, domain infrastructure, and address hygiene. This guide walks through each layer in order, explains the methodology behind it, and shows you what to do (and what not to do) at each step.
Overview
Email validation is the process of verifying that an email address is correctly formatted, points to an active domain with mail infrastructure, and is not a known throwaway or role-based address. Proper validation before adding an address to any system — registration forms, contact capture, checkout flows — protects your sender reputation and ensures your messages actually reach real people.
A fully validated email 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 checks automatically.
What You Need
- The email address to validate
- Understanding of which validation layers apply to your use case (simple form? marketing list? transactional system?)
- For programmatic validation: a regex library and access to DNS resolution (or a third-party validation API)
- For bulk list cleaning: a CSV of addresses and access to 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
.,+,-,_,% - Cannot start or end with a dot
- Cannot 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 cannot 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.
A practical regex that covers the common valid cases without being RFC-complete (which would be unreadably complex):
/^[a-zA-Z0-9._%+\-]+@[a-zA-Z0-9.\-]+\.[a-zA-Z]{2,}$/
This correctly accepts user+tag@domain.co.uk and firstname.lastname@company.org while rejecting @nodomain, nodomain@, and two@@atsigns.
What format checking does not catch: A syntactically valid address like test@fakedomainthatdoesnotexist.com passes format validation but will bounce on delivery. That is why format checking is only the first step.
Step 2: Validate the Domain and MX Records
Format validation tells you the address is structured correctly. DNS validation tells you whether the domain actually exists and can receive mail.
Two DNS lookups to perform:
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, email sent to any address on that domain will bounce with a "550 No MX record" or similar error. A domain can exist as a website without having any email infrastructure — this is common for placeholder domains, parked domains, and single-page websites.
Example of 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
Example of what a missing MX record looks like:
*** No MX records found for thisdomain.example
No MX records = cannot receive email = do not add to your list.
The Email Validator performs this DNS lookup automatically so you do not need to run dig commands manually for individual addresses.
Step 3: Check for Disposable Email Domains
Disposable email addresses are temporary inboxes — they accept messages for a short period (minutes to hours) then expire. Users create them specifically to avoid giving out their real email address.
Well-known disposable providers include:
- mailinator.com
- tempmail.com and temp-mail.org
- guerrillamail.com
- yopmail.com
- 10minutemail.com
- throwam.com
There are over 3,000 known disposable providers, and new ones appear regularly. Detection works by checking the domain portion of the submitted address against a continuously updated blocklist.
Why this matters: A user who signs up with a disposable address has no intention of being contacted. Their "inbox" will expire before your welcome email arrives. Adding them to a list inflates your subscriber count, produces hard bounces, and distorts 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
- Do not silently accept and then bounce — this wastes send credits and harms your sender score
Step 4: Check for Role-Based Prefixes
Role-based email addresses are tied to a job function rather than an individual person. Common examples:
| Prefix | Why it's problematic |
|---|---|
| admin@ | Often shared; high complaint rate |
| info@ | Monitored by multiple staff or auto-responder |
| support@ | Ticketing system; unsubscribes often missed |
| sales@ | CRM routing; personal emails preferred for consent |
| noreply@ | Cannot receive replies; consent unclear |
| postmaster@ | Technical role; not a marketing contact |
| abuse@ | Specifically used to report spam |
Role-based addresses are not invalid — they follow RFC format and often have working MX records. But they carry elevated risk for marketing and transactional email because:
- They are not tied to one consenting individual, creating GDPR and CAN-SPAM issues
- Shared inboxes mean spam reports can come from staff who never signed up
- Many ESPs score role-based addresses negatively and may reject them during list import
Best practice: Flag role-based addresses rather than silently accepting them. For B2B lead capture, you may choose to accept info@ and sales@ while blocking noreply@ and abuse@. For consumer sign-up forms, reject all role-based prefixes.
Step 5: Never Validate by Sending a Test Email
A common misconception is that the most reliable way to validate an email is to send a test message and see if it bounces. This approach has serious problems:
SMTP probing is blocked: Connecting to a mail server's SMTP port and going through the handshake (RCPT TO:<address>) without actually sending was historically used for validation. Today, major providers (Google, Microsoft, Yahoo) return a 250 OK to any address to prevent directory harvesting — making the check useless. Others reject the probe outright, flagging your IP as suspicious.
Catch-all domains accept everything: Many corporate domains configure their mail server to accept all addresses (@company.com) and route to a central inbox or discard. A bounce test on these domains always returns success, even for addresses that don't exist.
Negative consequences: Sending probe messages, even without a body, generates SMTP activity from your IP. Repeated probing can get your IP or domain flagged by spam filtering systems, harming deliverability for your legitimate sends.
The right 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 will bounce. Consider implementing fuzzy matching for common provider typos — suggest the corrected domain rather than silently accepting the mistyped version.
Not checking MX records: Format validation alone passes addresses on non-email domains. Always 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 RFC 5321. So are hyphens in the local part, and TLDs longer than 3 characters (.museum, .photography). Custom regex patterns that are too narrow incorrectly reject legitimate addresses — test your regex against a corpus of known-valid edge cases before deploying.
Not normalising before storage: Email addresses should be normalised before saving to a database. At minimum, lowercase the domain part — RFC 5321 specifies that the domain is case-insensitive. User@Domain.COM and user@domain.com are the same address. Storing unnormalised addresses causes duplicate accounts and failed login lookups.
Treating validation as one-time: Addresses that were valid at sign-up can become invalid later — people change jobs, domains expire, providers shut down. Regular list hygiene (removing addresses that hard-bounce or have not opened in 12+ months) is as important as validation at the point of capture.
Formula & Methodology
Email validation follows a layered model, where each layer catches a class of invalid addresses that 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 pattern:
^[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 DNS protocol). The presence of at least one MX record with a valid priority integer and mail exchanger hostname is sufficient for this layer to pass.
Double opt-in is the definitive validation method — it proves the address is real, accessible, and controlled by the person who submitted it. All other layers are pre-filters that improve list quality before the confirmation email is sent.
Use the Email Validator to run all four layers on any address instantly.