Verifying an address sends no message: the SMTP session stops before the DATA command, the one that transmits the content (RFC 5321, section 4.1.1.4). This little-known mechanic explains most of the myths about email verification, whether they credit it with too many powers or accuse it of intrusions it never commits.
Its best-established effect is on the hard bounce: it removes nonexistent addresses before you send. It does not touch spam complaints or engagement. Each of the 9 myths below is settled by a published threshold or by how the SMTP protocol works.
Verification vs. validation: the scope in a few lines
Validation checks the form of an address: an “@”, a domain, a syntax that complies with RFC 5322. Verification then queries the domain through its MX record, then the mail server itself, and flags disposable addresses. The steps are detailed in the article on the difference between validation and verification.
9 email verification myths, put to the test
Is a verified address a risk-free address?
No. A verifier sorts addresses into categories (valid, invalid, catch-all, risky) because a “valid” does not cover every case. Disposable addresses are one example: the mailbox exists and responds on test day, then gets abandoned. Services spot them using lists of disposable domains, compared in the article on disposable email addresses. The spam trap is the sneakiest case: run by a mailbox provider or an anti-spam organization, it accepts mail, so the SMTP test sees an ordinary mailbox. The Amazon SES documentation states that these traps can be former valid addresses, abandoned after a long period of bounces.
Can you verify a mailbox without sending it an email?
Yes. An SMTP transaction has 3 commands: MAIL FROM announces the sender, RCPT TO names the recipient, DATA transmits the content of the message (RFC 5321, section 3.3). The server answers RCPT TO before DATA exists; a verifier stops there and closes the connection. Code 250 means “accepted”, 550 “unknown mailbox”, and a 4xx code a temporary refusal to retry.
The MX record tells you where to ask. Section 5.1 of RFC 5321 provides that a domain with no MX is treated as if it had an implicit MX pointing to its own host. A missing MX therefore remains a signal to cross-check against the rest. This mechanism has a known flaw, covered below: some domains answer 250 to everything.
Is verification invasive?
The content stays out of reach: no message is transmitted or read, since the session stops before DATA. The GDPR question remains: a named address is still personal data. The CNIL sets the rules at the moment of prospecting. It requires prior consent in B2C and a right to object in B2B. It recommends collecting them through a box unchecked by default (a pre-ticked box is prohibited). Each message must identify the sending organization and offer a simple way to refuse (CNIL page on prospecting by email, in French, updated June 10, 2026).
Does a catch-all prove the address exists?
No. A catch-all domain accepts mail sent to any name before the at sign: jean.dupont@ and azertyuiop@ get the same 250 to the RCPT TO command.
No method settles it with certainty: what happens to the message, filed in a real mailbox or discarded, depends on how the domain is configured. Reputable services file these addresses as risky (“accept-all” at some), which expresses a genuine uncertainty. A test batch sent to this segment, with the hard bounce read before scaling up, beats sorting blindly.
Is a free tool or a simple syntax check enough?
No. “gmial.com” follows every syntax rule. The next check, the MX record, eliminates nonexistent domains but lets through a real domain where the mailbox does not exist. Only the SMTP conversation queries the address itself. A free tool is therefore judged on the depth of its check: syntax and domain on one side, SMTP with catch-all detection on the other. Validation alone says nothing about the state of the inbox.
Are verified addresses always active?
No. “Valid” means accepted by the server at the time of the test. A mailbox can sit unread for months. It can also fill up and return soft bounces. Amazon SES even recommends ceasing to send to recipients who neither open nor click: an inactive contact does not bounce, it weighs on engagement.
Is one verification a year enough?
No universal figure sets the rhythm. It depends on how fast the list turns over and on what a bounce costs you (thresholds below). For contacts you have not written to in a long time, SES advises including only a small share of them in each send. The page on how often to verify an email list details the rhythm. A double opt-in and verification at sign-up cut off the source of typos at entry; cleaning the existing list completes these two safeguards.
Does verification guarantee deliverability?
No, it acts on a single line of the ledger. For spam complaints, Gmail has set the rule since February 1, 2024 for all senders:
“Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher.”
This guidance appears in Google’s sender guidelines, which require SPF or DKIM from all senders and add DMARC beyond 5,000 messages a day to Gmail. A perfectly valid recipient who clicks “report spam” weighs on sender reputation, and no verification can prevent it; the definition of spam and the deliverability errors cover this other half of the file.
On the bounce side, the same Amazon SES page gives a readable scale: under 2% hard bounces for good results, account review at 5% and possible suspension at 10%. Temporary bounces, such as a full mailbox, are not counted.
Are all verification services equal?
No. Services differ on how they treat catch-all addresses, on how fresh their disposable-domain lists are and on how fine-grained their statuses are. A service that returns only “valid” or “invalid” hides the most uncertain category, the catch-all. The most telling test takes a few minutes: submit a few hundred addresses whose fate you already know, then compare the statuses returned. The sample mixes active internal mailboxes, invented addresses on real domains and one identified catch-all domain.
What a verified list leaves out
The test measures neither the content of the message nor the recipients’ consent. It also says nothing about whether anyone wants to read. A sample drawn from your oldest segment and run through Captain Verify before the next campaign gives you the share of invalid addresses in that list, to compare with the 2% bounce threshold from Amazon SES.
