📧 Email Address Validator

About Email Validation

There is no single test that tells you whether an email address is “good”. What you can do is run a chain of independent checks, each answering a narrow question, and read the results together. That is exactly what this tool does — and it shows you every stage so you can see which one failed rather than getting a bare yes or no.

The one thing this tool cannot do

It cannot confirm that the mailbox actually exists. Nothing on this page proves that somebody@example.com is a real person’s inbox rather than a plausible-looking string at a domain that happens to accept mail.

The only way to probe for a specific mailbox is to open an SMTP conversation with the domain’s mail exchanger and issue a RCPT TO command, then hang up before sending anything. That technique is both unreliable and rude:

• Catch-all domains accept everything. Plenty of servers answer250 OK for every address, so a positive result means nothing.
• Large providers deliberately lie. Google, Microsoft and others return success for unknown recipients specifically to defeat address harvesting, then bounce the message later.
• Greylisting delays the answer. Many servers reject the first attempt from an unknown sender with a temporary error, so you learn nothing on the first try.
• It gets you blocked. Repeated probing from one IP looks exactly like a directory-harvest attack, and the reward is rate limiting or a spot on a blocklist.

So we do not do it, and we do not fake a result that pretends we did. The honest answer is that the only reliable proof a mailbox exists is sending a real message with a confirmation link and seeing somebody click it.

MX records — where the post goes

An MX (Mail Exchanger) record is a DNS entry that names the servers willing to receive mail for a domain, each with a priority number. A sending server looks up the MX records, sorts them by priority ascending, and tries the lowest number first. Equal priorities share the load between them.

Two special cases matter. First, implicit MX: RFC 5321 §5.1 says that if a domain has no MX record at all, the sender must fall back to its A or AAAA address record and deliver to that host on port 25. Mail can still arrive, but it is an unusual setup and some senders handle it badly, so we flag it rather than passing it silently.

Second, the null MX (RFC 7505): a single record of 0 . is a deliberate statement that the domain accepts no mail whatsoever. It is the correct way to configure a domain used only for a website, and it means any address there will bounce immediately. example.com publishes one.

Why SPF and DMARC matter

SMTP was designed in an era of mutual trust, and it lets any server claim to be sending from any domain. SPF and DMARC are the DNS records that close that hole.

• SPF (Sender Policy Framework) is a TXT record startingv=spf1 that lists which servers may send mail for the domain. It ends with an all mechanism saying what to do with everyone else:-all (reject — strongest), ~all (soft fail, mark as suspicious), ?all (neutral, near useless) or +all (authorise the entire internet, which is worse than publishing nothing).
• DMARC is a TXT record at _dmarc.yourdomain startingv=DMARC1. It ties SPF and DKIM results to the visible From address, tells receivers what to do when authentication fails (p=none monitor only,p=quarantine send to spam, p=reject refuse outright), and asks for aggregate reports via rua=.

A domain with p=none and no more is only watching, not defending: spoofed mail still reaches inboxes. Seeing -all together withp=reject tells you the domain owner takes their reputation seriously, which is a reasonable proxy for the domain being professionally run.

Disposable and role-based addresses

Disposable providers hand out inboxes that expire in minutes. They are perfectly valid addresses, so syntax and MX checks pass happily — the only way to catch them is to recognise the domain. Our list covers the well-known services and common naming patterns, but new throwaway domains appear constantly, so treat a pass as “not obviously disposable” rather than a guarantee.

Role addresses such as info@, support@ ornoreply@ are shared aliases rather than individual mailboxes. They are real and they work, but they are a poor choice for a user signup: nobody personally owns them, they change hands as staff come and go, and marketing sent to them attracts disproportionate spam complaints.

Syntax quirks worth knowing

• Plus tagging is valid. blake+receipts@gmail.com delivers to blake@gmail.com. Rejecting it is a bug, not a security measure.
• Quoted local parts are valid."very.unusual@strange"@example.com is legal RFC 5322, though most services reject it in practice.
• Length limits are real. The local part is capped at 64 octets and the whole address at 254.
• Dots have rules. An unquoted local part may not start or end with a dot, nor contain two in a row.
• IP address literals are valid. user@[192.0.2.1] is legitimate per RFC 5321, but there is no DNS name to look up.

Privacy

The address you enter is sent to our server so that the DNS lookups can be performed against Cloudflare’s DNS-over-HTTPS resolver. We do not store it, we do not log it to a database, and we never send mail to it.