How an email validator works technically

The first filter is RFC 5322. The address is split into a local-part and a domain. The validator checks total length (up to 254 characters), allowed characters, the absence of consecutive dots, and correct quoting.

A common mistake is thinking a regex can handle this. The formal grammar for an email address is 6,343 characters of regular expression. Real validators use a parser, not a regex.

The domain passed syntax. Now we check whether it can receive mail at all. The validator sends an MX query for the domain.

No MX records? Fall back to an A record lookup (RFC 5321 fallback). If there is no A record either, the domain cannot receive mail, and checking further is pointless.

One subtlety: some domains return an MX record with priority 0 and a hostname of ".". That is a null MX (RFC 7505), an explicit declaration that the domain refuses all mail. Those addresses are rejected too.

This is the main event. The validator connects to the MX server and simulates the start of a delivery without actually sending anything. The technique is called SMTP callback verification.

A 250 on RCPT TO means the mailbox exists. A 550 means it does not. Everything else is ambiguous: 450 (try again later), 421 (server overloaded), 552 (mailbox full).

One thing worth noting: we never send DATA. The connection drops after RCPT TO. No email is delivered, and the load on the receiving server is minimal.

This is also where things get hard. Google, Yahoo, and Microsoft can all detect bulk SMTP probes and respond 250 to any address, including nonexistent ones, to protect user privacy. A solid validator handles this with IP rotation, request throttling, and provider-specific logic built up over time.

Some domains accept mail at any address. Send to x7k9m2q@domain.com and the server returns 250 OK. When that happens, a positive SMTP response proves nothing about the specific mailbox.

Detection works by sending a RCPT TO with a deliberately invented address (a random string). If the server says 250, the domain is catch-all. The address gets flagged as "accept-all" with a warning that deliverability cannot be confirmed.

Around 18% of corporate domains run catch-all configurations. For marketers, these are a problem: if the real inbox does not exist behind the catch-all, every send to it is a hard bounce waiting to happen.

The address exists, the domain accepts mail. But the domain is a throwaway service. Tempmail, Guerrilla Mail, Mailinator, and roughly 40,000 others create inboxes that expire in 10 minutes and then disappear.

This check runs against a database. Good validators update their disposable domain list daily, because new ones appear every day. It is a constant race: temporary mail services register fresh domains, validators add them to the blocklist.

Extra signal: if a domain was registered yesterday and its MX points to a known disposable host, it gets flagged as "risk" even before it appears in the database.

All stages are done. The validator assembles the results into a single response:

The score is not binary. A catch-all address gets 0.6; a disposable one gets 0.1. A clean address with an SMTP confirmation scores 0.9 or above. The score is what lets you make decisions: the threshold for transactional mail differs from the threshold for a marketing campaign.