Why do bounces cost more than the failed send?
Mailbox providers use several signals when filtering mail. Record hard-bounce and complaint statuses, follow the current sender guidance for each provider, and separate mailbox validation from the sending practices that also affect placement.
A syntactically plausible address can still fail a current mailbox check. Record the validation method, returned status, and timestamp, then measure the invalid share in the submitted cohort instead of applying a general list benchmark.
Validation before a send creates a dated decision point. Suppress failed addresses, separate uncertain results for review, and retain the returned reason so a later campaign does not silently restore a rejected mailbox.
What checks do we run?
Each address moves through a sequence of checks, ordered from cheap to expensive:
- Syntax validation. Properly formed, valid characters, no mangled copy-paste artifacts like trailing spaces or swapped characters.
- DNS lookup. The domain resolves. Addresses at companies that shut down or rebranded fail here.
- MX record check. The domain has mail servers configured. A registered domain with no MX records receives nothing.
- SMTP verification. We ask the mail server whether the specific mailbox exists, without sending a message.
- Domain-wide acceptance detection. Domains that accept mail for any address get flagged, since mailbox-level verification can't give a straight answer there.
- Disposable and role detection. Temporary inboxes, plus role accounts like info@ and support@ that reach a queue instead of a person.
The mechanics of each layer, and what the result categories mean, are covered in our email validation glossary entry. This page is about what we do with those results.
Where does the human review come in?
Automated checks can leave ambiguous results that need judgment, especially when a server accepts each address or responds inconsistently. A managed review should expose those exceptions instead of forcing them into a clean-looking binary result.
Domains with domain-wide acceptance accept mail for addresses without confirming whether a specific mailbox exists, so an SMTP check can remain inconclusive. We preserve that status and corroborate the record: does the person still work at the company, does the address follow the pattern of confirmed colleagues, and do other sources report the same mailbox? The output distinguishes evidence from the final recommended action.
Greylisting servers, timeout-prone hosts, and mailboxes that answer differently on retry get the same treatment. A person looks at the conflict and makes the call, instead of letting "unknown" pile up into a segment you don't know what to do with.
What lands back in your inbox?
A CRM-ready file rather than a wall of status codes. Each record keeps your original fields plus:
A verdict. Valid, invalid, domain-wide acceptance, or risky, with the failure reason where one exists: domain gone, mailbox not found, disposable, role account.
A recommended action. Send, suppress, or re-source. The suppress segment keeps your bounce rate down; the re-source segment tells you which contacts are worth finding fresh addresses for, something worth doing when the contact is an open opportunity rather than a cold name.
A list quality summary. What share of the submitted cohort was deliverable, how failures break down, which results remain uncertain, and how those results compare with the acceptance targets defined for this file.
How should the result be imported?
Keep the submitted address beside the returned status, checked date, reason, source, and recommended action. Load those fields into a staging area before updating the CRM. That gives the owner a chance to review conflicts, protect confirmed customer values, and reject changes that do not meet the agreed rule.
Apply suppression by stable record identifier where possible so a later list upload does not restore the same failed address. Route uncertain and domain-wide acceptance results to a separate review queue. After approval, reconcile import counts with the delivered file and retain the rejected-row report. The result is an auditable change set rather than an unexplained overwrite.
When should you run validation?
Three moments deserve a validation decision: before a large send, before a CRM migration, and after a list purchase or event import. In each case, define the cohort, preserve the validation date, and prevent failed or uncertain addresses from moving forward without the agreed review.
Between those moments, treat a prior result as dated evidence with a defined review point. Set the next review from observed changes in your own records, campaign schedule, and tolerance for uncertain mailboxes.
How does the process work?
Step 1: Send the file. CSV, Excel, or a CRM export. Mixed files with phones and addresses are acceptable; email validation combines with phone validation and the rest of the stack in one pass.
Step 2: Automated checks run. Syntax through SMTP, every address.
Step 3: Edge cases get reviewed. Domain-wide acceptances, conflicts, and unknowns go through human corroboration.
Step 4: File comes back. The agreed delivery separates send, suppress, re-source, and review segments and preserves the status behind each recommendation.
What does it cost?
Verum provides a written, scope-specific charge and schedule after reviewing the records, requested checks, exception rules, and delivery format.
Common Questions
Do you send test emails to my list?
No. SMTP verification confirms a mailbox exists without sending a message. We open a connection to the mail server, ask whether it would accept mail for the address, and disconnect before anything sends. Nobody on your list sees a thing.
How accurate is email validation?
The main limitation is domains with domain-wide acceptance, which accept mail for any address and hide whether a specific mailbox exists. Those come back flagged rather than guessed at.
How do you handle domains with domain-wide acceptance?
Uncertain addresses get their own category instead of a guessed verdict. Where the record matters, we corroborate whether the person still works there, whether the address pattern matches confirmed colleagues, and what other sources report. The output preserves the uncertainty and the evidence behind the recommended action.
What is the difference between this service and a self-serve validation tool?
Self-serve tools return raw verdicts and leave the judgment calls to you: what to do with domain-wide acceptances, role accounts, and unknowns. We run the checks, make those calls with human review, and hand back a file segmented into send, suppress, and re-source, ready to import. Same underlying checks, different amount of work left on your desk.
How often should a B2B list be revalidated?
Before each major send if the list has sat for a quarter or more. B2B addresses die when people change jobs, and a list validated in January will have accumulated fresh invalid addresses by June. Teams sending monthly usually revalidate quarterly; a list that's been idle for a year should be treated as unverified.
Can you validate emails as part of a bigger cleanup?
Yes, and most clients do it that way. Email validation slots into the same pass as deduplication, phone validation, and field standardization, so one project returns one clean file instead of four partial ones.
Protect Your Sender Reputation
Your deliverability depends on your reputation, and your reputation depends on your bounce rate. Validate before you send, and the bounce problem rarely starts.
Related: Email Validation (Glossary) | Phone Validation | Pre-Import Validation | All Validation Services