Pre-Send Evidence Checklist for High-Value Outreach

A pre-send evidence checklist helps a team answer one question before a valuable contact enters an outbound campaign: what do we actually know, and what are we merely assuming?

For high-value outreach, that distinction is worth making explicit. The contact may represent a strategic account, a client campaign, an executive relationship, or a limited ABM list where replacing a bad record is cheaper than discovering the problem after launch.

The Core Problem in This Specific Scenario

Outbound teams often collect many signals but mix them into one confidence feeling.

A researcher may know that the person works at the target company. An enrichment provider may return an email. DNS may show that the domain routes mail. A verifier may provide a status. A salesperson may recognize the name. All of those facts can be useful, but they answer different questions.

The danger is evidence substitution: treating one signal as proof of another.

Examples:

• An MX record supports the conclusion that the domain has configured mail routing. It does not prove that alex@company.com is a live mailbox.
• SPF describes authorization for sending on behalf of a domain. It does not prove the recipient mailbox exists and does not guarantee inbox placement.
• A role-based address can be real and active while still being the wrong recipient for a named-person campaign.
• A contact can match the ICP perfectly while the email evidence remains uncertain.
• A technically plausible address can belong to the wrong person.

When those distinctions are not documented, reviewers tend to collapse uncertainty into either optimism or over-suppression. High-value teams need a middle path: preserve what is known, identify what is not known, and choose the next action accordingly.

A Targeted Way to Solve It

Use the checklist in five evidence groups.

A. Identity and relevance evidence

• Is the person or function relevant to the campaign?
• Is the company a target account?
• Is the role current enough for the intended outreach?
• Is the source recorded?
• Is the contact named, or is it a shared functional inbox?

This section prevents teams from using technical validation to compensate for weak prospect selection.

B. Address structure and hygiene

• Is the email syntactically usable?
• Is the domain spelled correctly?
• Is the record duplicated?
• Is the address obviously no-reply or otherwise unsuitable?
• Does the address contain a pattern that requires manual inspection?

These checks remove avoidable data problems.

C. Domain-level mail evidence

• Does the domain have usable mail routing?
• Are relevant authentication records present when your review requires them?
• Are you recording the state rather than interpreting it too broadly?

A domain can be well configured while an individual mailbox remains uncertain. Keep this section explicitly labeled domain-level evidence.

D. Mailbox and address-type evidence

• Is mailbox status confirmed, unconfirmed, unavailable, or contradictory?
• Is the domain catch-all?
• Is the address role-based?
• Is it associated with a disposable provider?
• Is the evidence fresh enough for this campaign?

Do not force “unconfirmed” into “invalid.” The purpose is to expose uncertainty.

E. Decision and ownership

• Is there a blocking signal?
• Does the contact meet the campaign acceptance policy?
• Does uncertainty require REVIEW?
• Who is authorized to approve an exception?
• What reason will be stored?

A simple evidence record might look like:

Identity: named VP at target account
Source: company leadership page
Domain mail routing: present
Mailbox evidence: unconfirmed
Role-based: no
Campaign policy: mailbox confirmation not mandatory when other evidence is strong
Decision: SEND
Boundary: individual mailbox existence not proven
Reviewed: 2026-07-26

A second-line audit tool such as Secwyn can organize technical evidence into SEND, REVIEW, or SUPPRESS and attach a reason and recommended action. That can make the checklist easier to operationalize, but it should preserve the evidence boundary rather than replacing it with a stronger claim.

Where This Approach Fits — and Where It Does Not

This checklist is most useful when someone other than the researcher must trust the result. Agencies can attach the evidence logic to a client approval process. RevOps teams can use it before a CRM or sequencer handoff. ABM teams can review a small set of strategically important people without pretending every signal is equally conclusive.

It is also useful for troubleshooting. If a campaign later sees unexpected bounces or wrong-contact replies, the team can inspect which evidence was available at launch instead of guessing what happened.

The checklist does not establish sender reputation. It does not audit message content, frequency, domain warm-up, or recipient filtering. Those belong in a broader deliverability review.

It also does not determine consent or legal compliance. A contact can have strong technical evidence and still be inappropriate to contact under the policy or law that applies to your organization.

The checklist should stay proportional. A low-value, broad research workflow may not require manual confirmation for every uncertain record. A high-value executive campaign may. The evidence categories can remain consistent while the decision thresholds vary.

Common Misconceptions

“More signals always mean more certainty.” Signals can be correlated or answer different questions. Count evidence by relevance, not by quantity.

“Authentication records validate the recipient.” SPF, DKIM, and DMARC are domain-level email authentication concepts. They do not confirm an individual recipient mailbox.

“Unconfirmed mailbox means invalid.” Unconfirmed means the available process did not establish mailbox-level certainty. That is different from a confirmed structural or domain failure.

“A checklist removes the need for judgment.” A good checklist makes judgment visible and consistent. It does not eliminate legitimate exceptions.

“Evidence only matters before launch.” The retained evidence is valuable later for client reporting, incident review, and improving policy.

Frequently Asked Questions

What is the most important evidence before high-value outreach?

There is no single universal signal. The most important combination is target relevance, usable contact data, absence of blocking technical evidence, and a clear understanding of remaining uncertainty. For strategic contacts, source and identity evidence may matter as much as technical checks.

Should SPF, DKIM, and DMARC be on the contact checklist?

They can be included as domain-level context when relevant, especially in a broader infrastructure review. Do not treat their presence as proof that the recipient mailbox exists or that your message will be delivered or placed in the inbox.

What should happen when mailbox evidence is unavailable?

Record it as unavailable or unconfirmed, then apply the campaign policy. A high-value workflow may route the contact to REVIEW. Another workflow may proceed if other evidence is strong and no blocking signal is present.

How should a checklist handle role-based addresses?

Record the role-based nature of the address and compare it with the campaign’s recipient policy. A shared inbox may be appropriate for partnerships or procurement and inappropriate for a campaign designed for one named executive.

Is a checklist useful for client reporting?

Yes. It gives the client a defensible explanation of what was checked and how uncertain records were handled. The report should describe evidence accurately and avoid implying outcomes such as guaranteed delivery.

Can Secwyn replace the checklist?

Secwyn can automate part of the evidence and decision workflow, but the broader checklist should still include source, audience fit, policy ownership, and any human approval required by the campaign.

Related: Pre-Send Email Risk Assessment and Audit Trail for Email Campaigns.