Syntax Check vs MX Check vs SMTP Verification: What Each Catches

A syntax check confirms an address is correctly formed. An MX check confirms the domain publishes mail servers. An SMTP check asks that server whether the specific mailbox exists. Each catches failures the previous one cannot see, and only the last one says anything about the person. Real lookups below show exactly where each layer stops.

Most explanations of this stop at "syntax is weak, MX is better, SMTP is best". That is true, but it hides the interesting part: each layer has edge cases where the obvious reading is wrong. We ran the DNS lookups in this post on 1 October 2026 with dig, from an ordinary connection. The raw output is in our research notes.

The three layers at a glance

Each layer answers a different question, and none of them can answer the next one's.

Layer	Question it answers	Cost	Catches	Cannot catch
Syntax	Is this shaped like an email address?	Microseconds, no network	Missing @, spaces, double dots, over-length parts	Typo domains, dead domains, dead mailboxes
MX / DNS	Can this domain receive mail?	One DNS query	Non-existent domains, null MX, most typo domains	Dead mailboxes on live domains
SMTP RCPT TO	Will this server accept mail for this mailbox?	A TCP connection on port 25, a few seconds	Deleted and never-existed mailboxes	Catch-all domains, servers that accept then bounce

Layer 1: syntax

Syntax checking rejects input that cannot be an address, and nothing else. It is the only layer that runs without a network, which makes it ideal for instant form feedback and useless as a verdict.

What it legitimately catches:

Input	Why it fails
jane.doe.example.com	No @
jane doe@example.com	Unquoted space
jane..doe@example.com	Consecutive dots in an unquoted local part
jane@	No domain
A 70-character local part	RFC 5321 section 4.5.3.1.1 caps the local part at 64 octets

What it lets through, correctly, because these are all valid syntax:

• asdkjhaslkdjh@gmail.com: well formed, certainly not a person.
• jane@gmial.com: well formed, wrong domain.
• jane+newsletter@gmail.com: well formed and real. Plus addressing is legitimate and a strict regex that rejects it is turning away real users.

The common mistake is going the other way and writing a regex so strict it rejects valid addresses. We cover why in why email validation regex fails. For a verification pipeline, syntax only needs to be strict enough to stop garbage before you spend a DNS query on it.

Layer 2: MX and DNS

The MX layer asks DNS which servers accept mail for the domain, and the answer has more than two possible shapes. Most guides treat it as yes or no. Here is what we actually got back for ten domains:

Domain	DNS status	MX answer	What it means
gmail.com	NOERROR	Five Google MX hosts	Can receive mail
outlook.com	NOERROR	outlook-com.olc.protection.outlook.com	Can receive mail
nonexistent-domain-zz918273.com	NXDOMAIN	none	Domain does not exist. Invalid, with certainty
example.com	NOERROR	0 .	Null MX: explicitly accepts no mail
yahoo.co	NOERROR	0 .	Null MX. A typo of yahoo.com that refuses mail
gmial.com	NOERROR	none, but an A record exists	No MX. See the implicit MX rule below
gmai.com	NOERROR	1 mail.h-email.net.	A typo domain with a working MX
hotmial.com	SERVFAIL on first query, then 5 mail.h-email.net.	A temporary DNS failure, then a working MX	Retry, never decide on SERVFAIL

Four lessons are packed into that table.

Null MX is a definitive "no"

example.com and yahoo.co publish a single MX record pointing at . with preference 0. That is a null MX, defined in RFC 7505: "To indicate that a domain does not accept email, it advertises a single MX RR ... with ... preference number 0 and a zero-length label". A naive check that only asks "is there an MX record?" sees a record and passes the domain. A correct one recognises the dot and fails every address on it. You can check any domain with the MX lookup tool.

No MX is not quite the same as no mail

gmial.com has no MX records but does have an A record. Under RFC 5321 section 5.1, "If an empty list of MXs is returned, the address is treated as if it was associated with an implicit MX RR ... pointing to that host." In other words, a sending server is supposed to try the A record.

In practice, a domain with no MX and only a parked web page almost never runs a mail server, so the delivery attempt fails. But the strictly correct behaviour is to treat "no MX, has A" as "try the host on port 25", and to fail it only if nothing answers. Treating it as instantly invalid is usually right and occasionally wrong.

Typo domains can pass the MX check

gmai.com and hotmial.com both publish an MX pointing at the same third-party host, mail.h-email.net. Mail sent there is not going to the person who mistyped their Gmail address. The MX layer cannot tell you that. It reports, accurately, that the domain receives mail. This is why typo detection is a separate check from DNS: it compares the domain against a list of known misspellings of large providers. See catching email typos at signup.

SERVFAIL is not NXDOMAIN

Our first query for hotmial.com returned SERVFAIL. A second returned an MX record. RFC 5321 is explicit that a non-existent domain "MUST be reported as an error" while "If a temporary error is returned, the message MUST be queued and retried later." A verifier that marks SERVFAIL as invalid will delete real addresses whenever a DNS server has a bad minute.

Layer 3: the SMTP mailbox check

The SMTP check is the only layer that asks about the mailbox rather than the domain. The verifier connects to the highest-priority MX host on port 25, introduces itself, names a sender, and then names the recipient with RCPT TO. The server's reply code is the answer, and the connection is closed before any message is sent. The full conversation is shown step by step in how to check an email without sending.

What it catches that the earlier layers cannot:

Address	Syntax	MX	SMTP
former.employee@company.com (mailbox deleted)	Pass	Pass	Rejected, 550 5.1.1
random-string-xyz@gmail.com	Pass	Pass	Rejected, 550 5.1.1
real.person@gmail.com	Pass	Pass	Accepted, 250

This is the layer that matters for hard bounces on a list of real people. When people leave jobs or abandon accounts, the domain keeps working and only the mailbox dies, so only this layer sees it.

Where SMTP stops

The SMTP layer has its own limits, and they are why a fourth outcome, risky, exists:

• Catch-all domains reply 250 to every address, including ones that cannot exist. A good verifier tests a random address first to detect this. See what is a catch-all domain.
• Accept-then-bounce providers say 250 at RCPT TO and bounce later. Yahoo is the best-known example, covered in why Yahoo addresses are hard to verify.
• Greylisting and timeouts return a temporary 4xx code or nothing at all. Retry later.
• Blocked port 25 on the verifier's side. The check never happens. We measured this on cloud hosts in cloud providers block port 25.

In every one of those cases the honest output is risky or unknown. Reporting valid is a guess.

Which layers you need, by situation

Use as many layers as your latency budget allows, and never stop at syntax for anything you intend to send to.

Situation	Layers to run	Why
Live form field, as the user types	Syntax only	Instant feedback, no network calls
Form submission	Syntax + MX + typo check, SMTP if it returns within your timeout	See real-time verification on signup forms
Cold email list before a campaign	All three, plus catch-all detection	A dead mailbox costs reputation, not just a wasted send
Old newsletter list being re-mailed	All three	Decay is in the mailbox layer, which syntax and MX cannot see
Data entry clean-up in a CRM, no sending planned	Syntax + MX	Cheap, finds the dead domains

How SimpleVerifier runs them

We run the three layers in order and stop as soon as one gives a definitive answer: broken syntax or a domain with no mail server returns invalid without opening an SMTP connection. Live domains go to the RCPT TO check. Anything the mail server would not confirm, including catch-all domains, comes back risky, never valid.

Practical takeaway

Syntax is a filter, MX is a domain test, SMTP is the mailbox test. If a tool or a script you wrote stops at MX, it is telling you the domain works and nothing about the person. Before you trust any of them, read the DNS response properly: NXDOMAIN and null MX are hard failures, SERVFAIL is a retry, and a typo domain with a live MX is a problem no DNS lookup will flag.

To see all three layers run on one address, try the free email verification tool.