Email Verification Accuracy: Why “Valid” Can Still Bounce

Email verification accuracy matters because the cost of a false “valid” result is not theoretical: it becomes a bounce, a damaged sending reputation, and a sales team acting on bad data. A recent founder post on r/SaaS exposes a particularly instructive failure mode—an email verifier that marked invented mailboxes as valid because it was checking the domain’s ability to receive mail, not whether the specific mailbox existed.

The lesson is bigger than one prospecting tool. Email verification is often presented as a simple binary decision, but modern mail infrastructure makes that promise difficult to keep. The useful question is not “Is this address valid?” It is: what evidence supports this result, what did the server actually reveal, and what uncertainty remains?

The SaaS bug that turned fake inboxes into “valid” leads

The original r/SaaS post came from a founder who discovered the issue after a customer exported roughly 30 addresses from the product and mailed them. Three messages bounced. One Outlook rejection explicitly indicated that the target mailbox did not exist. The founder’s subsequent audit found that the production verifier never attempted a recipient-level SMTP check against the actual address being returned as valid. (reddit.com)

Instead, the tool performed a separate SMTP probe using a random recipient to infer whether a domain was catch-all. If a domain had mail-routing records and did not appear catch-all, addresses on that domain were effectively promoted to “valid” with a confidence score—even nonsense local parts such as an invented first name. In other words, the system had confused domain deliverability with mailbox existence. (reddit.com)

That distinction is the foundation of email verification accuracy:

• A domain can exist while a specific mailbox does not.
• A domain can accept every recipient during SMTP while routing or rejecting later.
• A server can refuse to reveal mailbox existence, even when the inbox is real.
• A verifier can fail its own probe before it reaches the relevant stage of the SMTP conversation.

The founder also found a second issue: the verifier announced nonexistent sender domains in its MAIL FROM command. Some receiving servers rejected that sender identity first, causing the probe to fail. The software then interpreted the failed probe as evidence that the domain was not catch-all—an error that increased, rather than reduced, confidence in the target address. (reddit.com)

That is a classic observability problem. A technical failure was not merely hidden; it was converted into a positive signal.

What email verification actually verifies

“Email verification” is an umbrella term for several checks with very different evidentiary value. A responsible tool should disclose which checks it ran and avoid implying that every result carries the same certainty.

1. Syntax validation

The first layer checks whether an address is structurally plausible: a local part, an @ sign, and a domain formatted according to expected rules. This removes obvious input errors such as missing domains, spaces, malformed punctuation, or accidental commas.

Syntax validation is useful, but it says almost nothing about deliverability. person@company.com may be perfectly formatted even if neither the person nor the mailbox exists.

2. Domain and DNS checks

A verifier can inspect whether the domain resolves and whether it publishes mail-routing information. SMTP delivery normally uses DNS to locate a receiving mail server, starting with MX records and, in some circumstances, falling back to A or AAAA records. RFC 7505 also defines a “null MX” record, which explicitly signals that a domain does not accept email. (rfc-editor.org)

These checks answer a narrower question: does this domain appear configured to receive mail? They do not prove that jari@company.com, hello@company.com, or firstname.lastname@company.com is a real mailbox.

3. Disposable, role, and policy checks

Many verification systems flag temporary email providers, generic role accounts such as info@, support@, or admin@, and known risky patterns. Those labels can help a marketer segment a list or prevent low-quality signups.

But these are policy classifications—not existence proofs. A role address can be a highly legitimate support destination. A consumer address can be real but inappropriate for B2B outreach. Keeping the concepts separate prevents a “risk score” from being mistaken for deliverability evidence.

4. SMTP recipient probing

The strongest pre-send signal, when a receiving server permits it, comes from opening an SMTP session and asking whether the server will accept a specific recipient. SMTP defines the MAIL FROM command for the envelope sender and the RCPT TO command for an individual recipient. A server’s response to the recipient stage can provide useful evidence about whether a mailbox is accepted for delivery. (rfc-editor.org)

However, “useful evidence” is not the same as universal truth. Some servers accept all recipients, some deliberately obscure mailbox existence to reduce directory harvesting, and some block or rate-limit probes. That is why a recipient-level SMTP response should be treated as one measured outcome—not magic.

Why an MX record is not proof of a mailbox

The failure described in the Reddit post is easy to reproduce conceptually. Imagine a company owns exampleco.com and routes its email through Microsoft 365 or Google Workspace. The domain has working MX records, so mail can reach its provider. But that tells you nothing about whether these addresses exist:

1. alex@exampleco.com
2. alex.rivera@exampleco.com
3. jari@exampleco.com
4. this-is-clearly-made-up@exampleco.com

A verifier that sees a mail-capable domain and concludes that every syntactically plausible address is valid is generating a domain-level inference, not verifying a recipient.

This distinction is especially important for outbound prospecting because lead databases frequently use pattern generation. They may infer first@domain.com or first.last@domain.com from a person’s name, historical data, or a company-wide convention. Pattern inference can be valuable for research, but it should be labeled honestly as a guess until corroborated.

The Reddit author said all three bounced addresses had been generated from common naming patterns, despite the names not appearing on the companies’ sites. After revising the product, the export reportedly separated guessed addresses from verified ones and removed known-dead records from the sendable column. (reddit.com)

That is a far better product model. It preserves potentially useful research leads without allowing a weak inference to masquerade as a confirmed route to an inbox.

The SMTP control test: a better way to interpret a probe

The founder’s fix is notable because it adds a control. Rather than sending a random probe and treating its failure as a catch-all verdict, the revised process reportedly uses a sender domain that exists, tests a deliberately invalid control recipient first, and then tests the target recipient on the same SMTP connection. (reddit.com)

The logic is straightforward:

Why same-session testing matters

Using the same connection reduces the chance that the two outcomes are distorted by unrelated changes such as a transient network issue, a different front-end server, connection throttling, or inconsistent anti-abuse behavior. It does not remove every ambiguity, but it produces a more meaningful comparison than evaluating a random address in one context and the target in another.

A result should still record the raw class of response. SMTP uses reply codes to communicate outcomes, and a successful recipient response is materially different from an access denial, a temporary failure, or a policy block. Treating every non-success reply as “invalid” discards crucial information. RFC 5321 defines the SMTP command flow and reply framework that makes these distinctions possible. (rfc-editor.org)

Why the envelope sender must be real

The MAIL FROM stage comes before recipient acceptance. If the sender identity is invalid, rejected, or suspicious, a receiving server may refuse the transaction before the verifier learns anything about the target mailbox.

That makes a valid and properly configured probe sender operationally important. It should be a domain the verifier controls, capable of receiving bounces, and configured consistently with its sending infrastructure. Modern mailbox providers place substantial weight on sender authentication: Google’s guidance for bulk senders requires SPF and DKIM, with alignment requirements, and recommends monitoring compliance through Postmaster Tools. (support.google.com)

A probe identity does not need to look like a marketing campaign, but it cannot be a fictional domain and still be expected to deliver reliable diagnostic signals.

Why “unverified” is often the most accurate answer

The most valuable part of the story is not the revised probe. It is the founder’s conclusion that the honest output for many domains is unverified, not a fabricated confidence number.

In the founder’s small, non-independent test of 40 real domains, 55% reportedly differentiated real and fake mailboxes, 28% behaved as catch-all domains, and 18% refused the probe or blocked the relevant port. Those figures should not be generalized as an industry benchmark—the sample is small and comes from the product’s own testing—but they illustrate why certainty is scarce in real-world verification. (reddit.com)

A strong verification taxonomy might look like this:

• Verified deliverable: The server accepted the target while rejecting an invalid control recipient under comparable conditions.
• Undeliverable: The target received a clear, recipient-specific permanent rejection after the system passed prerequisite checks.
• Catch-all / accept-all: The server accepts the control recipient, so mailbox-level existence cannot be distinguished.
• Blocked or access denied: The receiving environment refuses the probe or withholds recipient information.
• Temporarily unknown: A timeout, transient SMTP response, DNS issue, rate limit, or temporary network failure prevented a conclusion.
• Guessed: The address was generated from a name-and-domain pattern or data enrichment, but has no direct verification evidence.
• Risky: The address may be disposable, role-based, malformed, or otherwise unsuitable for a given workflow—but is not necessarily nonexistent.

This classification solves an incentive problem. Many products feel pressure to return a clean yes/no answer because dashboards, exports, and sales workflows prefer simplicity. But forcing uncertain data into “valid” creates false precision. A decimal confidence score cannot compensate for a test that never inspected the mailbox.

For most senders, six addresses with credible recipient-level evidence are more valuable than 30 records labeled 0.90 valid on the strength of an MX lookup.

Catch-all domains are not verified addresses

A catch-all domain accepts email addressed to virtually any local part. It may route unknown recipients to a central inbox, archive them, reject them later, or silently discard them. From the perspective of a pre-send SMTP probe, the critical point is that both a real recipient and a made-up one can receive the same acceptance response.

That means a catch-all outcome is not bad data; it is non-discriminating data. The verifier has learned something useful about the domain but cannot prove the specific person’s inbox exists.

How teams should use catch-all results

Do not put catch-all addresses into the same send queue as recipient-verified contacts. Instead:

• Keep them in a separate segment with a lower sending priority.
• Require corroboration, such as a public bio, a recent press mention, a contact form, a verified LinkedIn identity, or a reply from another channel.
• Send only highly relevant, low-volume, personalized outreach if you choose to contact them.
• Monitor bounces, complaints, and engagement at the segment level.
• Never let a catch-all label become an excuse to treat generated address patterns as confirmed.

This is a practical instance of data provenance. Two records may look identical in a CRM—same name, company, and email format—but one was observed as recipient-accepted while the other is an inferred pattern on an accept-all domain. Your workflow should retain that difference.

Microsoft 365, Gmail, and the limits of mailbox probing

The Reddit post specifically mentions Microsoft 365 returning an access-denied-style response that was subsequently given its own status instead of being marked invalid. That is a sensible design choice because a server that refuses all recipient probes has not disproven a mailbox; it has declined to provide evidence. (reddit.com)

Microsoft’s own email-security documentation emphasizes the role of SPF, DKIM, DMARC, and composite authentication in how Exchange Online and Microsoft 365 evaluate messages. Those controls are aimed at securing mail flows, not making recipient enumeration convenient for external verifiers. (learn.microsoft.com)

Google likewise continues to formalize sender expectations for mail reaching personal Gmail accounts, particularly for bulk senders. Its requirements make sender identity and authentication increasingly central to deliverability. (support.google.com)

The second-order implication is important: the more aggressively providers defend users from spam, spoofing, and directory harvesting, the less likely it becomes that an external service can reliably determine mailbox existence everywhere. That is not a defect in email verification. It is an expected consequence of safer infrastructure.

Product teams should plan for this reality rather than promise universal verification. If a service claims it can definitively validate every mailbox at every major provider without sending a message, buyers should ask how it handles blocked probes, accept-all domains, recipient privacy protections, and sender-authentication failures.

A practical email verification accuracy checklist for builders

If you build, buy, or integrate an email verifier, use this checklist before trusting its “valid” column.

Questions to ask a verification vendor

1. Does “valid” require a target-specific check, or can it be assigned from DNS and domain-level signals alone?
2. How are catch-all domains detected, and are they separated from mailbox-verified records?
3. Does the product test a known-invalid control recipient before calling a target recipient verified?
4. What sender domain does the probe use, and is it a real, authenticated domain?
5. How are blocks, timeouts, rate limits, and access-denied responses represented?
6. Can I export the evidence type and raw outcome, rather than only a confidence score?
7. Are pattern-generated addresses clearly labeled as guesses?
8. What happens when a domain publishes a null MX record or otherwise does not accept mail?
9. How does the system avoid reclassifying technical errors as positive results?
10. Can I suppress previously hard-bounced addresses automatically?

The answers should affect procurement decisions. A cheap verifier that inflates “valid” rates may create bigger downstream costs in sender reputation, wasted sequencing capacity, and misleading sales reporting.

A safer implementation workflow

For a product team adding verification to a signup form, import process, or prospecting workflow, use a layered design:

1. Perform syntax and normalization checks immediately.
2. Inspect domain, MX, and null-MX signals.
3. Flag disposable or policy-sensitive addresses separately from deliverability status.
4. Attempt target-level SMTP verification only where technically and ethically appropriate.
5. Use a control recipient to distinguish recipient acceptance from accept-all behavior.
6. Store the result as evidence with a timestamp, not an eternal fact.
7. Preserve “unknown,” “blocked,” and “catch-all” states.
8. Feed hard bounces and user feedback back into suppression logic.
9. Re-check stale data before major sends, since mailboxes and company domains change.

If you need a lightweight first-pass check before adding an address to an app workflow, use an email address verification tool for syntax and domain screening—but avoid treating any single automated result as a guarantee that a person will receive, read, or welcome a message.

Confidence scores need an evidence model

Confidence scores are not inherently bad. They can be useful when they summarize a transparent model. The problem starts when a score conceals weak or missing evidence.

For example, a score of 0.90 could mean several radically different things:

• The target mailbox accepted RCPT TO, while a known-invalid control was rejected.
• The domain has working MX records and the email fits a common corporate pattern.
• The address appeared in an old database but has not been checked recently.
• The verifier could not connect but assumes the domain is probably fine.

Those are not equivalent. A well-designed score should be accompanied by categorical evidence: smtp_target_accepted, control_rejected, catch_all_detected, server_blocked, mx_only, pattern_inferred, or historical_source.

This makes verification useful for automation. A CRM can route verified addresses to one sequence, catch-all addresses to a manual-review queue, guesses to enrichment, and hard failures to suppression. Without that evidence, teams end up making risky decisions based on a number they cannot audit.

Measure precision, not just pass rate

Verification vendors often market a high “valid rate,” but that metric can be gamed by calling uncertain records valid. Better operational metrics include:

• Post-send hard-bounce rate by verification status
• Precision of the verified segment: among records labeled verified, how many avoid hard bounces?
• False-positive rate: how often are “valid” records later proven undeliverable?
• Coverage: what proportion of records receive a true recipient-level result versus an unknown state?
• Catch-all and blocked share
• Age of verification evidence

The goal is not maximum validation coverage. It is better decisions under uncertainty.

What the community reaction does—and does not—tell us

The supplied discussion snapshot contained no top comments, so there is no meaningful community consensus to report from the thread itself. That absence matters: this is primarily a firsthand postmortem from a product owner, not an independently reviewed benchmark or a broad industry study.

Still, the account is valuable because the technical diagnosis is specific. It identifies the flawed assumption, traces it to a missing recipient-level check and invalid envelope sender domains, describes a revised testing method, and acknowledges that a large share of domains may remain unconfirmable. That is more useful than a generic claim of “99% accuracy.” (reddit.com)

Builders should read it as a product-design case study, not proof that every email verifier makes the same mistake. The broader takeaway is to demand verifiable semantics: if a tool says “valid,” users need to know whether that means the mailbox was tested, the domain exists, a pattern looked plausible, or the system simply did not encounter an obvious failure.

The larger deliverability lesson: uncertainty should change behavior

Email verification accuracy is often framed as a data-cleaning problem. It is also a sending-strategy problem.

When uncertainty is surfaced correctly, teams can adapt. They can lower volume, personalize more deeply, prioritize addresses with strong evidence, verify identity through another channel, or decide that the potential value of the contact does not justify the deliverability risk. When uncertainty is hidden, teams blast a larger list and discover the truth through bounces.

This distinction is increasingly relevant as mailbox providers enforce stricter authentication and anti-abuse expectations. Google’s guidance makes clear that high-volume senders should authenticate mail with SPF and DKIM and meet sender-alignment requirements; DMARC gives domain owners a way to instruct receivers how to handle authentication failures. (support.google.com)

Verification does not replace sender authentication, consent, relevance, or good list management. It is one input into a broader deliverability system. A technically accepted mailbox can still be the wrong person, an abandoned inbox, an unmonitored alias, or a recipient likely to report unwanted outreach.

The mature approach is therefore conservative: verify what can be verified, label what cannot, distinguish guessed contacts from observed evidence, and keep bad addresses out of the sending path.

Conclusion: the best verifier knows when not to claim certainty

The r/SaaS post is a useful warning against a deceptively common shortcut: treating a mail-enabled domain as proof that every address on it exists. The founder’s revised method—using a real sender identity, a control recipient, target-level checks, and explicit blocked/catch-all states—points toward a more defensible standard. (reddit.com)

For founders, marketers, and developers, the practical rule is simple: do not optimize for the largest possible “valid” count. Optimize for a result taxonomy that matches the evidence. A smaller send list made of genuinely verified recipients, well-labeled unknowns, and carefully handled guesses will generally outperform a larger list built on inflated confidence.

FAQ

What does email verification accuracy mean?

Email verification accuracy is how reliably a verification result reflects real-world deliverability. High accuracy requires distinguishing domain-level signals, mailbox-level acceptance, catch-all behavior, policy blocks, and unverified guesses rather than collapsing them into one “valid” label.

Can an email address be valid if it later bounces?

Yes. An address can be syntactically correct and use a mail-enabled domain while the specific mailbox does not exist. It can also change after verification, be disabled, or be affected by provider policy and temporary delivery issues.

Is an MX record enough to verify an email address?

No. MX records indicate where a domain receives email; they do not establish that a particular local part or mailbox exists. A domain-level pass should never be represented as recipient-level verification. (rfc-editor.org)

What is a catch-all email domain?

A catch-all domain accepts messages sent to many or all local parts, including nonexistent ones. Because a fake control address may be accepted alongside a real one, mailbox-level existence cannot be confidently determined from the SMTP acceptance response alone.

Should blocked SMTP checks be marked invalid?

No. A blocked, access-denied, rate-limited, or otherwise inconclusive SMTP check means the verifier lacks enough evidence. The more honest status is unverified, blocked, or unknown—not invalid and not valid.