Check permission before you check addresses
For unsolicited electronic mail marketing to individual subscribers, the ICO requires consent or compliance with all the conditions of an applicable soft opt-in. Different rules apply to corporate subscribers, but sender identity and a valid opt-out contact address are still required. ICO electronic mail marketing rules A "valid" result from a verification service does not establish any of those conditions.
The products-and-services soft opt-in requires direct collection during a sale or negotiation, marketing of your own similar products or services, and an opt-out opportunity at collection and in every subsequent message. ICO electronic mail marketing rules Current ICO guidance also describes a separate charitable-purposes soft opt-in with its own conditions; do not apply an old one-size-fits-all summary. ICO electronic mail marketing rules
These are compliance signposts, not a legal assessment of your list. If the source or permitted use is unclear, hold the record out of marketing while you establish it. A purchased or scraped address does not become permissioned because a checker recognises it. For the fuller picture of the two UK rules, read how PECR and UK GDPR apply to business email.
Keep technical validity separate from consent, objection and suppression records so a deliverable address is not treated as permission.
Understand what each technical check actually establishes
Syntax. A format check can identify obvious structural problems. It cannot prove that the mailbox exists. Avoid aggressive automatic corrections: replacing a suspected typo can change the intended recipient. Ask the person to confirm corrections through your own collection process.
Domain routing. DNS checks can examine whether mail routing is configured. Missing MX records alone are not conclusive: SMTP defines an implicit fallback when the MX list is empty. RFC 5321: Simple Mail Transfer Protocol A null MX is different: RFC 7505 lets a domain explicitly announce that it accepts no mail. RFC 7505: Null MX Ask a verification supplier how it distinguishes these cases.
Mailbox checking. SMTP does not always disclose whether a user exists. RFC 5321 permits a 252 response meaning the server cannot verify the user but will accept a message and attempt delivery. RFC 5321: Simple Mail Transfer Protocol A checker's "unknown" result must therefore remain uncertainty, not be silently converted into valid or invalid.
Catch-all results. If a receiving setup accepts arbitrary recipient names, acceptance alone cannot establish that the particular named mailbox belongs to a real, monitored recipient. Treat "accept-all" as a separate operational category and ask what evidence the tool actually observed.
Use this email verification workflow
- Establish provenance. Record how and when the address was collected, the requested communication and the supporting consent or soft-opt-in evidence. Keep that evidence independent of verification status.
- Apply suppressions first. Exclude unsubscribes, complaints and known invalid destinations before creating a verification batch. Never use a fresh "valid" result to reactivate someone who opted out.
- Minimise the data shared. Before uploading a list, review the supplier's purpose, retention, security, subprocessors and deletion controls. Send only the fields needed for the check and document the decision.
- Preserve uncertainty. Retain result categories, reasons and timestamps. Separate invalid, valid, unknown and accept-all outcomes instead of forcing them into a single pass/fail column.
- Review proposed changes. Do not automatically remove every role address or rewrite spelling. A shared sales mailbox may be intentional. Use your collection evidence and the purpose of the communication.
- Import carefully. Update technical status without overwriting permission, opt-out dates or existing suppressions. Check a small sample of records before applying the batch result.
Do not turn checking into a sending licence
A verification result is a dated observation, not a permanent guarantee. It does not establish inbox placement, readership or continuing interest. SMTP acceptance transfers responsibility for a message; it does not prove the recipient read it. RFC 5321: Simple Mail Transfer Protocol Continue investigating actual bounce responses rather than treating an earlier check as decisive.
A confirmation check at sign-up can help demonstrate control of the address, but it must be designed around the communication the person requested. Do not send a marketing "repermission" campaign to an unpermissioned list merely to test which addresses respond.
For the wider picture, see what free email checks can already show you and the business email deliverability guide.
Verification must also respect one-click unsubscribe and suppression handling rather than putting a removed address back into circulation.
Keep the list safe after the check
Keep suppression controls active across connected systems. The ICO says people can withdraw consent at any time, and unsolicited marketing must stop unless they later give consent again. ICO electronic mail marketing rules Preserve the distinction between a technical correction and a new marketing choice.
Next, improve the collection form, investigate recurring bounce causes and document how uncertain results are handled. Repeat checks when there is a justified operational need, not as a substitute for permission or relevant content. If addresses still bounce after verification, use the bounce code guide to find the real cause.