Business-email verification is not a binary oracle. A verifier can detect malformed addresses, missing mail servers, some nonexistent mailboxes, disposable domains, or catch-all behavior. It cannot reliably prove that the person still holds the job, that the mailbox belongs to that person, or that outreach is appropriate. Build confidence in layers.
Verify the company and role before the mailbox
First confirm that the company domain is current. Check the company website rather than assuming a database domain is correct. Rebrands and acquisitions can leave old domains forwarding or parked.
Next confirm that the person still appears to hold a relevant role using a recent company page or professional source. A technically deliverable mailbox for a former employee is not a useful lead.
Store the role source and checked date separately from the email-verification result.
- CompanyConfirm current domain/source.
- PersonCheck current role and retain source/date.
- AddressNormalize syntax; inspect domain/MX.
- VerifierKeep exact category and timestamp.
- PolicyAssess contact eligibility separately.
Run deterministic checks before a paid verifier
Normalize whitespace and obvious capitalization. Confirm the address has one `@`, a plausible local part, and a domain that resolves.
Check whether the domain publishes MX records. A domain without mail exchange service may still use unusual routing, but for ordinary business-email prospecting it is a strong warning.
Look for role accounts such as `info@`, `support@`, or `sales@`. These are not inherently invalid, but they represent a function rather than a named person and should be labeled differently in personalization workflows.
Understand the verifier’s categories
Different vendors use labels such as valid, invalid, risky, catch-all, unknown, or accept-all. Read the vendor definition.
“Valid” generally means the service found evidence consistent with deliverability; it does not guarantee inbox placement or human ownership. “Invalid” is a reason to suppress before sending. “Catch-all” means the domain accepts mail in a way that prevents reliable mailbox-level confirmation. “Unknown” can occur when the remote server blocks a probe or will not provide enough information. Do not convert catch-all and unknown to valid simply to hit a list-size target. For outbound lists, suppress clear invalid or disposable results and keep catch-all, blocked, and unknown records in a separate review tier; use source evidence and a small, monitored sample if the business chooses to test that tier.
A website signup has a different goal from outbound prospecting. NeverBounce recommends allowing unknown results through at point of entry because single checks can time out; avoid rejecting a legitimate signup solely for an inconclusive result, and apply separate abuse controls.
Do not use live SMTP probing irresponsibly
Some verification systems interact with receiving mail servers without completing delivery. Remote servers can block or tarpitting such probes, and aggressive verification can itself become abusive. Use reputable services and respect their published method and rate controls.
Your own outbound campaign should not be used as a “verification blast.” A hard-bounce-producing test to thousands of guessed addresses damages the very sender reputation you are trying to protect.
Add pattern inference as a separate confidence field
If the company clearly uses a pattern such as `first.last@domain.com`, you may infer a candidate address for research, but label it `pattern_inferred`, not `verified`.
Verify known employee examples before deriving the pattern, and be careful with initials, middle names, duplicate names, accents, and name changes. If the verifier returns catch-all, the pattern remains an inference.
This distinction is operationally valuable: sales can prioritize confirmed addresses, then handle inferred catch-all addresses in a smaller risk tier.
Email verification is not contact permission
For U.S. commercial email, CAN-SPAM imposes requirements on commercial messages including truthful headers/subjects, identification rules, a physical postal address, and a functioning opt-out process. Other laws and platform policies can apply depending on recipients and geography.
Therefore use two separate fields: technical email confidence and contact-policy status. A mailbox can be technically deliverable while still being excluded by your campaign rules.
A strong verification workflow reduces hard bounces and false personalization because each row says not only “email = X” but also “why we believe X, when we checked it, and what uncertainty remains.”
Keep verification evidence current
Store the verifier, exact status, and checked date. A mailbox can change after it was checked, so re-verify stale or purchased records before a campaign. Do not rerun an unchanged catch-all or unknown result every night; re-test after a domain migration, first-party confirmation, source refresh, or enough time for the mailbox state to change.
If providers disagree, keep each result with its source and date rather than averaging them into a false certainty. After sending, let a definitive permanent invalid-recipient response override an older “valid” result and update the suppression reason. A successful delivery still does not prove the person read the message or that the address belongs to the intended person. Track outcomes by source and verification status to find overly optimistic vendors or overly aggressive rules.
