Draft:Email verification

Process of checking if email addresses are valid From Wikipedia, the free encyclopedia


Email verification is the process of checking whether an email address is valid and able to receive messages. Also referred to as email validation or email list hygiene, it is used in email marketing and online registration to reduce bounced emails and protect sender reputation.

Email verification should not be confused with email authentication, which uses protocols like SPF, DKIM, and DMARC to verify that a message was actually sent by the domain it claims to come from. Verification is about the recipient side—confirming that the address on the other end is real and emailable.

Background

Invalid email addresses have been a problem since email became a commercial channel in the 1990s, but the issue grew worse as businesses began depending on email for marketing at scale. When a message is sent to a non-existent address, the receiving server generates a bounce message. Too many bounces damage a sender's reputation with ISPs, eventually causing legitimate mail to be filtered as spam or blocked entirely. Cross-industry benchmarks consider anything below a 2% bounce rate normal; rates above 5% are considered critical.[1]

Regulation has also pushed list hygiene into compliance territory. The CAN-SPAM Act (2003) in the United States established requirements for commercial email, with each violation subject to penalties of up to $53,088.[2] CASL (2014) in Canada and the General Data Protection Regulation (2018) in the European Union impose further rules that make maintaining accurate contact lists a legal concern, not just a deliverability one.[3]

In February 2024, Google began enforcing new requirements for anyone sending more than 5,000 messages per day to Gmail users. The rules mandate DMARC authentication, one-click unsubscribe, and spam complaint rates below 0.3%. Senders who fail to comply have their messages throttled or rejected.[4] Yahoo! announced similar requirements around the same time.[5]

As of 2026, the email verification software market is valued at approximately US$0.79 billion, with projections of reaching $1.1 billion by 2030.[6]

How it works

Verification typically runs several checks in sequence. An address that passes all of them is considered deliverable; one that fails at any stage gets flagged as undeliverable or risky.

Syntax validation

The most basic step is confirming that the address follows the formatting rules in RFC 5321 and RFC 5322. An email address takes the form local-part@domain, where the local part can be up to 64 octets and the domain up to 255.[7][8] This catches missing @ signs, spaces, double dots, and other formatting mistakes. Fast, but limited—a syntactically correct address can still point to a mailbox that doesn't exist.

Domain validation

The verifier then queries DNS for MX (mail exchange) records on the address's domain. MX records tell the internet which server handles incoming mail for that domain. If there is no MX record and no A record fallback, the domain simply cannot receive email. RFC 5321 specifies the MX lookup procedure and fallback behavior.[7]

SMTP verification

This step actually contacts the recipient's mail server. The verifier opens a TCP connection on port 25 and starts a partial SMTP session:

  1. EHLO — the verifier identifies itself
  2. MAIL FROM — provides a sender address
  3. RCPT TO — names the address being checked
  4. The server responds with a status code

A 250 response generally means the mailbox exists; a 550 means the address is unknown or the mailbox is unavailable. The full list of SMTP response codes is defined in RFC 5321.[7] The verifier disconnects before the DATA command, so no email is ever actually sent.[9]

A well-known limitation is that large providers like Gmail and Microsoft Outlook often accept all RCPT TO commands regardless of whether the address is real—they only bounce after full delivery is attempted. This makes SMTP-level verification unreliable for those domains.

Accept-all / Catch-all servers

Some domains are configured as accept-all servers, meaning they accept mail addressed to any local part, whether or not it corresponds to a real mailbox. A verifier pinging a completely made-up address still gets a 250 back, making it impossible to distinguish real users from dead ends through SMTP alone. This is particularly common in corporate environments, where administrators configure accept-all addresses to avoid losing messages sent to misspelled employee names.

Disposable and role-based addresses

Disposable addresses

Disposable email addresses (DEAs) are temporary, throwaway inboxes that typically last anywhere from ten minutes to a few hours. They are commonly used to avoid handing over a real address during signups or to claim promotions without commitment. Verification services maintain lists of known disposable domains, though detection is something of a cat-and-mouse game as new domains appear regularly.

Role-based addresses

Addresses like info@, admin@, sales@, and support@ belong to a department or function, not an individual. Standard mailbox names for common roles are defined in RFC 2142.[10] Marketing mail sent to these addresses tends to generate more spam complaints because the messages are seen by multiple people who didn't individually subscribe.

Bounces

Verification is closely tied to bounce handling. Bounces are classified by the SMTP response code returned by the receiving server:

  • Hard bounces are permanent failures, indicated by 5xx codes (for example, "550 User unknown"). The address doesn't exist, the account is disabled, or the domain doesn't accept mail. These should be removed from a list immediately.[7]
  • Soft bounces are temporary, signaled by 4xx codes. Causes include a full mailbox, a server that's temporarily down, or a message that exceeds size limits. The sending server can retry, and the issue often resolves on its own.[7]

Pre-send verification aims to catch the addresses that would hard-bounce and remove them before any mail goes out, sparing the sender's reputation.

Spam traps

ISPs and anti-spam organizations use spam trap addresses (sometimes called honeypots) to catch senders with poor list practices. The Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) and Spamhaus identify several types:[11][12]

  • Pristine traps are addresses that never belonged to a real person. They're seeded across the web specifically to be scraped or purchased by spammers. Hitting one is a strong signal that a sender's list was not built through opt-in processes.
  • Recycled traps are old addresses that were once real but were abandoned by their owner and later repurposed by the mailbox provider. M3AAWG recommends that repurposed addresses receive standard "no such user" rejection messages for a minimum of twelve contiguous months before being converted into traps.[11] Their presence on a list suggests it hasn't been cleaned in a long time.
  • Typo traps exploit common domain misspellings—gmial.com instead of gmail.com, for instance—to flag senders who don't validate addresses at the point of collection.[12]

Some email verification vendors market the ability to detect and remove spam traps from mailing lists. However, industry authorities are skeptical of these claims. Spamhaus notes that trap addresses are never revealed by their operators, and that when a sender does manage to identify one, "what usually happens is that the sender simply suppresses the trap address" without addressing the underlying data problem.[12] Deliverability consultant Laura Atkins has written that "none of the data hygiene services have reliably identified spamtraps that cause your mail to be blocked," and that such services may detect some commercial sensor-network addresses but not the traps actually responsible for blocking.[13] Spamhaus explicitly advises against conducting "a hunt for spamtraps" and instead urges senders to treat trap hits as evidence of a data collection or hygiene problem that needs to be fixed at its source.[12]

Complications

Greylisting

Greylisting is an anti-spam technique where a receiving server temporarily rejects the first connection from an unknown sender with a 4xx code, expecting legitimate servers to try again after a delay. Spammers typically don't bother retrying. RFC 6647 documents the practice and its effects on SMTP.[14] The problem for verification is that the initial RCPT TO gets a temporary rejection rather than a clear yes or no. The verifier has to decide whether to retry later or mark the result as inconclusive.

Throttling and IP blocking

Mail servers that see a single IP firing off hundreds of RCPT TO commands without ever actually delivering a message will often throttle or block the connection. This pattern—lots of recipient checks, no message content—is a well-known fingerprint of bulk verification, and servers treat it similarly to address harvesting by spammers.

Privacy

SMTP-based verification tells the receiving server that someone is probing for the existence of a specific address, which raises privacy concerns. Under the GDPR, email addresses are personal data, and processing them—even just checking whether they exist—requires a lawful basis.[3] This has pushed some organizations toward point-of-entry validation and double opt-in rather than bulk verification of existing lists.

Implementation

Bulk list hygiene

The most common use case is uploading an existing mailing list to a verification provider, which checks each address and returns it tagged as deliverable, undeliverable, risky, or unknown. This is often the first step when a company inherits a list through an acquisition or discovers its bounce rates climbing.

Real-time and point-of-capture validation

Verification can also happen at the point of capture—when an address is first entered. An API call fires when someone types their email into a signup form, and the result comes back before the form is submitted. This prevents bad data from entering the database in the first place and avoids the need for periodic bulk list hygiene.

Double opt-in

Double opt-in (or confirmed opt-in) is not a verification technology in the same technical sense, but achieves a similar goal. After a user enters their address, they get a confirmation email with a link they have to click before they're added to the list. This proves both that the address works and that whoever submitted it actually has access to the inbox. Double opt-in is considered best practice under the GDPR[15] and is effectively required by court precedent in Germany, where the courts have consistently ruled that verifiable confirmation of consent is necessary for marketing communications.[3]

See also

References

Related Articles

Wikiwand AI