Email address validator

Three answers, kept apart

Most checkers hand back one badge. That is the most common way this kind of page misleads people, because the three things it is made of fail independently. not.a..real@example.com is malformed at a domain with excellent mail servers. someone@example.org may be flawless at a domain that has never accepted a message in its life. A single verdict hides which one you are looking at, and therefore hides what to fix.

So the report answers the grammar question, the domain question and the MX question separately, and only then says what the three of them together add up to.

What “deliverable” means here

Exactly this: the address parses under RFC 5322, and its domain publishes at least one usable MX record. Both halves, which is why it is worth saying out loud what each half costs. An address with perfect syntax at a domain with no MX is not deliverable. A malformed address at a domain with a flawless MX list is not deliverable either.

And what it does not mean: that the mailbox exists, that the server behind the MX is running, that it will accept a message from you specifically, or that anything you send will survive the filtering on the other side. It is a statement about published records. Records are all this page reads.

Four different reasons there is nowhere to deliver to

They look similar in a summary and they mean completely different things, so they are reported as four answers rather than as “no MX”.

The domain does not exist. DNS says the name is not registered at all. This is the typo case, and it is the single most useful result this page gives: somebody wrote gmail.cmo and has not noticed. Nothing will ever be delivered and no retry will help.

The domain exists and publishes no MX. Somebody registered the name and never pointed mail anywhere. Parked domains look like this, and so do registered typosquats — a near-miss of a popular domain, bought deliberately, serving no mail. Senders fall back to the web server, get refused, and retry for days before bouncing.

The domain refuses mail on purpose. A null MX (RFC 7505) is the single record 0 ., and it means “this domain will never receive mail”. That is the opposite of publishing nothing: senders reject immediately instead of queuing for days. If you own a domain that only serves a website, this is the setting you want on it.

We could not read DNS.Not an answer about the domain — an answer about the lookup. A slow nameserver, a dropped packet, a domain whose own DNS is briefly down. Treating this as “not deliverable” would be inventing a verdict out of our own failure, so the page says plainly that nothing follows from it and asks you to try again.

Why the domain can be refused before anything is looked up

Some things after an @ are not public domains, and asking a resolver about them is at best pointless. An IP address in brackets, localhost, a .internal or .local name, a label that is not a valid hostname label, a last label made of digits: each of those gets a named answer here rather than a lookup.

That is a result, not a failure — “the part after the @ is not a public domain” is precisely the thing you asked. It is also a boundary we keep on purpose: the domain out of a stranger’s address is untrusted input, and an anonymous form that will point our resolver at anything is a form other people will point at things.

What comes back, and what does not

The answer contains the domain. It does not contain the part before the @ — that answered the grammar question on our side and went no further: not into a cache key, not into telemetry, not into a log line. The address shown in the report is the one still sitting in this browser, which is why it survives a response that never mentioned it.

DNS answers are cached for a few minutes, so that a popular link does not turn into a flood of identical queries. If you have just changed your records and still see the old ones, the result says when it came from the cache.

What “verification” is, mechanically

There is only one way to find out whether a mailbox exists without sending to it. You open an SMTP session to the domain’s mail server, say MAIL FROM with some address, say RCPT TO with the address you are testing, read the response code, and hang up before DATA. A 250is taken as “exists” and a 550as “does not”.

That is the entire trick. Every “real-time mailbox verification” feature you have seen is this, at scale, from somebody’s IP addresses. It is a connection to a third party’s server, made to ask a question about one of their users, by somebody who has no intention of sending them anything.

It does not reliably work

Catch-all domains accept everything. A domain configured to receive mail for any local part answers 250 to every RCPT TOit is given, including addresses nobody has ever used. A large share of company domains are configured this way. The probe returns “valid” and has learned nothing.

Large providers answer the same way on purpose. Accepting at RCPT TO and deciding later is both a defence against exactly this kind of enumeration and a perfectly ordinary design. So the biggest mailbox hosts in the world — precisely the ones most addresses live at — give you an answer that carries no information.

Greylisting makes the answer depend on when you asked. A server that temporarily rejects a first attempt from an unknown sender returns a 4xx, which is neither yes nor no. Ask again later and the answer changes. A check whose result depends on the time of day is not a check.

What is left, once you remove the catch-alls, the big providers and the greylisters, is a minority of domains where a probe tells you something — and where a wrong answer still costs you a real recipient you have decided not to mail.

And it is not ours to spend

Maski forwards mail. That means our sending reputation is the product: if our IP addresses get a bad name, every alias every person here uses starts landing in spam folders. Wiring a public form with no account behind it to an SMTP prober would point anonymous, unlimited, stranger-supplied traffic straight at that.

And at the far end, probe traffic is indistinguishable from the thing it resembles. List scrubbing and address enumeration look exactly like this: many connections, RCPT TO after RCPT TO, never a message. Receivers block IP ranges for it, and they are right to. We would be spending the deliverability of everyone’s forwarded mail on a feature whose answer we have just explained is unreliable.

There is a quieter reason too. A tool that verifies mailboxes in bulk attracts people who want to verify mailboxes in bulk. That is not the audience a privacy product should be building for, and pretending otherwise because the traffic would be good is not a trade we are interested in.

So the honest answer is a send

If you need to know that an address reaches a person, mail something to it with a link in it and see whether the link is followed. That is the only proof, and it is the one every confirmation email has been quietly performing for thirty years.

Everything else narrows the field without answering, and this page is the cheap, honest end of “narrowing the field”: it catches the misspelled domain, the address that cannot parse, the domain that has never received mail. Those are most of the bad addresses in a signup form, and none of them cost anybody a probe.

The grammar allows more than anyone takes

RFC 5322 is generous in ways that surprise people. "odd one"@example.com has a space in it and is a legal address. So is "a@b"@example.com, where the @ that matters is the last one. So is user@[192.0.2.1], which names a host and skips DNS entirely. A great deal of software rejects all three, and that software is not exactly wrong — it is refusing things it cannot handle.

Which is why the report tells you two things rather than one: whether the address is legal, and where it sits in the gap between legal and what real receivers take. If you are debugging a form that rejected your address, the useful finding is usually “this is valid, and being rejected is normal”.

Which is also why a pattern is the wrong gate

A regular expression can only answer the legal-or-not question, and it cannot even do that properly — the grammar permits nested comments, which no regular expression can match at arbitrary depth. It certainly cannot tell you that the domain does not exist, which is where most bad addresses in a signup form actually fail.

There is a longer version of that argument, with copyable patterns for the cases where a loose check is genuinely the right thing, on the sibling page: Email regex generator.

The shape that works: a loose check in the browser that asks is this what you meant? rather than refusing, a domain check like this one to catch the typo before you spend a send on it, and a confirmation mail that does the actual proving. If your check and your mail disagree, trust the mail.

A +tag is the weak version of a good idea

name+shop@example.com is legal and widely supported, and the reason people use it is a good one: give a different tag to each company and you can tell who leaked your address. The report flags it because plenty of signup forms reject it — sometimes, pointedly, to stop exactly that.

It is also undone in one line of code. Everything before the + is the same mailbox, so anyone holding the address can strip the tag back to your real one, and list brokers do. A separate address per sender has no shared stem to strip, which is what Maski does instead — when one of them starts selling you on, you switch that one address off rather than changing your mail provider.