Email verification

Last quarter, a 42-person SaaS company imported a list after an acquisition and sent it straight into a sales sequence. Email verification marked most of the addresses as valid. The first batch still produced a messy mix of bounces, dead inboxes, and contacts who had left months earlier.

The problem wasn't just the verifier. The team treated one column of green results as proof that the list was ready.

Email verification should answer a narrower question: is there enough current evidence to treat this address as contactable? It doesn't tell you whether the person is the right buyer, whether the title is current, or whether they'll reply. And it isn't a permanent yes or no.

Start with the person, not the mailbox

A mailbox check can't fix a bad contact record.

If the person isn't actually at the company, a technically deliverable address is still useless. The same goes for a guessed title or an address built from the wrong domain after a merger.

The stronger approach is to ground the record first. Start with company and contact data collected from owned sources, then enrich only where the record is incomplete. Put the person against the right company and org structure. Confirm that the role makes sense. Then derive the address from the company's observed email convention.

That order matters. Suppose a 120-person cybersecurity company acquires a smaller consultancy and keeps both domains active for six months. A contact may have a real name, a real title, and two plausible email addresses. A simple first.last guess won't tell you which domain the person actually uses. The company record and domain history need to be resolved before verification can mean much.

The address generator should handle more than the obvious pattern. It needs to work through variations such as first initial plus surname, surname plus first initial, nicknames, and other common formats. Around 19 patterns may be useful as a starting point, but the important part is learning what a specific domain actually does. A pattern that works at one company shouldn't be copied across every company in the database.

What a verified address means

A verified address has enough supporting evidence to be treated as contactable under the checks that ran at that time.

That's all. It does not mean the mailbox is monitored. It doesn't prove the person still works there. It certainly doesn't mean the account belongs in your campaign.

Outbound teams get this wrong because "verified" sounds stronger than it is. In practice, it's a sending decision backed by evidence, not a guarantee.

A useful verification process runs multiple checks rather than trusting one provider's response. Two checks can run in parallel, with a third used to investigate ambiguous catch-all results. The goal isn't to manufacture confidence. It's to find disagreement before it becomes a bounce or a bad send.

Catch-all domains are where shallow verification tends to break. A catch-all mail server accepts messages sent to addresses that may not map to a real individual mailbox. A basic SMTP check can see that the domain accepts mail and return a positive result. That only proves the domain is permissive.

It doesn't prove that jordan.lee@example.com belongs to Jordan Lee.

The extra check should try to separate an actual mailbox from a domain that accepts nearly anything. Sometimes it can. Sometimes it can't. A system that returns "verified" in both cases is hiding the distinction your campaign needs.

Unknown is not invalid

Unknown means the evidence isn't strong enough to confirm the address. Invalid means the address should not be sent to.

Those are different operational states. Treating them as the same throws away potentially usable contacts. Treating both as verified is worse.

When the domain accepts everything, the adaptive guesser should stop pretending it has certainty. That may leave the address as unknown. Good. The honest answer is more useful than a positive verdict based on a weak signal.

A team might hold unknown records for another source, send them through manual review, or exclude them from a high-volume campaign. For example, a five-person founder-led company may have a catch-all domain and no public employee directory. An unknown address there could be worth checking manually before a one-to-one sales note. It probably isn't worth putting into a 10,000-contact sequence.

My view is simple: teams get more damage from forced certainty than from visible uncertainty. Unknown records make the edge cases visible. False positives bury them in the campaign report.

Freshness belongs on the record

A verification result ages because the thing being checked changes.

People leave. Mail systems change. Companies merge domains, switch providers, or shut down old inboxes. A result from six months ago isn't equivalent to one checked this morning, even if the address itself looks unchanged.

Verified results stay fresh for 30 days and expire at 90. That gives the sending system a useful boundary:

• within 30 days, the result is fresh
• from 31 to 90 days, it can still be used but deserves less confidence
• after 90 days, it should be treated as stale and checked again

The exact windows can vary by workflow, but a window needs to exist. Without one, a database import quietly turns a temporary result into a permanent property of the contact.

This is why email verification shouldn't happen only during list cleanup. Run it close to the point of sending, especially after a trigger such as an acquisition, a major role change, a domain migration, or a list that has sat untouched for a quarter.

The person record needs the same attention. Normalize titles into a role taxonomy before selecting contacts. "Chief Revenue Officer," "VP of Sales," and a company-specific title may describe similar responsibilities, but they shouldn't be left for the sequence logic to interpret later. Better targeting reduces the number of bad records that verification is expected to rescue.

Why one provider can't carry the decision

One provider gives you one interpretation of a difficult technical question. It may have good coverage for common domains and weaker coverage for smaller regional providers. It may treat catch-all responses as positive. It may also keep returning a result after the contact record has changed.

That doesn't make the provider useless. It makes it a source of evidence, not the whole decision.

A practical workflow looks like this:

1. Collect the person and company record from reliable sources.
2. Resolve the right domain and derive the address from that company's convention.
3. Run independent checks, including a check for catch-all ambiguity.
4. Store the verdict with its freshness date.
5. Route verified, unknown, and invalid records into different actions.

No checker can repair a contact who never belonged to the account. No enrichment source can make an old result current. And no system can turn a catch-all response into certainty just by returning a greener status.

The useful verdict is the one that tells the sending system what it can safely do next. Send, hold, or reject. Anything more confident than the evidence deserves is just a bounce waiting to happen.