Email Validator — Syntax and Email Domain Validation

Four Questions Hide Inside "Is This Email Valid?"

The question sounds like one thing and is really four, arranged in order of how confidently they can be answered from outside. Being clear about which one you are asking explains both what this tool reports and why no tool can promise more.

The first three are what a validator does. The fourth is what people usually want, and it is the one that cannot be answered honestly without sending mail. Everything below is about that gap.

Syntax: the Rules Are Looser Than Most Forms Assume

Addresses split at the last @ into a local part and a domain. The domain half is strict. The local half permits considerably more than typical sign-up forms accept, which is why perfectly real addresses get rejected at checkout.

The plus-addressing row causes real commercial damage. Some sign-up forms strip or reject it, and a customer who gave you [email protected] then finds the address you send to does not match the one they filter on. Rejecting valid syntax costs you customers silently, while accepting it costs you nothing.

Domain Validation: What an MX Record Proves

This is the check most people are actually looking for when they search for email domain validation, and it is worth understanding precisely.

An MX record is a DNS entry naming the server that handles mail for a domain. Its presence means someone has deliberately configured that domain to receive mail, which is a strong signal that addresses there can work. Its absence is the interesting case.

• The domain does not resolve at all. Nothing exists at that name. No address there can receive mail, so the address is not deliverable.
• The domain resolves but has no MX record. The classic case of a typo landing on a real but mail-less domain, or a parked domain. Mail may still fall back to the address record in some configurations, so this is flagged as risky rather than invalid — a distinction worth keeping, because treating it as a hard failure will occasionally reject someone real.
• MX records are present. The domain accepts mail. This says nothing about the individual mailbox.

Domain checks are also the fastest way to catch a typo, because misspelled providers rarely have mail configured. If you want to inspect the underlying records directly, our DNS lookup tool shows the MX entries for any domain.

The Mailbox Is the One You Cannot Check

Whether that particular person exists at a working domain is, from the outside, close to unanswerable. It is technically possible to open a connection to the mail server and ask, and it is a bad idea for four reasons.

• Catch-all domains accept everything. Many organisations configure the server to accept mail to any address at the domain, so it answers yes to every question you ask. The result is meaningless.
• Servers deliberately mislead. Accepting every address at the connection stage and rejecting later is a standard defence against exactly this kind of enumeration.
• Greylisting delays first contact. A temporary rejection on first attempt is normal behaviour, and reads as a failure if you only ask once.
• It damages your sending reputation. Repeated probe connections from one address look like address harvesting and get that address blocked, which harms the mail you actually want to deliver.

The honest position is that syntax and domain checks eliminate the addresses that definitely cannot work, and a confirmation email establishes the rest. Any service claiming certainty about mailbox existence is overstating what the protocol allows.

Disposable and Role Addresses Are Valid but Different

Two categories pass every technical check and may still not be what you want. Both are policy decisions rather than validity findings.

Disposable addresses come from services providing throwaway inboxes that expire in minutes. They are technically deliverable and almost never worth keeping on a list — the mail arrives somewhere nobody will read.

From the other side of the form, a disposable address is a privacy tactic rather than a nuisance: it lets someone try a service without handing over an inbox they intend to keep. That trade-off, and others like it, are covered in online privacy and security basics.

Role addresses — info@, support@, sales@, admin@ — reach a function rather than a person, often a shared inbox or a ticketing queue. They are entirely valid for business correspondence and a poor fit for anything personalised, since consent and identity are ambiguous when several people read one inbox.

The useful framing is that a validator tells you what an address is, and your own rules decide what to do about it. A support desk should accept role addresses without hesitation; a personalised newsletter probably should not.

Where Bounces Actually Come From

The third row is regularly misdiagnosed. When a whole campaign bounces from one provider, the addresses are rarely at fault — the more likely causes are missing authentication records or a reputation problem, and cleaning the list will not fix either. SPF, DKIM and DMARC are the records involved, and the DNS lookup tool will show whether yours are published.

Validating Without Losing People

Validation has two failure modes and they are not symmetrical. Letting a bad address through costs one bounce. Rejecting a good one costs a customer who will not tell you why they left.

• Accept everything the addressing rules permit, including plus signs, apostrophes and long extensions. Over-strict validation rejects real people.
• Warn rather than block on a suspected typo. Suggest the correction and let the person decide — they know their own address better than the form does.
• Treat a missing MX record as a warning, not a rejection. It is usually a typo and occasionally an unusual but working setup.
• Confirm by sending. A confirmation link is the only check that proves the address reaches the person who typed it.
• Re-validate old lists before large sends. Domains lapse and mailboxes close, so a list validated two years ago is no longer clean.

Email Validation Questions