Email Checker — Syntax & MX Deliverability

Three layers of "is this email real?"

Most "email validators" collapse three very different questions into one green checkmark. This one keeps them apart. Syntax — is the string even shaped like an address? — is checked against the same pattern browsers use for input type="email", tightened with the RFC 5321 rules real servers enforce: a 64-character local part, 254 characters overall, no leading, trailing, or doubled dots. Domain deliverability — can anything at that domain receive mail? — is answered with a live DNS query for MX records, the same lookup a sending mail server performs. Mailbox existence — is this exact inbox real? — cannot be determined from a browser, and mostly cannot be determined at all without sending a message, so this tool refuses to guess.

How the MX check reads the DNS

A domain with MX records is set up to receive mail — you'll see each mail server with its preference number. A domain with no MX but an A or AAAA record falls under RFC 5321's implicit-MX rule: mail is delivered to the host itself. That's legal but rare among domains that genuinely use email, so it's reported as a fallback, not a clean pass. A domain publishing the RFC 7505 Null MX record (0 .) is explicitly declaring it accepts no mail, and a domain that doesn't resolve at all (NXDOMAIN) can't receive anything. To dig into the raw records yourself, run the domain through the DNS Lookup tool, or read our primer on DNS record types.

Related tools

Cleaning a mailing list? Validation and normalization are complementary: after checking deliverability here, the Email Normalizer canonicalizes Gmail dots and +tag aliases and finds duplicates. The DNS Lookup tool shows every record type for a domain, and the WHOIS Lookup reveals who registered it.

Frequently asked questions

What is the difference between valid syntax, deliverability, and mailbox existence?

They are three separate questions. Syntax asks whether the string is even shaped like an email address. Deliverability asks whether the domain after the @ is set up to receive mail at all, which is what MX records in DNS declare. Mailbox existence asks whether that exact inbox is real — and that is something only the receiving mail server knows. This tool answers the first two precisely and is honest about not answering the third.

What is an MX record?

An MX (Mail eXchange) record is a DNS record that names the servers responsible for accepting email for a domain, each with a preference number (lower is tried first). When you send mail to [email protected], the sending server looks up the MX records for example.com to find out where to deliver it. If a domain publishes no MX and no address records, mail to it simply has nowhere to go. You can explore any domain’s full DNS records with our DNS Lookup tool.

Why don’t you verify that the mailbox actually exists?

Truly verifying a mailbox requires opening an SMTP conversation with the domain’s mail server and asking it about the recipient — something a browser cannot do, and something mail servers increasingly refuse to answer anyway (many accept every recipient during the conversation and bounce later, precisely to defeat address harvesting). Services that claim 100% mailbox verification are overstating what SMTP allows. Rather than fake a confidence level we cannot have, this tool tells you what can actually be known from the outside: syntax and MX-level deliverability.

Why is 254 characters the maximum email address length?

RFC 5321 caps an SMTP forward-path at 256 octets — but that count includes the angle brackets that wrap the address in the MAIL and RCPT commands, leaving 254 characters for the address itself. The same RFC also caps the local part (before the @) at 64 octets. You will sometimes see 320 quoted as the limit (64 + @ + 255-octet domain), but an address that long could never travel through a standards-compliant SMTP transaction, so 254 is the practical truth.

What does "no MX records, but an A record" mean?

RFC 5321 says that when a domain has no MX records at all, senders must treat it as having an implicit MX pointing at the domain itself — so if the domain has an A or AAAA record, mail is delivered straight to that host. It works, and some small domains rely on it, but virtually every domain that seriously receives mail publishes explicit MX records. We report this case as "deliverable via fallback" and suggest treating such addresses with mild suspicion.

What is a Null MX record?

A Null MX (RFC 7505) is a single MX record with preference 0 and a lone dot as the server name ("0 ."). It is the domain owner’s explicit, machine-readable way of saying "this domain does not accept email" — senders that understand it fail immediately instead of queueing and retrying for days. Domains that only exist for websites or for sending (never receiving) publish it deliberately, so this tool treats a Null MX as a firm "mail will be refused".

Why the HTML5 email pattern instead of full RFC 5322?

The full RFC 5322 grammar accepts things no mail provider or signup form would ever take — comments in parentheses, folding whitespace, elaborately quoted local parts. The WHATWG HTML Standard defines a simpler pattern for input type="email" and openly calls it a willful violation of RFC 5322, because the RFC grammar is simultaneously too strict, too vague, and too lax for practical use. Since that pattern is what every browser enforces on real forms, it is the most useful definition of "valid" — and on top of it we add the RFC 5321 length limits and dot rules that real mail servers enforce.