The short answer

Check relevance and suppressions before address validation. Separate invalid addresses from stale records, inactive contacts, catch-all results and unknowns. Keep an owner and reason for each decision, reconcile the final audience back to your CRM, and check suppressions again before release. A valid email address does not establish permission, interest or inbox placement.

Start with the campaign, rather than the whole database

An ATS record is not automatically a recipient for the next mailshot. Define the message, the intended audience and why the information is relevant now. Keep an expected interview update separate from a new-role campaign or speculative client approach.

Ask the campaign owner what evidence supports the selection: a current preference, a recent conversation or another documented reason that your organisation has assessed. An old job title or a record being present in the CRM is weak evidence of current relevance.

This is an operational preparation method. It does not determine the legal basis for outreach. Your responsible owner must assess the message, recipient, applicable law and platform rules. SourceWhale’s published terms also impose recipient and acceptable-use requirements; a technically valid address does not override them.

Treat different data problems differently

Record condition What it means for preparation Suggested next step
Suppressed or opted out There is a recorded restriction or preference Exclude according to its scope; preserve the restriction across systems
Confirmed invalid Evidence indicates this address cannot accept mail Stop using that address for the campaign; retain the reason in the approved system
Stale information Role, employer, address or preference may have changed Review the relevant facts before including it
Inactive contact No useful recent engagement is recorded Review relevance; lack of opens alone does not prove invalidity
Unresolved catch-all The individual mailbox has not been confirmed Hold separately for an approved decision, rather than treating it as validated
Unknown validation result The service could not reach a conclusion Review its reason and any supported recheck; do not relabel it valid
Duplicate More than one record may refer to the same contact Resolve ownership and conflicting preferences before sending

Validation services use different classifications. Read the result and sub-status together. For example, a syntax problem and a temporary server issue need different treatment; neither should be turned into a blanket conclusion about the person.

Screen suppressions before an export or validation job

For direct marketing, the ICO recommends keeping enough information on a suppression list to prevent an opted-out person being added back by mistake. Simply deleting a marketing record can lose that protection.

Identify the source of truth for preferences and the systems that will actually send or schedule follow-ups. Check what happens when an ATS export, a SourceWhale campaign and a later import contain different values. A freshly enriched or validated address should not silently reset an existing restriction.

Keep the preference’s scope clear. Have the responsible team resolve conflicts or erasure requests through its approved process; do not improvise a new retention rule in a campaign spreadsheet.

Review stale records without guessing a new address

An address can remain technically valid after a person changes role or loses interest. Conversely, no tracked open may reflect image blocking rather than a dead mailbox. Keep technical validity and current relevance in separate fields.

Do not “repair” an address by guessing a new employer’s domain or accepting an automated typo suggestion without a reliable source. Preserve the original evidence and route an uncertain change to its owner.

For duplicates, check whether records genuinely refer to the same person before merging. Avoid automatic merging based only on a similar name. If the decision needs personal details, make it in the authorised CRM rather than in a public troubleshooting tool.

Use validation for the question it can answer

Address validation can add evidence about address and domain conditions. It cannot establish whether a candidate wants the campaign, whether your organisation may send it, or which folder the message will reach.

A catch-all domain may accept mail for addresses whose individual mailbox does not exist. Current ZeroBounce guidance distinguishes a domain-level catch-all indicator from an unresolved address result: a service may resolve some individual addresses while others remain uncertain. Keep those fields separate rather than excluding or accepting every address at the domain automatically.

For unknown results, record the provider’s reason. A timeout or anti-spam system can prevent a conclusion. Follow the service’s supported recheck process and your organisation’s policy; do not send a speculative mailshot merely to see which addresses bounce.

Before sharing any list with a validation supplier, have the authorised owner approve the service and the data it needs. Use the minimum fields needed for that task. Candidate notes, CVs, special-category information and client details do not belong in a routine address-validation file. This website does not accept candidate-list uploads.

The tool comparison explains the difference between validation and placement testing, including why buying the wrong report will not answer a list-quality question.

Reconcile the audience before release

Our suggested workflow is:

  1. Save the selection criteria, source-system reference and preparation date.
  2. Exclude restricted records and resolve conflicting preferences.
  3. Review stale and duplicate records in the approved system.
  4. If validation is justified, keep its dated status, sub-status and unresolved decisions.
  5. Apply authorised updates back to the source system without reactivating suppressed contacts.
  6. Check the final sending audience and scheduled follow-ups against current suppressions again.
  7. Name the person who will monitor failures, complaints and opt-outs after sending.

An export prepared earlier can become stale before release. The final check matters especially when another recruiter or workflow may have changed a preference in the meantime.

Download the blank candidate-list preflight worksheet. It records decisions and counts, not a candidate database. Complete it privately; nothing needs to be uploaded here.

Learn from failures without confusing the measures

If a message fails, keep the complete rejection and identify whether it concerns an invalid address, a temporary problem, authentication or a policy decision. Do not delete a valid person’s record simply because one message was blocked.

Review outcomes by list source and message purpose where your approved reporting permits it. Keep bounce events separate from recipient spam complaints and keep both separate from seed-test placement. A cleaner audience is one part of preparation; the recruitment preflight checklist covers the sending route and message as well.

Sources & scope

This is a documentation-led guide, not a claim of hands-on testing in your account. Sources checked 20 October 2026. Product settings and provider policies can change.

Editorial responsibility: Inbox Field Guide. Read our research method or suggest a correction.

Give IT something useful to work with.

Turn the symptoms and checks into a clear, private handoff.

Build an IT handoff