Email verification before send: tools, accuracy, and process

What does email verification actually check?

The term "email verification" covers three distinct technical checks that run in sequence. Each layer builds on the last, and each removes a different category of address that would otherwise either hard-bounce or never reach an inbox. Understanding what each layer does matters because the results inform your send strategy, not just your suppression list.

Layer 1: syntax validation

Syntax validation tests whether the address string conforms to the rules set out in RFC 5322. That means checking for a single @ symbol, a valid local-part (the bit before @), a valid domain segment, and no illegal characters. This layer catches typos like firstname.lastnamegmail.com (missing @) or name@@company.co.uk (doubled @), as well as encoding artefacts that sometimes appear when address data is exported from a CRM or spreadsheet.

Syntax checks are deterministic and instant. They do not require network connectivity. Any address that fails at this layer would hard-bounce with a 550 error if you tried to send to it, and there is no scenario in which keeping it in your file adds value.

Layer 2: domain validation (MX record lookup)

Once an address passes syntax, the verification tool queries the Domain Name System (DNS) to confirm the domain has live MX records pointing to a mail server. A domain with no MX record cannot receive email, full stop. This catches addresses at defunct companies, domains that were set up as web-only and never configured for email, and cases where a company has rebranded or been acquired and the old domain has expired.

For B2B lists, this layer is where domain-level decay shows up most clearly. B2B email data decays at roughly 25%-30% per year across a typical file, and a meaningful portion of that decay is companies closing, merging, or migrating to new domains. MX lookup catches the domain failures cleanly, with no false positives.

Layer 3: mailbox-level validation (SMTP handshake)

The third layer connects to the recipient mail server and simulates the opening of a delivery conversation without actually sending a message. The tool issues an SMTP RCPT TO command for the target address and reads the server's response code. A 250 response indicates the mailbox exists. A 550 response indicates it does not. The connection is then closed before any message content is transmitted.

This is the most informative layer, but also the most nuanced. Some mail servers are configured to block or rate-limit verification probes. A small number return generic positive responses for all addresses regardless of whether they exist. These are called catch-all domains, and they deserve their own section.

What is a catch-all domain, and how should you handle it?

A catch-all (or "accept-all") configuration means the mail server returns a 250 OK response for every address at that domain, whether or not the individual mailbox exists. The domain owner may have done this deliberately (to catch misaddressed mail), or it may be a default posture in their email gateway software. From a verification standpoint, the result is the same: you cannot confirm whether [email protected] is a real, active mailbox or a non-existent address the server is silently accepting.

A good verification tool flags these addresses as "catch-all" or "accept-all" rather than reporting them as verified. The appropriate handling depends on context. For a warm house list where you have prior engagement, catch-all addresses are generally worth including. For a cold B2B send to a purchased or compiled list, treating catch-all addresses as higher risk is sensible: exclude them from your initial wave, or send to a test segment first and monitor bounce rates before mailing the full group.

In our experience, catch-all domains account for 15%-25% of a typical UK B2B list. The proportion varies significantly by industry: technology, legal, and financial services firms tend to run stricter mail server configurations with lower catch-all rates, while some smaller professional services firms and SMEs show much higher rates.

Accuracy benchmarks: what verification can and cannot guarantee

Syntax and MX checks are essentially deterministic. If an address fails either layer, it will not deliver. The accuracy concern lies with the SMTP handshake layer, where several factors affect reliability.

For non-catch-all corporate domains (which covers the majority of UK B2B addresses), mailbox-level accuracy sits above 95%. The main source of error is greylisting or SMTP throttling, where the server temporarily defers or blocks the probe without returning a clean pass or fail. Verification tools handle this by retrying deferred probes and reporting a "risky" or "unknown" status when a clean answer cannot be obtained.

For B2C lists, the accuracy picture is shaped differently. Consumer email addresses at major providers like Google, Microsoft, or Yahoo benefit from reliable SMTP responses, so verification accuracy is high for those domains. ISP-specific domains and smaller webmail providers occasionally behave inconsistently.

Verification layer	What it catches	Accuracy	Typical % removed from a B2B list
Syntax validation	Malformed strings, illegal characters, encoding errors	100% (deterministic)	0.5%-2%
Domain/MX validation	Expired domains, no-MX domains, web-only domains	100% (deterministic)	2%-5%
Mailbox/SMTP validation	Non-existent mailboxes at live domains	95%+ for non-catch-all	2%-6%
Catch-all detection	Domains that cannot be verified at mailbox level	Flags unknown, not definitive	15%-25% flagged as unknown

Net of catch-all unknowns, a full B2B verification pass typically removes 5%-12% of records as confirmed undeliverable. B2C runs through similar processing shed 3%-8%. The gap reflects B2B's higher sensitivity to company closures and role-based address churn.

Bulk verification vs real-time API: which model suits your workflow?

Email verification tools are sold in two integration models. The right choice depends on whether you are cleaning existing data or preventing bad data entering your systems in the first place.

Bulk batch verification

Bulk verification takes a CSV or similar file upload, processes all addresses through the three-layer check, and returns a results file with a status against each address. Processing speed varies by vendor and volume: a 50,000-record file typically completes within 20-40 minutes. Pricing for bulk runs sits at £1-£5 per 1,000 addresses, with volume discounts applying above 100,000 records. Some vendors charge a flat monthly subscription instead of per-record pricing; for high-volume users that model can be more economical, but per-record pricing is more practical for one-off or quarterly list hygiene.

Bulk verification is the right choice for pre-send hygiene on a purchased or compiled list, for quarterly hygiene on a house database, or for cleaning a CRM export ahead of a campaign upload.

Real-time API verification

API verification checks each address at the point of entry: a web form submission, a CRM record creation, a manual data import. The check runs within 1-3 seconds and returns a pass, fail, or unknown status that can be used to gate whether the record is accepted, flagged, or rejected.

The benefit of API verification is preventive rather than corrective. It stops bad addresses entering your database before they accumulate, which reduces the scale of bulk hygiene jobs needed later. For businesses with high-volume inbound lead capture (paid search, content downloads, event registrations), API verification at the form level pays back its cost quickly.

API pricing is per call, typically slightly higher per address than bulk rates. Most vendors publish pricing in the range of £2-£8 per 1,000 API calls. Rate limits and uptime SLAs vary significantly between providers, so for mission-critical form capture it is worth checking whether the vendor offers a fallback behaviour (allow-and-flag rather than block) when their service is briefly unavailable.

For teams appending email addresses to existing contact records, see our guide on email append for UK B2B and B2C data, which covers the match process and what to do with newly appended addresses before your first send.

When should you verify your email list?

The answer depends on the list's origin and its last verified state. There is no single frequency that suits all use cases.

Cold or purchased lists: verify immediately before every send. You have no prior engagement signal and no visibility of how recently the data was compiled. Even a list supplied by a reputable data provider will have accumulated some decay between compilation and your send date. Running verification as the last step before the send, rather than at the point of purchase, gives you the most accurate snapshot.

House lists built from opt-ins: verify quarterly. Open and click activity tells you some addresses are deliverable, but inactive addresses accumulate silently. Quarterly hygiene catches the drift before it reaches a level that affects your sender reputation. Any address that has not opened or clicked in twelve months and fails verification should be suppressed.

Dormant lists: treat exactly as cold lists. A house list that has not been mailed in six months or more should go through a full verification pass before reactivation, regardless of how clean it was when last used. Six months is enough time for a material share of B2B addresses to have become invalid through staff turnover and company changes.

Post-event or trade-show data: verify before you send, the same day or the next day. Badge-scan and business card data collected at events is notoriously inconsistent in format and accuracy.

GDPR and the accuracy principle

Under the UK GDPR accuracy principle (Article 5(1)(d)), personal data must be accurate and, where necessary, kept up to date. For email marketing data, this means that holding addresses you know to be undeliverable in a live send file creates both a deliverability problem and a compliance one. The Information Commissioner's Office (ICO) has cited inaccurate data as a contributing factor in enforcement cases involving unsolicited marketing, because it suggests the controller has not maintained adequate data governance.

Practically, this means verification is not just a deliverability hygiene task. It is part of the minimum standard of care for any organisation holding personal data for marketing purposes. Keeping a record showing when you last verified a list, what percentage was removed, and what was suppressed gives you an audit trail that supports accountability under Article 5(2).