Email Address Validator
Validate an email address format and check the domain's MX records.
Email Address Validator checks whether an address is in a valid formatand whether its domain can actually receive mail by looking up the domain's MX (mail exchanger) records — all in one step. It helps you catch obvious typos or non-existent domains in sign-up forms, newsletter opt-ins, and contact forms before they enter your list.
Validation runs in two stages. First it checks the local@domain structure and allowed characters with a robust rule set; if the syntax passes, it extracts the domain and queries public DNS for MX records. When no MX exists, it falls back to the A record (implicit MX) to estimate whether the domain can receive mail. For deeper domain diagnostics, view all records with DNS Record Lookup.
What it checks — and what it can't
This tool verifies two things: (1) whether the address is in an RFC-compliant format, and (2) whether the domain has a mail-receiving record (MX, or A as a fallback). When both pass, the overall verdict reads "likely deliverable." But that is a likelihood, not a guarantee.
- Syntax check: the position of the @, local and domain length, allowed characters, and dot placement.
- MX presence: whether the domain is configured to receive mail (delegated to a mail server).
- A fallback: if there is no MX but an A record exists, it is treated as an implicit MX and counted as deliverable.
The limits of email validation
Even when both the syntax and MX are fine, this tool cannot tell whether the actual mailbox exists. Only the mail server knows whether a specific username is registered.
- SMTP pings are unreliable: probing a mailbox with RCPT TO is often wrong because of catch-all addresses, greylisting, and deliberately misleading responses. Excessive SMTP attempts can also harm your sending IP's reputation.
- Disposable and role addresses: a valid format and MX can still be a throwaway domain or a role address like
info@oradmin@. - Double opt-in is the real check: sending a confirmation email and having the user click a link is effectively the only reliable way to verify true receipt and ownership.
Format rules seen through verdicts
Here is how some easily confused inputs are judged. Note that even when the syntax passes, the domain stage filters again with an MX/A lookup.
| Input | Verdict | Why |
|---|---|---|
user.name+tag@gmail.com | Pass | Dots and plus tags are allowed. +tag is sub-addressing and is a valid address. |
user@例え.jp | Pass (IDN) | Internationalized domains are converted to xn-- punycode internally before the MX lookup. |
user@gmail.con | Syntax pass / MX fail | A typo (.con) is syntactically legal, but the domain has no MX/A, so it is flagged as undeliverable. |
user..name@x.com | Fail | Consecutive dots, or a dot at the start/end of the local part, are not allowed. |
user@localhost | Fail | A single-label domain with no dot is not a public mail target, so it is rejected. |
info@example.com | Pass (role caution) | Even with valid syntax and MX, role addresses like info@ or admin@ may have low personal reach. |
A real verdict walkthrough
Suppose John@Gmail.COM comes in with surrounding whitespace and mixed case. The steps are: (1) trim the ends → John@Gmail.COM, (2) confirm a single @ and normalize the domain to lowercase → gmail.com, (3) syntax passes, (4) look up MX for gmail.com→ Google's mail servers are found → final verdict "likely deliverable." The case of the local part (John) is preserved per RFC and is not lowercased on its own.
Common pitfall
- Reading "syntax pass" as "sendable": typos like
.conorgmial.compass the format rules perfectly. Without the domain-stage MX/A lookup they are never caught, so never decide to send based on the syntax check alone. - Pasting the display name too: a form like
John <john@x.com>with a display name fails the format check. Only the bare addressjohn@x.comis what gets validated.