Email validation vs email verification: what each one does to your users

What is email validation?#

Validation is a set of checks on the address and its domain, with no message sent and no connection to the mailbox. Typical checks:

• Syntax: is the string a well-formed address.
• Domain: does the domain exist in DNS.
• MX: does it publish mail-exchanger records (or an explicit null MX saying it accepts no mail).
• Disposable: is the domain on a list of throwaway providers.
• Heuristics: typo of a major provider, role accounts such as info@, very young domains.

These catch bob@gmial.com, bob@no-such-domain.example, and bob@mailinator.com. For how disposable-domain detection works in more depth, see how disposable services hide and disposable email detection APIs compared; for the MX and domain-age signals, see which mail servers disposable domains use and how old disposable domains are. They run in milliseconds to a few hundred milliseconds, and the address owner never sees anything. You can try this class of check with the email checker, the MX lookup and the disposable email checker.

What is email verification (SMTP mailbox probing)?#

Verification here means connecting to the recipient’s mail server and issuing RCPT TO:<address>, then disconnecting before any message body is sent. RFC 5321 describes the expected reply: if the recipient “is known not to be a deliverable address, the SMTP server returns a 550 reply” [1]. A 250 means accepted. The probe stops before DATA, so no message is delivered.

Why do results come back “unknown” or “accept-all”?

• Catch-all domains. A server can accept every recipient and sort mail later. A 250 then says nothing about the mailbox. Vendors label these “accept-all” or “catch-all”.
• Deferred decisions. RFC 5321 notes that when address validity is “deferred until after the DATA command is received, RCPT may return no information at all” [1].
• Greylisting. A server answers a first-time sender with a temporary failure (4yz) and expects a retry. RFC 6647 documents the practice [2]. A prober that does not retry gets no answer.
• Hidden behaviour per provider. Replies differ by provider and configuration. Microsoft documents that Exchange Online with Directory-Based Edge Blocking rejects unknown recipients at the edge with 550 5.4.1 [4], but that depends on the domain’s setup. A 250 from a hybrid or relay setup is not proof of existence.

Why do large providers limit it?

Probing lets a third party enumerate which mailboxes exist on a provider, which is the same mechanism used to harvest addresses. What the primary sources support:

• Microsoft defines namespace mining as “the practice of verifying email addresses without sending (or attempting to send) emails to those addresses”, and SC-002 as “The mail server IP connecting to Outlook.com has exhibited namespace mining behavior” [3].
• WEB.DE states that sending many messages to unknown or deactivated addresses can lead to temporary suspension of the sending system, and to permanent suspension in severe cases [7].
• Google documents the 550 5.1.1 reply but not the stage, so whether Gmail answers at RCPT TO is not established by Google’s own page [5]. Practitioner reports exist but are not primary sources.
• Proton documents 550 5.1.1 for a nonexistent account, also without the stage [6].
• RFC 5321 section 7.3 observes that disabling VRFY gives little security because “RCPT commands can be used to obtain the same information about address validity” [1]. The standard itself acknowledges the leak.

We found no Google or Yahoo page that names probing as a prohibited practice, so this article makes no claim that they ban it.

Does verification ever send an email?

Some vendor features do. ZeroBounce’s Verify+ documentation says: “During validation, we send an email to check for bounces and validate the address based on the response” [8]. It describes Verify+ as an optional, free add-on that “primarily impacts disabled Yahoo, AOL, Verizon and Catch-all email addresses” and is available for API imports and single-email validation [8]. ZeroBounce’s 2024 launch release says only that Verify+ “uses proprietary methods” and gives no mechanism [9].

On 23 June 2026 a blogger reported receiving unsolicited messages after entering an address in a third-party company’s signup form [11]. In the Hacker News discussion [10], the company’s founder said they use ZeroBounce and Customer.io for email validation. On 25 June the founder wrote: “this is actually ZeroBounce’s Verify+ feature which we figured out after some escalation. It’s now disabled!” [10]. A commenter had earlier linked the behaviour to ZeroBounce’s documented step of rechecking unknown emails from different locations; that was the commenter’s inference. We did not find a ZeroBounce statement on the incident, and this article does not characterise it further.

The practical point is narrow: a verification feature can send real mail to the address you submit to the vendor, so check the vendor’s documentation for which options are enabled on your account.

What is a confirmation email?#

A confirmation email sends a one-time code or link to the address and waits for the user to use it. It is the only method in this article that shows the person controls a working mailbox at that moment. It cannot be faked by a server’s configuration, because the user has to receive and act on the message.

Its costs are different in kind: one extra step for the user, a message you pay to send, and a bounce if the address is bad. Validation before the send reduces avoidable bounces from typos and dead domains.

How do the methods compare?#

What does StormDoor’s emails gate do, and what does it miss?#

The emails gate validates. It checks syntax, role accounts, MX, disposable domains (including shared mail infrastructure), typo domains, and domain age, and returns findings rather than a score. Its own documentation states: “None of these check that the specific mailbox exists — only that the domain can plausibly receive mail” (emails gate docs).

This is a design choice with tradeoffs.

What it buys. No message or probe ever reaches the recipient’s mail server, so there is no mailbox-operator abuse exposure, no probe-IP reputation to manage, and no extra third party touching the address. Results are deterministic for a given input and reference-data version.

What it misses.

• bob@gmail.com and qzx83jd@gmail.com look identical to it. A valid domain with a nonexistent mailbox passes.
• A typo that lands on another real domain (bob@gmai.co if that domain has MX records) is caught only if the typo-similarity check or domain age flags it.
• It does not detect abandoned or disabled accounts.
• It cannot say anything about catch-all behaviour, because it never asks.

If you need mailbox-level answers, the options are an SMTP verification vendor (accepting “unknown” results and the privacy notes in the table) or a confirmation email. For most signup forms the second is the better fit, since it proves ownership, and validation in front of it removes the cheap failures before you send.

Which should you use?#

1. Validate on submit to reject malformed, non-existent and throwaway addresses early.
2. Send a confirmation email for any account that matters.
3. Add SMTP verification only for list hygiene on addresses you will email in bulk, and read the vendor’s documentation to learn whether it sends mail.