Email Address Verification: How to Read an Email Verifier Result
Understand syntax, domain and mailbox checks, handle uncertain verification results, and know when to confirm access with an email link or code.
Use with your tools
An email verifier checks an address for problems that could prevent delivery. It can catch malformed input, a domain without a usable mail destination, or a mailbox rejection before you send an important message. The result depends on which checks ran and what the receiving service disclosed.
That leaves two questions to keep separate: is this address likely to accept mail, and can the person who entered it open that mail? A signup form needs both answers. A contact-list check mainly helps with the first, alongside the permission and suppression records you already hold.
What an email verifier actually checks
Read the reason behind a result before turning it into an accept or reject rule. A spelling error, a failed DNS lookup and a server that declines to verify a mailbox need different responses.
Syntax validation
A syntax check asks whether the input has an acceptable address structure. It catches an omitted @ or an empty domain, but a perfectly formed address can still name a mailbox that does not exist.
Use a maintained library compatible with your sending system and preserve the original address. Lowercase the domain for comparison; do not silently remove dots or +tags. The email validation regex guide covers implementation choices, and OWASP's email validation guidance explains comparison policies.
Domain and mail-routing checks
DNS tells the sender where to try delivery. An MX record names a mail exchanger; its presence alone proves neither that the server is available nor that a particular mailbox exists.
| DNS finding | How to interpret it |
|---|---|
| Ordinary MX records | The domain advertises mail destinations. Delivery still needs to succeed. |
| No MX records, but usable A or AAAA records | SMTP has an implicit-MX fallback to the domain itself. Do not reject solely because MX is absent. |
Null MX, written as 0 . |
The domain explicitly says it accepts no email. |
NXDOMAIN |
The queried domain does not exist. Check for a typo. |
Timeout or SERVFAIL |
The lookup is inconclusive. Hold and retry rather than declaring the address invalid. |
The fallback and temporary-error handling come from SMTP's DNS rules. Null MX is a separate, explicit declaration, not an empty MX answer.
Mailbox-level verification
A mailbox check may ask the receiving SMTP service about an address. An acceptance response is useful evidence at that point; it is not proof that a later message will reach the inbox. SMTP also permits a server to report that it cannot verify a user while still attempting delivery. See RFC 5321's verification response rules.
Catch-all domains add another complication: they may accept mail for names that were never assigned to individual mailboxes. Cloudflare's catch-all routing example shows how even a misspelled local part can reach one shared destination. Treat a catch-all finding as uncertainty about the intended recipient, not as proof of a bad address.
Verification result categories
Verifier labels differ, so read the findings and choose an action in your application:
| Finding | Next action |
|---|---|
| Malformed input, or a confirmed nonexistent domain or mailbox | Ask for a corrected address, or exclude the record from the send. Keep the reason. |
| DNS or connection failure, incomplete check, or unknown result | Hold for retry or review. Do not convert a failed check into a permanent rejection. |
| Catch-all acceptance | Review the contact source and previous delivery history; confirm access when the person is present. |
| Successful checks | Continue only if the address is eligible for that message, then monitor the actual delivery outcome. |
A role address such as support@ can be a working shared mailbox. A disposable-address flag describes a kind of service. Decide whether either fits your application's needs without relabeling it as a syntax error or a nonexistent mailbox.
At larger volumes, repeating checks and joining the results back to contact records becomes the practical problem. MailSlurp is an email testing platform with an email validation API for checking address lists, alongside controlled inboxes for testing the messages your application sends. Keep each returned result attached to the address you submitted and apply your own review and suppression rules.
Confirm access when an address identifies a user
Someone can enter a real address that belongs to somebody else. Passing syntax, DNS and mailbox checks should therefore leave a new account's email unconfirmed until the person completes an email challenge.
For a signup flow, send a random, single-use link or code with an expiry, and mark the address confirmed only after the challenge succeeds. Tie it to the pending account and exact address; a change of address requires a new confirmation. This follows OWASP's ownership-verification guidance. Successful confirmation demonstrates access at that time, not someone's legal identity or permanent control of the mailbox.
Test this separately from address validation. In a controlled MailSlurp inbox, submit a signup, receive its message and complete the challenge. Then check that expired, already-used and wrong codes fail. The OTP testing guide covers those cases, including resends and magic links.
Check imported lists without losing suppression history
For an import, keep the original contact ID, address, subscription status and previous bounce reason before running verification. A valid result must not reactivate an unsubscribe, complaint or existing suppression. Verify only the contacts that are otherwise eligible for the intended message.
Join results back to the submitted addresses, retain incomplete checks for review, and compare the eligible list with your current suppression records again before sending. The email-list verification procedure explains how to prepare a list, use MailSlurp's batch endpoint and handle the returned results.
Use delivery failures to decide what to check again
Verification is a snapshot. A mailbox can close after a successful check, and a working address can reject a message because of sender authentication, policy or message content.
Keep the full bounce reason. A confirmed nonexistent recipient calls for address correction or suppression; a sender-policy rejection calls for investigating the sender before another attempt. The email bounce diagnosis guide explains that distinction. If many previously working addresses fail at the same provider, investigate the shared delivery problem before removing them all from your list.