How to validate an email address without sending an email

The four layers of email validation

1. Practical syntax, not a mythical perfect regex

An email-like identifier has a local part, an @, and a domain. RFC 5322 permits more forms than most web forms expect, including quoted local parts. SMTP adds transport constraints: RFC 5321 specifies a maximum local part of 64 octets and a domain of 255 octets. Internationalized addresses add SMTPUTF8 and IDN considerations, so “RFC compliant” is not a useful one-bit marketing claim unless the supported profile is stated.

A practical validator should trim accidental surrounding whitespace, require one usable address rather than a display name or comma-separated list, reject empty labels and consecutive dots where they are not legal, normalize the domain for DNS, and preserve the local part. Do not lowercase or silently rewrite the whole address: local-part semantics belong to the receiving system.

2. Domain DNS: MX first, then the RFC 5321 fallback

Query the domain for MX records. An MX target must resolve to an address record, such as A for IPv4 or AAAA for IPv6. A common implementation error is to declare “no MX” invalid immediately. RFC 5321 says that when the MX lookup succeeds but returns an empty MX list, mail transport treats the domain as an implicit MX pointing to the domain itself. The validator must therefore try its A and AAAA records.

Keep “no records,” NXDOMAIN, DNS timeout, and SERVFAIL separate. A temporary resolver failure is unknown and may succeed later. Also recognize a Null MX: RFC 7505 defines a single MX 0 . record as an explicit declaration that the domain does not accept email. That is not the same as an empty MX answer and should not fall back to A or AAAA.

3. Disposable and role-address heuristics

A maintained domain list can flag temporary-mail providers. A local-part list can flag role accounts such as admin@, billing@, or support@. These are risk or routing signals, not validity failures. A disposable address may work now, and a role inbox may be exactly the correct contact for a vendor invoice.

Lists age quickly, custom domains can forward to disposable services, and words such as “sales” can also be a real person's local part. Return the observed flag and let the product apply an explicit policy. Do not hide a business rule behind a label such as “invalid.”

4. SMTP probing is unreliable—and can be rude

An SMTP probe connects to a receiving server, introduces itself, supplies an envelope sender, asks about the candidate with RCPT TO, and stops before DATA. It sounds decisive, but the reply is contextual. Greylisting intentionally gives a temporary failure to an unfamiliar sender tuple and expects a legitimate mail system to retry. A catch-all domain can accept every invented recipient during SMTP and reject or discard the message later. Large providers may conceal recipient status, rate-limit probes, tarp it, or answer differently by IP reputation.

Timeouts can mean a firewall or blocked outbound port 25, not a bad address. Repeated recipient probes also consume someone else's infrastructure and resemble directory harvesting. That can get the probing IP throttled or blocklisted, damaging real outbound mail. Probe only when you have a legitimate purpose and authorization, at low volume, with a valid identity; send RSET and QUIT, and never treat a temporary reply as permanent evidence.

Check if an email is valid with an API

Use the public endpoint for an individual check

The following requests use synthetic examples. They do not send a message. Because the email is a URL query parameter, it can appear in browser history, proxy logs, CDN logs, and server access logs. Do not paste a real person's address into a public test unless your privacy basis and retention controls permit it.

curl 'https://email.lifestep.io/validate?email=not-an-address'

curl 'https://email.lifestep.io/validate?email=person%40gmial.com'

curl 'https://email.lifestep.io/validate?email=alice%40example.com'

The first example should fail the supported syntax profile. The second is syntactically plausible but contains the common gmial.com transposition; the useful result is a suggestion to confirm gmail.com, not an automatic rewrite. The third separates syntax from mail routing: example.com is reserved for examples and advertises that it does not accept ordinary mail. Read the returned JSON as current evidence because DNS and provider data can change.

Make typo suggestions explainable

Compare only the domain against a curated set of common mail providers and your own known customer domains. Edit distance makes the rule auditable: standard Levenshtein distance counts the swapped letters in gmial as two substitutions, while Damerau–Levenshtein treats the adjacent transposition as one edit. Weight keyboard-neighbor mistakes and common top-level-domain slips carefully, then apply a conservative threshold.

Show “Did you mean person@gmail.com?” and require the user to choose. Never change the submitted domain silently. A short distance does not prove intent, especially for company domains or deliberately similar brands.

Interpret score and verdict separately

A score can summarize which checks passed, but it is not a deliverability probability unless it was calibrated against a representative, recent outcome dataset. Publish the components behind the number. A useful verdict model distinguishes invalid for decisive evidence, risky for policy flags or catch-all behavior, unknown for transient or inconclusive checks, and valid-looking for an address that passed the available layers.

Even a maximum score cannot promise that the mailbox exists, belongs to the claimed person, will accept the next message, will place it in the inbox, or gave marketing consent. Use a confirmation link for ownership, normal bounce handling for delivery, and a separate consent record for lawful outreach.

Batch validation without turning uncertainty into damage

1. Deduplicate exact normalized inputs while preserving an index that maps each result back to the source row.
2. Parse syntax first. Group valid-looking addresses by domain, cache DNS answers for their TTL, and avoid repeating the same lookup for every row.
3. Bound concurrency and respect rate limits. Retry DNS timeouts, HTTP 429 responses, and temporary SMTP results with jitter; do not retry permanent syntax or Null MX failures.
4. Preserve per-layer evidence and an explicit unknown state. One timeout must not downgrade a whole domain to invalid.
5. Measure removals against later confirmed bounces and signups. That is how a score becomes calibrated to your audience rather than merely looking precise.

Email addresses that identify people are generally personal data under GDPR. Validation is processing, even when no message is sent. Establish a lawful purpose, disclose any processor, minimize the fields and retention period, and secure the data. Most importantly, do not log raw email addresses in application, analytics, error, proxy, or tracing logs. Redact query strings and request bodies. If correlation is necessary, prefer a rotating secret-key HMAC over an unsalted hash, which is easy to reverse by guessing common addresses. Delete batch uploads and detailed results as soon as the operational purpose is complete.

Common questions

Can I verify that a mailbox exists without sending?

Not reliably. Syntax and DNS can reject clear failures, and an SMTP server may expose a recipient decision, but catch-all, greylisting, policy filtering, and reputation-based responses prevent a universal existence check. A confirmation email is the normal proof that someone controls the destination.

Should an address with no MX record be rejected?

Not immediately. If the MX lookup succeeds with an empty list, RFC 5321's implicit-MX rule requires checking the domain's A or AAAA address records. Reject a confirmed NXDOMAIN, unusable route, or Null MX; classify temporary DNS failures as unknown.

Is a role or disposable address invalid?

No. Those labels describe risk or product-policy signals. A role inbox can be the correct business destination, and a disposable mailbox may receive mail. Decide whether to allow, challenge, or review it based on the actual abuse cost.

What is the safest validation flow for signup?

Validate practical syntax, check DNS, offer a typo correction, accept inconclusive network results provisionally, and send a time-limited confirmation link. Keep validation and marketing consent separate, and never store the address in diagnostic logs.