The last check before a campaign goes out
A campaign is scheduled, the segment is built, and the send button's an hour away. Everything after that point is a correction rather than a decision.
Scale is what makes this worth doing. A mistake in a send to two hundred people is a nuisance. The same mistake across two hundred thousand is an account review, and the difference is entirely in the size of the segment.
The order the work happens in
Check when this segment was last verified
If the answer is more than three months, or nobody knows, that's the whole argument for running one now. A stamp with a date makes this a five-second question in future.
Confirm the suppression list is applied
Unsubscribes, complaints and previous hard bounces. Most platforms do this automatically and the failures happen when a segment was built from an uploaded file rather than from the database.
Verify the segment if it is old or unfamiliar
Not the database. A segment of 40,000 out of a 300,000-contact list is a much smaller job and covers the only addresses this campaign can damage you with.
Send a seed test and actually open it
To your own addresses across Gmail, Outlook and Yahoo. Look at where it landed, click the links, and click the unsubscribe. A broken unsubscribe turns people who wanted to leave into complaints against you.
Check authentication has not drifted
SPF and DKIM on the sending domain, especially if anything changed in DNS or in the sending platform since the last campaign.
What each result means here
The same four results and their flags, read against this job. A catch-all worth keeping in one situation is one to exclude in another.
| Result | What to do with it |
|---|---|
| Valid | Send. |
| Invalid | Exclude from this campaign, then suppress permanently rather than only for today. |
| Catch-all | Send if the segment is engaged, exclude if it is cold. The same verdict means different risk depending on who these people are. |
| Unknown | Exclude if the campaign is large. A small share of non-answers is not worth delaying a send for. |
| Role flag | Send, unless this is cold outreach, where role addresses are the complaint generators. |
| Disposable flag | Exclude and remove from the database while you are here. |
How you know it is finished
The segment has a verification date, suppressions are applied, a seed message arrived in an inbox rather than a junk folder, and every link in it including the unsubscribe has been clicked once by a human.
What this does not fix
Checking a campaign segment rather than a database is what keeps this affordable enough to repeat: 40,000 addresses is well under the $89 tier for 50,000 credits, and duplicates inside the segment are not billed.
Questions people ask
Should I verify before every send?
Before sends to data older than about three months, and before any unusually large one. A weekly newsletter to an engaged segment surfaces its own decay and rarely needs it.
How long before the send should the check run?
Far enough ahead that the results can change the plan. A check that finishes thirty seconds before the send isn't a control, it's a formality.
What else belongs in a pre-send check?
Suppression applied, authentication passing, a seed test opened and clicked, and the unsubscribe link tested. Those cost nothing and catch failures verification cannot see.
Try it on the file in front of you
100 free checks a month, no card. Addresses we could not get an answer on come back labeled as unknown, and those are not billed.