Verified is a technical assessment at a point in time. It is not a promise of inbox delivery, a buying signal or permission to contact someone.
Four questions hide inside one green badge
When a lead list says verified, ask what was verified. Does the address appear technically usable? Does it belong to the person you intended to reach? Does that person still work at the company? Is your planned communication lawful and appropriate? These are four different questions. A single status badge should not silently answer all of them.
This matters when comparing suppliers. One file might contain a recent mailbox check. Another might contain an address inferred from a naming pattern. A third might use a status inherited from an older database. Ask for the status definition and timestamp before treating two exports as equivalent. More rows do not necessarily mean more usable contacts.
Read the provider's status definitions
Hunter's Email Verification FAQs explain that a valid result can still change after the check. Accept-all domains accept addresses in a way that prevents full certainty about a particular mailbox; unknown results can arise when the server does not respond or blocks verification. These are Hunter's documented meanings, not a promise that every supplier uses identical labels.
Keep the original provider status alongside any simplified internal label. If your import converts both unknown and valid into ready, you have destroyed a useful distinction. Likewise, do not turn an accept-all result into verified merely because its confidence score looks high. Record the uncertainty and decide how your team will handle it before the list reaches a sending tool.
- Store the original status, provider and verification time.
- Separate known invalid addresses from unresolved results.
- Keep account and role checks outside the technical email status.
- Document the rule that decides whether a row can be exported.
Audit identity and relevance separately
Imagine a fictional export containing an operations director at a company you want to approach. The email passes a provider check, but the person moved to another employer. The address may still accept mail or forward internally. Your outreach can still reach the wrong person. Technical validity did not establish current employment or responsibility.
For a review sample, compare company domain, name, title and the source of the employment information. Flag conflicting evidence rather than choosing whichever version makes the list bigger. Keep a distinct not-our-buyer outcome for people whose role does not match the offer. That gives you useful feedback about the search instead of blaming every poor result on verification.
Permission is not a property of the mailbox
The ICO's Business-to-business marketing guidance explains that UK GDPR can apply to business contact data and that electronic marketing rules depend on the subscriber type. The FTC's CAN-SPAM business guide also makes clear that US commercial-email rules cover B2B messages. Neither framework turns a technical verification result into consent. This is general information, not a determination that your campaign is lawful.
Give compliance its own approval step. Record the recipient market, source of the contact, intended purpose and applicable suppression checks. Do not purchase a list on the assumption that a supplier's compliance label transfers every responsibility to you. If the legal basis or permitted channel is unclear, resolve that question before an export becomes a campaign.
Check the sending system too
Google's Email sender guidelines set authentication and delivery requirements for messages sent to personal Gmail accounts, with additional requirements for bulk senders. A clean recipient file does not replace that infrastructure work. Check the current rules for your sending service and destination before launching; do not treat verification as an inbox-placement guarantee.
Run a controlled pilot only after relevance, permission and sender configuration have been reviewed. Track attempted sends, delivery failures, objections and genuine replies separately. If the pilot exposes a systematic identity error, stop and repair the data. Sending a larger batch will not fix a wrong-domain mapping or a stale role field.
Define usable before counting success
Write a one-line acceptance rule that the team can audit. For example: the account fits, the role is relevant, the contact evidence is current enough for our policy, the provider result meets our threshold and the communication has passed our legal review. This is an operational definition, not a universal standard or a substitute for professional advice.
Report the count at each gate. If a thousand purchased rows become a hundred approved contacts, the useful number is a hundred, along with the reasons the others failed. Sync Scala's enrichment depends on configured providers and their returned data. No provider status should be read as guaranteed accuracy, consent or a guaranteed response.
Sources and further reading
- Hunter: Email Verification FAQs
- ICO: Business-to-business marketing
- FTC: CAN-SPAM Act compliance guide for business
- Google: Email sender guidelines
Prepared with AI assistance and checked against the linked sources. Examples are illustrative, not customer results. See our editorial standards or request a correction.