How to Validate Email Addresses in Bulk: What Syntax, MX and SMTP Checks Really Prove

"Is this email address valid?" sounds like a yes-or-no question, but the honest answer is "valid for what?". An address can be perfectly formatted, belong to a real domain, accept SMTP connections and still be a dead mailbox, a trap or the wrong person. Understanding the layers helps you choose the right checks and avoid the two classic mistakes: rejecting good addresses and trusting bad ones.

The five layers of email validation

Layer	What it checks	What it proves	What it cannot prove
1. Syntax	Format against RFC 5321/5322 rules	The string could be an email address	That the domain or mailbox exists
2. Domain / DNS	MX record (or A fallback) for the domain	The domain accepts mail	That this mailbox exists
3. Risk signals	Disposable domains, role accounts, typos	Likelihood of low value or complaints	Anything about a specific person
4. SMTP probe	RCPT TO handshake without sending	A hint the server accepts the recipient	Reliable status (catch-all, greylisting, blocking)
5. Confirmation	The owner clicks a link you emailed	The mailbox exists and the owner consents	Nothing it cannot: this is the gold standard

Layer 1: syntax validation

Syntax rules are defined by RFC 5321 and RFC 5322. In practice you check: exactly one @, a local part up to 64 characters, a domain with valid labels (up to 63 characters each) and a real top-level domain, with no spaces or illegal characters, and a maximum total path of 256 characters (so an address of about 254 characters). Be careful not to be stricter than the standard: addresses containing + (name+tag@example.com) and internationalised domains are valid. A simple, safe rule set is:

^[^\s@]+@[^\s@]+\.[^\s@]{2,}$        # intentionally permissive: one @, a dot in the domain, a TLD of 2+ chars
# then: length(local) <= 64, length(domain) <= 255, no label > 63 chars, TLD not all digits

The permissive pattern is on purpose: a strict regex rejects real customers, and the DNS check in the next layer does the real filtering. Our email address syntax guide lists exactly what is allowed.

Layer 2: DNS and MX checks

A DNS query tells you whether the domain can receive mail. The rule: if the domain has an MX record, mail goes there; if it has none, SMTP falls back to the domain's A/AAAA record (the "implicit MX"); a "null MX" (a single . target, RFC 7505) explicitly declares that the domain accepts no mail. This catches typos such as gmial.com that have no mail servers and domains that have expired. A minimal programmatic check:

// Node.js
const dns = require('dns').promises;
async function canReceiveMail(domain) {
  try {
    const mx = await dns.resolveMx(domain);
    if (mx.length === 1 && mx[0].exchange === '') return false;   // null MX
    return mx.length > 0;
  } catch (e) {
    if (e.code === 'ENODATA' || e.code === 'ENOTFOUND') {
      try { return (await dns.resolve4(domain)).length > 0; } catch { return false; }  // implicit MX
    }
    throw e;                                                       // SERVFAIL/timeouts = unknown, not invalid
  }
}

Note the last line: a DNS failure is "unknown", not "invalid"; treating timeouts as invalid is a common way to delete good subscribers.

✉️Email ValidatorSyntax, MX, disposable and typo checks, single or bulkOpen the tool →

Layer 3: disposable, role and typo detection

• Disposable addresses (temporary inbox services) work briefly and are rarely read; excluding them improves list quality. Detection depends on a domain list that goes stale, so treat it as a signal, not a verdict.
• Role accounts (info@, sales@, admin@) are shared mailboxes with higher complaint and lower engagement rates.
• Typos in popular domains can be corrected or suggested, but never auto-correct without confirming: some look-alike domains are real.

Layer 4: SMTP verification and its problems

SMTP verification connects to the mail server and issues RCPT TO:<address> to see whether the server accepts it, then disconnects without sending a message. It sounds ideal but is fragile:

Server answer	Typical meaning	Reliability
250 accepted	Mailbox may exist, or server is catch-all	Low: catch-all domains accept everything
550 5.1.1 user unknown	Mailbox does not exist	High when it comes from the real mail server
450/451 temporary	Greylisting or rate limit	Unknown: retry later
Connection refused/blocked	Probing is blocked from your IP	Unknown

• Catch-all servers accept every recipient, so "accepted" proves nothing.
• Large providers block probing or return identical answers for all addresses, to prevent harvesting.
• Reputation risk: repeated probes from one IP look like a directory-harvest attack and can get your IP blocklisted.
• Privacy and legality: probing addresses of people who never gave you their address can conflict with data-protection rules.

For these reasons browser-based tools do not do SMTP probing, and you should treat "valid" from any SMTP checker as a probability, not a fact.

Layer 5: confirmation is the only real proof

If a mailbox must actually belong to the person, send a confirmation email with a unique link (double opt-in). A click proves existence, ownership and consent in one step, and it protects you from spam traps and typos made by real users.

A practical workflow for bulk lists

1. Normalise: trim spaces, lowercase the domain, remove duplicates (be careful with Gmail dots and plus-addressing; do not merge unless you are sure).
2. Syntax check: drop malformed entries and keep a report of the reasons.
3. DNS check: remove domains with no MX and no A record; keep DNS failures as "unknown" and retry.
4. Tag risk: separate disposable and role addresses and decide per campaign.
5. Send in stages: start with your most engaged segment, watch bounces, then widen.
6. Suppress hard bounces permanently after the first send.

🧹Email List CleanerRemove duplicates and invalid addresses, fix typos and split by providerOpen the tool →

Special cases that trip validators

Case	Example	Correct handling
Plus tags	ana+shop@example.com	Valid. Keep as typed; deliver to the full address
Dots in Gmail	a.na@gmail.com vs ana@gmail.com	Gmail treats them as one mailbox, but other providers do not: normalise only when you know the provider
Quoted local part	"ana smith"@example.com	Legal but rare; accept or reject by policy, not by accident
Internationalised domains	user@bücher.example	Convert the domain to Punycode (xn--bcher-kva.example) for the DNS check
Unicode local part (SMTPUTF8, RFC 6531)	用户@example.cn	Valid only if the receiving system supports it; flag as risky rather than invalid
Case	Ana@Example.COM	Domain is case-insensitive; keep the local part exactly, compare case-insensitively for duplicates only if your provider does
Trailing dot or spaces	ana@example.com.	Trim spaces; strip the trailing dot in the domain after reporting it

How to test a validator before trusting it

Whether you build your own or use a service, test it with a small set whose answers you know. Include 20 addresses that must pass (with plus tags, long TLDs, subdomains, Unicode domains), 20 that must fail (missing @, double dots, spaces, a 65-character local part), 10 domains that exist but have no mail (a null MX or no MX/A), and 10 real mailboxes of your own on different providers. Count false rejections separately from false acceptances: the first costs you customers, the second costs you bounces. A validator that rejects any of your must-pass addresses is too strict to run at sign-up, however good its other numbers are.

How to read a validation report

Status	Meaning	Action
Valid	Syntax and domain pass	Send; this still is not a mailbox guarantee
Risky	Disposable, role, typo suggestion	Segment; confirm or exclude per goal
Invalid	Malformed or domain cannot receive mail	Remove
Unknown	DNS or network failure	Retry later; do not delete

After the first send, bounce data corrects the picture: anything that hard-bounces moves to suppression, and the rate tells you whether the cleaning was enough. Keep bounces under about 2% and complaints under 0.1%, the numbers the Gmail and Yahoo requirements make you care about.

Privacy and consent while you validate

Validation is processing of personal data. Run it only on addresses you already have a lawful reason to hold, keep the results (valid, risky, invalid) rather than sending the raw list to more third parties than necessary, and prefer tools that work locally in the browser or on your own server. Cleaning a list never turns an address without consent into one with consent, and it does not change what you are allowed to send to it.

Common mistakes

• Using a regex found online that rejects + or new top-level domains.
• Treating "valid format" as "deliverable".
• Buying validated lists: validation does not create consent.
• Validating once and never again; addresses decay over time.
• Rejecting a sign-up because of an unusual but legal address, losing real customers.

Frequently asked questions

Can I verify that an email address exists without sending an email?

Not reliably. SMTP probing can hint at it, but catch-all servers, greylisting and blocking make results uncertain. The only certain method is a confirmation email.

What is a catch-all email address?

A catch-all domain accepts mail for any local part, so SMTP checks always look valid. You cannot tell whether a specific mailbox exists until you send.

Should I block disposable email addresses?

It depends on the goal. For newsletters and account creation they usually have low value, so many senders exclude them. For one-off downloads you may allow them.

Is an MX record check enough?

It proves the domain receives mail, which catches typos and dead domains, but not that the mailbox exists.

How often should I clean my email list?

Validate on capture, then run a bulk clean before large campaigns and at least a few times a year, removing hard bounces after every send.

References & further reading

1. RFC 5321 — Simple Mail Transfer Protocol
2. RFC 5322 — Internet Message Format
3. RFC 7505 — A "Null MX" No Service Resource Record
4. Google — Email sender guidelines