Email verification checks whether an address can receive mail without sending a message. A verifier confirms the syntax, checks that the domain has mail servers, asks the mail server whether the mailbox exists, and flags domains that accept every address. The result is a status (valid, invalid, catch-all or unknown) that tells you whether it's safe to send.

This guide explains each check, what the statuses from common verifiers actually mean, how to treat catch-all and unknown results, and where verification fits in an enrichment workflow. If you're choosing a tool rather than learning the mechanics, start with the best email validation tools instead.

Why does email verification matter for deliverability?

Every message sent to an address that doesn't exist comes back as a hard bounce, and mailbox providers read a high bounce rate as a sign of a poorly maintained list. Microsoft's documentation for its own marketing platform puts it plainly: in most cases an acceptable bounce rate shouldn't be higher than 2% (Microsoft Learn, updated August 2026).

Bounces aren't the only number mailbox providers watch. Google's email sender guidelines (checked September 2026) ask all senders to keep the spam rate reported in Postmaster Tools below 0.30%, and recommend staying below 0.10%. Verification doesn't lower complaint rates directly, but it removes the dead and risky addresses that drag down list quality overall. For the GTM side of the problem, see how bad B2B data turns into bounces.

What checks does an email verifier run?

1. Syntax check

Is the address formatted correctly? jane@acme.com passes; jane@@acme.com or jane@acme fails. This catches typos and broken imports instantly and costs nothing, but a perfectly formatted address can still be fake.

2. Domain and MX record check

The verifier looks up the domain's MX (mail exchanger) records in DNS. No MX records usually means the domain can't receive email at all: it expired, it's parked, or it was never set up for mail. This check can't tell you whether a specific mailbox exists on a domain that does receive mail.

3. SMTP mailbox check

This is the core of verification. The verifier connects to the domain's mail server and starts an SMTP conversation as if it were going to deliver a message, then stops before sending anything. The key step is the RCPT TO command naming the recipient. The server's reply code, defined in RFC 5321, tells the verifier what happened:

• 250: requested action okay. The server will accept mail for that address.

• 550: requested action not taken, mailbox unavailable. Typically the address doesn't exist.

• 450 and other 4xx codes: a temporary failure, such as greylisting or a busy server. The verifier may retry, or return unknown.

This check catches deleted mailboxes, former employees whose accounts were closed and guessed addresses that don't exist.

4. Catch-all detection

Some mail servers are configured to accept mail for any address at the domain, whether the mailbox exists or not. On those domains the SMTP check returns 250 for jane@acme.com and for random-string@acme.com alike, so the verifier can't confirm the mailbox. Verifiers detect this by testing an address that can't exist; if it's accepted, the domain is catch-all.

5. Risk signals

Beyond "does it exist", good verifiers flag addresses you shouldn't mail even if they're technically deliverable: disposable addresses, role accounts like info@ or sales@, full mailboxes, known spam traps, and addresses associated with people who report mail as spam.

What do email verification statuses mean?

Verifiers name their statuses differently. Here's how two common ones map, based on ZeroBounce's status code documentation and Bouncer's terminology page (both checked September 2026):

ZeroBounce's do_not_mail status covers role-based, disposable, toxic and possible trap addresses, with a sub-status telling you which. Bouncer returns a status plus a reason code, domain and account flags, and a score. Whichever verifier you use, map its statuses to these actions once and apply the same rule every time.

How should you handle catch-all and unknown results?

Catch-all addresses aren't bad addresses, they're unconfirmed ones. Deleting them all throws away real decision-makers at companies whose servers happen to be configured that way. A more useful approach:

• Keep catch-all contacts in their own segment and send to them in smaller batches, watching bounces closely.

• Prefer catch-all addresses that came from a provider's database match over ones built from a naming pattern.

• Pause the segment if bounces climb, rather than letting it drag down your main campaign.

The cost of deleting catch-all emails goes deeper on this trade-off.

Unknown usually means the server didn't answer in time, blocked the check or greylisted it. Re-run verification later, or send the unknowns to a second verifier. A practical pattern in a Databar table is a run condition on a second verification column that only fires when the first verifier returned unknown or risky, so you only pay for a second opinion on the ambiguous rows.

When should you verify email addresses?

• At the moment you find them. Verify inside the enrichment step so unverified addresses never reach your CRM or sequencer.

• Before every campaign. An address that was valid when you found it can bounce months later after the person leaves. How to verify and clean email lists before every campaign is the step-by-step version.

• When records enter the CRM. Form fills, event lists and imported spreadsheets are where typos and fake addresses come from. Email validation for CRM covers verifying on import.

• After every send. Process hard bounces immediately and never mail those addresses again, whatever a verifier said earlier.

How do you verify emails in Databar?

There are two ways, depending on whether you already have the addresses.

Verify a list you already have. Add a verification enrichment to the email column of a table. The catalog in September 2026 lists ZeroBounce, Bouncer, Emailable and Reoon at 1 credit per email, and Prospeo's verifier at 2 credits. There's also a domain check from Bouncer that returns DNS records and accept-all status for a domain.

Verify while finding. The Email by name and Email by link waterfalls have a Verify email toggle with Emailable, Bouncer or ZeroBounce. Each time a provider returns an address, the verifier checks it before the waterfall accepts it. If it fails, the waterfall moves to the next provider. One billing detail to plan for: when an address fails verification you're still charged for that provider's result (it did return data) plus the verification, so verification can raise cost per row even as it lowers bounces. See how waterfall enrichment works and the waterfall enrichment page for the setup.

Before a campaign, the BDR data quality checklist covers the other fields worth checking alongside email status.

Frequently asked questions

Does email verification send an email to the address?

No. SMTP verification opens a connection to the mail server and issues the commands that precede delivery, including RCPT TO, then disconnects before any message is sent. The recipient never sees anything.

What's the difference between email verification and email validation?

The terms are used interchangeably by most tools. When a distinction is made, validation sometimes means format and domain checks only, while verification includes the SMTP mailbox check. Check which checks a tool actually runs rather than relying on the name.

Can any tool verify catch-all emails with certainty?

Not through a standard SMTP check, because the server accepts every address. Some vendors offer their own catch-all scoring using other signals. Treat those as risk estimates and still send catch-all segments cautiously.

How often should I re-verify my list?

Before each campaign for cold outbound, and on a regular schedule for lists you mail continuously. The older the data and the more job changes in your audience, the more addresses will have gone bad since the last check.

What bounce rate should I aim for?

As low as you can get it. Microsoft's guidance treats 2% as the upper limit of acceptable in most cases. If a campaign starts bouncing well above that, pause it and re-verify the remaining recipients before continuing.

Verify your next list before you send it

Upload a list to a Databar table, add a verification column, and sort the results by status before your next campaign goes out. Or find and verify in one step with an email waterfall. Start free with a 14-day trial that includes 100 credits, or book a founder demo.