Draft:Email verification

Submission declined on 22 June 2026 by Dreamyshade (talk). This draft appears to contain text generated by a large language model (such as ChatGPT). You cannot use LLMs to generate article content. LLM-generated pages with certain obvious signs of being machine generated may be deleted without notice. Instead, only summarize in your own words a range of independent, reliable, published sources that discuss the subject. See the advice page on large language models for more information. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by Dreamyshade 58 days ago. Last edited by Dreamyshade 58 days ago. Reviewer: Inform author. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

• Comment: Along with showing signs of having been generated or substantially modified by a LLM, the draft has an essay-like tone - for advice on mitigating this, see WP:NOTESSAY, WP:TONE, WP:PERSUASIVE. Most of the citations are to articles with background information instead of specifically about email verification, which creates WP:OR and WP:SYNTH issues as well - needs citations to articles specifically about email verification, such as scholarly/academic articles. Dreamyshade (talk) 16:49, 22 June 2026 (UTC)

• Comment: @JarrettLusso: Thanks for disclosing a conflict of interest! Can you clarify what your conflict is? For example, do you work for a company mentioned or cited in the article? That context will help with reviewing the article. Dreamyshade (talk) 08:19, 21 June 2026 (UTC)

• Comment: In accordance with Wikipedia's Conflict of interest guideline, I disclose that I have a conflict of interest regarding the subject of this article. JarrettLusso (talk) 00:40, 16 April 2026 (UTC)

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 is distinct from 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.

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. High bounce rates can affect 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 often 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 requires 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 estimated at approximately US$0.79 billion, with projections of reaching $1.1 billion by 2030.^[6]

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.

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.

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]

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.

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 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.

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.

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 the 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.

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 "Some have argued that data hygiene services do not reliably identify 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]

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.

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.

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.

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 are climbing.

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 (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 indicates that the address is functional 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]

• Bounce message
• Disposable email address
• Email address
• Email authentication
• Email deliverability
• Email marketing
• Email spam
• Greylisting (email)
• MX record
• Simple Mail Transfer Protocol

Category:Email Category:Data quality