Email Address Validator

What the Email Address Validator checks

An email address has two parts: the local part before the @, which only the receiving mail server interprets, and the domain after it, which anyone can look up in DNS. From the outside you can check the format and whether the domain is set up to receive mail.

This validator checks the syntax against the practical subset of RFC 5321 and RFC 5322 that real mail systems accept, not every rare form the standards allow, such as comments. Then it looks up the domain in DNS and reports its MX records and whether their host names resolve. If the domain publishes a “null MX” (RFC 7505), it reports that the domain accepts no mail. If there is no MX record at all, it checks the A and AAAA records, because sending servers fall back to those (the implicit MX). Only the domain is looked up; the address itself is not stored.

Why it matters

Typos are the most common cause of bad addresses in sign-up forms and customer lists: gmail.con, a missing dot, a stray space. Catching them before you send keeps bounces down, and a high bounce rate hurts your sender reputation, so mail to real customers is more likely to land in spam.

The tool deliberately stops at DNS and never connects to the mail server to ask whether the mailbox exists. That kind of SMTP check is unreliable: catch-all servers accept every address, greylisting delays unknown senders, and many large providers answer the same way for real and made-up mailboxes. It is also abusive at scale, because probing mailboxes without sending mail is how spammers harvest addresses, and servers that see it may block the sender. A valid result therefore means “this address can receive mail”, not “this person exists”.

How to fix common problems

If the syntax check fails, look for the usual typos: a comma instead of a dot, two @ signs, spaces, or an ending such as .con or .cmo. In forms, avoid overly strict patterns that reject valid addresses with plus signs or newer top-level domains.

If the domain has neither MX nor A/AAAA records, mail to it cannot be delivered: the address is wrong or the domain has lapsed. If you own the domain and want to receive mail, add MX records that point at your mail provider. If the domain should never receive mail, publish a null MX (MX 0 .) so senders fail at once instead of retrying for days. See our guide to mail servers.

The only reliable proof that a mailbox exists and belongs to the person who typed it is a confirmation email with a link. Use double opt-in for newsletters and sign-ups, and remove addresses that hard-bounce. To check the sending side of a domain, use the Email Security Checker (SPF, DKIM, DMARC).

Questions

Does a valid result mean the mailbox exists?

No. It means the address is well-formed and its domain can receive mail. Only a confirmation email proves that the mailbox exists and that its owner wants your mail.

Why not check the mailbox over SMTP?

Because the answer is unreliable (catch-all servers, greylisting, providers that accept every recipient), and because probing mailboxes without sending mail looks like address harvesting and can get the checking server blocked.

What is a null MX?

An MX record with priority 0 and a single dot as its host, defined in RFC 7505. It says the domain accepts no email, so sending servers reject a message straight away instead of retrying.

Do you store the addresses I check?

No. Only the domain part is looked up in DNS, and the full address is not stored.