Webmaster & Network·4 min read

Email Syntax vs Deliverability: What a Check Proves

A signup form that accepts anything containing an @ will happily store addresses that can never receive mail. The fix starts with understanding email syntax vs deliverability: syntax says an address is well formed, deliverability says a message will actually arrive, and there's a surprising amount of daylight between the two. A validator can prove the first and estimate the second, but only a real delivery attempt settles it. Here's what each layer of checking buys you, where it stops, and how to use those limits honestly instead of pretending they don't exist.

Open the tool All insights

The gap between email syntax vs deliverability

Well formed and reachable are different claims.

user@gmali.com is perfectly valid syntax and perfectly undeliverable, because the typo'd domain isn't running mail. Meanwhile an address at a real company can be syntactically fine, route to a real server, and still bounce because the employee left last quarter. Format, domain, and mailbox are three separate claims, and each needs its own evidence.

This distinction matters commercially, too. Bounce rates above a few percent damage your sending reputation with providers like Gmail, and a damaged reputation hurts delivery to your good addresses. Filtering out the provably bad ones before you send is cheap insurance.

The three layers of validating an email address

Each layer catches a different failure.

Layer one is syntax: does the string follow the format rules, one @, a valid local part, a plausible domain. This catches typos and garbage input instantly, offline, with zero network cost.

Layer two is the domain: does it publish MX records in DNS, meaning some server has agreed to accept mail for it? This catches misspelled domains and abandoned ones. Layer three is the mailbox itself, and here's the honest part: no external tool can reliably verify it. Only the receiving server knows whether a mailbox exists, and many are configured not to say. The Email Validator on this site performs layers one and two and tells you plainly that layer three remains unknown.

A worked example: three addresses through the checks

Same tool, three different verdicts.

Input: sales@@example.com gives Syntax: Failed, and the MX lookup never runs, since a malformed address can't be routed anyway. The fix is editorial, not technical: remove the second @.

Input: hello@gmail.com gives Syntax: Passed and MX: Passed, with a record table showing servers like gmail-smtp-in.l.google.com at priority 5, lower numbers being tried first. Input: team@this-domain-went-away-2019.com gives Syntax: Passed but MX: Failed, meaning mail sent there has nowhere to land and will bounce immediately. Two passes and one failure, and each verdict tells you the next move.

MX record checks: what the server list actually tells you

DNS reveals routing, not residents.

MX record checks read public DNS to find the servers accepting mail for a domain, sorted by priority. Seeing records that point at Google Workspace or Microsoft 365 tells you the domain has live, professionally hosted mail, which makes a random typo less likely. Seeing none tells you delivery is impossible today.

What the record list can't reveal is anything about individual mailboxes, quotas, or spam filtering on the receiving end. A domain with pristine MX records will still bounce mail to a deleted account. Treat an MX pass as necessary but not sufficient.

Validation mistakes that let dead addresses through

Most list-quality problems trace back to one of these habits:

Relying on regex alone. A format check waves through every plausible-looking address at a dead domain, which is exactly the category that bounces hardest.
Rejecting valid addresses with an overzealous pattern. Plus signs (name+tag@gmail.com), long TLDs, and hyphenated domains are all legal; strict homemade regexes reject real users.
Treating an MX pass as proof the mailbox exists. It proves the domain accepts mail, nothing more.
Validating once and never again. Addresses die as people change jobs; a list that was clean two years ago isn't clean now.

Disposable email detection and the checks beyond this tool

Know what you're not testing.

Disposable email detection means flagging throwaway providers like ten-minute inboxes, and it requires a constantly maintained domain blocklist, something a syntax and MX check doesn't include. If burner signups are a real cost for you, add a dedicated blocklist at the form level and treat it as a moving target, because new disposable domains appear weekly.

The other missing layer is SMTP mailbox probing, where a service half-initiates a delivery to see if the server accepts the recipient. It's slow, sometimes gets your IP flagged, and catch-all servers answer yes to everything, so even paid verification services report a confidence score rather than certainty. Anyone promising a definitive mailbox verdict from the outside is overselling.

Where Email Validator fits next to DNS Lookup

Use the Email Validator when the question is about one address: will mail to this contact plausibly arrive? For a wider view of the same domain, the DNS Lookup tool shows the full record set, including the TXT records that hold SPF and DKIM policy, which matter when you're diagnosing why your own outbound mail lands in spam.

And if you're mid-migration and want to confirm where a domain's infrastructure actually lives, Domain to IP resolves the address record directly. Three tools, three grains of detail: one address, one domain's mail setup, one domain's location.