Email Address & MX Record Validator

Validate an email address and check whether its domain can receive mail.

email-validator

🌐 The domain is resolved server-side over DNS-over-HTTPS. Only the part after @ is looked up — the local part is never sent to a resolver, and no mail is sent.

§01 ABOUT THIS TOOL

Overview

Two different questions get confused with each other. “Is this address well-formed?” is answerable from the string. “Will mail sent here arrive?” is partly answerable from DNS. “Does this mailbox exist?” is not answerable at all without sending mail, and anything claiming otherwise is guessing.

This tool answers the first two and says so plainly about the third. It checks the syntax against the rules mail servers enforce in practice, then resolves the domain for MX, A/AAAA, SPF and DMARC records — enough to distinguish a typo from a domain that cannot receive mail from a domain whose authentication is broken.

How to use

Type or paste an address.
Read the two headline results: Syntax and Domain accepts mail.
Read the notes. They name the specific problem rather than a verdict.

What the syntax check enforces

RFC 5322 permits far more than mail systems accept. Comments in parentheses, quoted local parts with spaces, and nested folding whitespace are all legal grammar that a substantial share of real servers reject. A checker that accepts everything legal tells you an address is fine when it will bounce.

So the rules applied here are the practical ones:

The local part may contain letters, digits and !#$%&'*+-/=?^_`{|}~. — which includes the apostrophe, because names like o'[email protected] are real, and +, because Gmail-style subaddressing is in daily use.
No leading dot, no trailing dot, no consecutive dots.
The local part is limited to 64 characters and the domain to 255, per RFC 5321. Each domain label is limited to 63.
The domain must be a valid hostname with a TLD of at least two letters. user@localhost is refused; it is meaningful only inside a single machine.
Non-ASCII must be Punycode. user@日本語.jp is rejected in favour of its xn-- form, because delivery to the Unicode form requires SMTPUTF8 support at every hop.

Reading the DNS result

MX records are listed in priority order, lowest first. Several records are normal — they are fallbacks, and equal priorities distribute load.

Null MX (RFC 7505) is a single record with priority 0 and an empty host. It means the domain deliberately accepts no mail, and it suppresses the implicit MX fallback. This is the correct configuration for a domain used only for a website, and example.com uses it.

Implicit MX is the opposite situation: no MX record at all, so senders fall back to the A or AAAA address. The domain is technically deliverable and the result is usually accidental. Mail arrives at whatever is on port 25 of the web server, which typically means it arrives nowhere useful.

SPF is checked for the faults that break delivery rather than for style. More than ten DNS-lookup mechanisms (include, a, mx, ptr, exists, redirect) causes a permanent error under RFC 7208 §4.6.4 and authentication fails outright — a limit that is easy to cross by adding one more vendor. +all authorises every sender on the internet and defeats SPF entirely. ptr is deprecated. A record with no all mechanism is open-ended, unless it uses redirect=, in which case omitting all is correct.

Two SPF records on one domain is also a permanent error, and it is reported because it presents as intermittent unexplained delivery failure. It happens whenever a second vendor’s record is added alongside the first instead of merged into it with include:.

DMARC is read from _dmarc.<domain>. p=none is flagged: it only collects reports, so failures are recorded and delivered anyway. It is the right starting point and the wrong place to stop.

Examples

A signup form rejecting real addresses — compare your validation with what is enforced here. Regexes copied from the web routinely reject + tags, apostrophes and long TLDs.
“They never got my mail” — check the recipient’s domain first. A null MX or a missing MX explains it instantly and moves the conversation off your server.
Auditing your own sending domain — SPF lookup count, +all, and a DMARC stuck at p=none are the three findings that most often explain mail landing in spam.
After adding an email vendor — vendors hand you an include: and rarely mention the ten-lookup ceiling. Check the total, not the new line.
Investigating a specific message — message header analyser shows the delivery path and the SPF, DKIM and DMARC verdicts as the receiver recorded them, and .eml viewer opens a saved message. This tool answers the question before a message is sent; those two answer it afterwards.

Notes

DNS is resolved over DNS-over-HTTPS with a five-second timeout per query. If a query fails, the fields it would have filled are reported as absent rather than as an error, so a slow TXT lookup does not discard a correct MX result.

The domain is only queried if it is a valid hostname. An address that fails the structural check produces no DNS traffic at all.

The disposable-domain list covers well-known providers as a prompt, not as an authority — new domains appear constantly and absence from the list means nothing. The role-account check is likewise informational: info@ and admin@ are perfectly valid addresses that simply do not belong to one person.

No mail is sent, no SMTP connection is opened, and the local part of the address is never included in a DNS query. See the privacy policy.

FAQ

Does this tell me whether the mailbox exists?

No, and no tool can tell you reliably. SMTP's VRFY command is disabled almost everywhere, and probing with RCPT TO is address harvesting — it is what spammers do, it gets you rate-limited or blocked, and providers with catch-all addresses answer yes to everything anyway. What is answerable is whether the syntax is valid and whether the domain accepts mail at all, and that is what this reports.

Is the address I type sent anywhere?

The domain is resolved over DNS-over-HTTPS. The local part — everything before the @ — is not needed to resolve anything, so it is never included in a DNS query. No mail is sent and nothing is stored.

Why is my valid address reported as invalid syntax?

Most often consecutive dots, a leading or trailing dot in the local part, or a non-ASCII character. Internationalised domains must be given in Punycode (xn--…) because a sender without SMTPUTF8 support cannot deliver to the Unicode form. Quoted local parts such as "a b"@example.com are also rejected: they are legal in RFC 5322 and refused by a large share of real mail systems.

What is a null MX?

A single MX record of priority 0 pointing at the root (a bare dot), defined in RFC 7505. It is the domain owner explicitly declaring that this domain receives no mail, and it stops senders from falling back to the A record. example.com publishes one, which is why it is reported as accepting no mail rather than as having no MX.

The domain has no MX but is still reported as deliverable. Why?

That is the implicit MX rule: with no MX record, senders fall back to the A or AAAA address. It is valid and it is almost never intended, so it is flagged. If that host is a web server rather than a mail server, mail is being delivered somewhere nobody reads.

Is a role account or a disposable domain a problem?

Neither is invalid — both are context. info@ and support@ reach a shared inbox that several people or nobody reads, which matters for account recovery. A disposable domain suggests the address was created to be abandoned. The check is informational, and the disposable list covers well-known providers only, so absence from it proves nothing.