How to Validate an Email Address Without Sending a Test Email

You have an email address. You want to know if it is real. The most reliable test is to send an email to it and see if it bounces. But you cannot always send that email — you are validating on a signup form, you do not have a real email to send, or you do not want to tip off a typo'd signup that they got the address wrong.

This post covers the three layers of email validation, what each catches, what each misses, and the right tool for each. The Uttir Email Validator runs the first two layers in your browser, with no upload. The third layer is the only one that actually confirms the address is deliverable, and it requires either sending a real email or paying for a mailbox-verification API.

Layer 1: syntax check

The cheapest layer. A regex (or a simple parser) checks that the address is shaped like an email: a local part, an @ symbol, a domain part, and a top-level domain. This catches the obvious garbage: addresses with no @, addresses with spaces, addresses with invalid characters, addresses that are obviously not email.

The standard regex is something like:

^[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,}$

This catches most of the obvious cases. The Uttir Regex Tester is the right tool to test any email regex you are using; paste the regex, paste some test addresses, see which match and which do not.

What syntax check misses: it does not know whether the domain exists. [email protected] passes the syntax check but is not a real address. It also does not know whether the local part is real. [email protected] passes the syntax check but might or might not be a real mailbox at uttir.com.

Layer 2: domain check

The middle layer. A DNS lookup checks whether the domain has mail-handling records (MX records). A domain with MX records is configured to receive email; a domain without MX records is not.

This catches a different class of invalid addresses. The address might be syntactically perfect, but if the domain is not configured to receive mail, the address is not deliverable. The DNS lookup takes about 100-500 ms for a typical query and works entirely through public DNS, so no authentication or API key is required.

The Uttir Email Validator runs the syntax check and the DNS-based domain check together. You paste the address, get a result in under a second, and the result tells you whether the address is syntactically valid AND whether the domain is configured to receive mail.

What domain check misses: it does not know whether the specific mailbox exists. A domain can have valid MX records and still not have the local part you are testing. [email protected] passes the domain check (uttir.com has MX records) but is not a real mailbox.

Layer 3: mailbox check

The expensive layer. The only way to know for sure that a mailbox exists is to actually try to deliver mail to it. This is either an SMTP-level test (connect to the mail server, attempt to send, see if the server rejects the address) or a real email send (send the email, wait for the bounce, see if it bounces).

The SMTP-level test is faster and does not require sending a real email, but it is intrusive: the mail server might rate-limit the check, or treat it as a probe and reject the connection. Some mail servers explicitly block SMTP-level mailbox checks to prevent address harvesting.

The real-email-send test is the most reliable. Send the email, wait a few minutes, check the bounce log. If the email bounced, the address is not valid. If the email was accepted, the address is valid (at least at the moment you sent it). This is what every transactional email service does on every send, and it is the only way to be 100% sure.

Third-party mailbox-verification APIs (ZeroBounce, NeverBounce, BriteVerify) run this layer at scale. They maintain lists of known-bad addresses, known-role-based addresses (info@, admin@, postmaster@), and known-trap addresses (spam-trap addresses that should never be on a marketing list). They charge per verification, usually fractions of a cent per address, and are the right tool for cleaning a large list before a campaign.

What to use when

The three layers serve different purposes. The right layer depends on what you are doing.

On a signup form. Run layer 1 (syntax) and layer 2 (domain). Both are fast (under a second combined), both are free, and both catch the most common errors: typos in the domain, addresses with no @, addresses from non-existent domains. Do not run layer 3 on signup; the SMTP probe is too slow and too intrusive for a real-time form check. After signup, send a confirmation email; that is the layer 3 test, and it is what every email service does.

Cleaning a list before a campaign. Run layer 1 (syntax) and layer 2 (domain) for free, then run layer 3 through a verification API for the addresses that pass. The verification API costs money but the cost is much smaller than the cost of sending to a list full of bad addresses (high bounce rate, sender reputation damage, possible blacklisting).

Validating a single address in a script. Run layer 1 (regex) inline, then call out to a DNS resolver for layer 2. Most languages have a DNS library built in. For layer 3, send the email and check the bounce.

Debugging an email delivery problem. Run all three. The syntax check tells you if the address is shaped right. The domain check tells you if the domain is configured to receive. The mailbox check tells you if the specific address is real. Most delivery problems are at layer 2 (the recipient domain is misconfigured) or layer 3 (the recipient mailbox is full, suspended, or rejected your message).

What these checks do not catch

A few things none of the layers can catch, that you should know about:

• Disposable addresses. Some services (Guerrilla Mail, 10MinuteMail, TempMail) provide throwaway addresses that pass every check but are designed to be abandoned. Catching these requires a blocklist of disposable domains, which changes constantly.
• Role-based addresses. Addresses like info@, admin@, support@ are valid mailboxes but are usually not what you want on a marketing list. They are also the addresses that are most likely to be spam-trapped.
• Temporary typos. [email protected] (a typo of gmail.com) passes the domain check (gmial.com is a real domain, just not the one the user meant). Catching this requires either a fuzzy-match check against a list of common email providers, or a confirmation email that proves the user can receive at the address.
• Addresses that will be valid in the future. A domain might be registered today but not configured for mail. The DNS check would say "no MX records" today, but the domain might have valid MX records next month. Re-validate periodically if you are storing the address for long-term use.

None of these are reasons to skip validation. They are reasons to not over-rely on it. A confirmation email is the only test that catches all of them; the layer 1 and layer 2 checks just catch the cheap and obvious ones first.

How to do it in your browser

The Uttir Email Validator runs layers 1 and 2 on any address, in the browser, with no upload. Paste the address, get the result. The Regex Tester is the right tool if you are writing the syntax check yourself and want to see which test cases your regex catches. The JSON Validator and JSON Formatter are the right companions if you are cleaning a list of email addresses in a JSON file. The URL Encoder is the right tool if you are passing the address as a URL parameter to a verification API.