Campaign Preflight Checks Every Team Should Run

A campaign preflight is the controlled review between building an email and pressing send. It is where marketing, CRM, engineering and deliverability teams make sure that the intended message is going to the intended people, through the intended infrastructure, with a safe way to stop receiving it.

It is easy to reduce preflight to a final proofread and a test send. Those matter, but they are only part of the job. A polished email can still create complaints if it reaches people who did not expect it. A well-segmented campaign can still fail if a DKIM signature breaks after a template change. And a healthy programme can be damaged when a familiar sending domain suddenly delivers several times its normal volume.

The purpose is not to create bureaucracy before every send. It is to make the risks visible while there is still time to change the audience, repair the build, slow the release or postpone a campaign altogether.

Start with a release decision, not a cosmetic review

Before checking HTML, establish what this campaign is, who asked for it and what a safe release looks like. The campaign owner should be able to answer four questions plainly:

• What is the message? For example, a weekly product newsletter, a renewal reminder or a one-off launch announcement.
• Why is each recipient eligible? This should be based on the subscription or customer relationship and the permissions recorded for that person, not on a vague assumption that they are “in the database”.
• What sending stream will carry it? Marketing and operational messages should not be casually mixed simply because they share a template or sender platform.
• What would make the campaign unsafe to send today? Examples include an unresolved authentication failure, a stale suppression export, an unexpectedly large audience, a broken unsubscribe endpoint or a material rise in complaints from the previous comparable send.

This gives reviewers permission to stop a campaign for operational reasons. It also prevents a common failure mode: treating a full send as the first proper test of a new segment, template, sender domain or sending pattern.

Confirm the audience is both eligible and current

Audience review is the most consequential preflight check. Mailbox providers receive the strongest signal from recipient behaviour: whether people read, ignore, unsubscribe from or report a message. No amount of elegant creative compensates for sending a campaign to people who did not reasonably expect it.

Freeze a recipient snapshot for review rather than approving a segment description such as “active UK subscribers”. Record the final count, the query or rules that produced it, the data refresh time and any exclusions. If the count is materially different from the comparable campaign, find out why before sending. A 40% increase might be entirely legitimate; it might also be a join error, a changed preference rule or the accidental inclusion of old records.

Suppression must be applied at send time

Suppression is not a list that is cleaned up occasionally. It is a decision applied when the message is assembled. The campaign should exclude, as relevant:

• people who unsubscribed from that programme or category;
• global opt-outs and do-not-contact records;
• recent spam complaints received through feedback loops;
• hard bounces and addresses known to be undeliverable;
• records subject to a legal, contractual or customer-service suppression;
• people who have already received the maximum planned contact pressure in the relevant period; and
• customers for whom the message would be inappropriate, such as people with an open cancellation or complaint case.

Check how quickly these events reach the sending platform. If an unsubscribe, complaint or hard bounce is processed overnight but the campaign is scheduled for the afternoon, the exclusion may be technically present yet practically stale. Run the suppression process, then create the final audience after it has completed.

Be especially careful where multiple systems are involved. A preference centre, ecommerce platform, CRM and email service provider can each hold a different version of a person’s status. The preflight should identify the system of record and confirm that its decision has reached the delivery system.

Use engagement thoughtfully

For broad promotional campaigns, a sensible engagement rule can reduce the risk of repeatedly mailing people who no longer respond. However, engagement is not synonymous with email opens. Treat opens as a supporting signal rather than proof of human attention, particularly where mail clients use privacy features for remote content; Apple explains that Mail Privacy Protection hides recipients’ IP addresses from senders. Use multiple signals where available, such as recent clicks, purchases, logged-in activity, explicit preferences and recency of subscription.

The right rule depends on the programme. A monthly newsletter, a seasonal retailer and a product with an annual purchase cycle should not share the same inactivity window. What matters is that the inclusion rule reflects a genuine, documented expectation of contact.

Verify the identity and path of the message

Authentication is a release dependency, not a one-time DNS project. A campaign can fail authentication because of a new sending platform, a changed From address, an unsigned stream, a malformed header or a DNS change that seemed unrelated to email.

For every production stream, confirm that SPF, DKIM and DMARC are working on an actual delivered message. In simple terms: SPF identifies permitted sending infrastructure; DKIM adds a cryptographic signature to the message; DMARC checks whether the visible From domain aligns with a passing SPF or DKIM identity and publishes a policy for failures.

Google requires high-volume senders to personal Gmail accounts to use SPF, DKIM and DMARC, align the visible From domain with SPF or DKIM, use TLS and maintain valid forward and reverse DNS. Its guidance also says that senders of more than 5,000 messages a day to Gmail accounts must support one-click unsubscribe for marketing and subscribed mail. Google’s email sender guidelines are a useful baseline even for programmes below that volume.

Check the complete message path, not just DNS records:

• the visible From address is stable, recognisable and appropriate for the type of message;
• the return-path or envelope sender is expected for the platform and stream;
• a valid DKIM signature survives delivery and uses the planned signing domain;
• DMARC passes with the intended alignment;
• the sending IP or hostname has working forward and reverse DNS where your infrastructure requires it;
• delivery uses TLS; and
• reply handling is deliberate. A reply-capable address needs an owner and a workable process, while a no-reply address should not be used to avoid customer contact.

Send a production-like test to seed inboxes and inspect the received headers. Do not assume that a platform preview proves authentication, because previews often do not pass through the same delivery route or apply the same headers as the live campaign.

Make unsubscribing easier than complaining

A recipient should be able to leave a marketing programme quickly and without logging in, explaining themselves or navigating several screens. This is good subscriber experience and a practical deliverability control.

For marketing and subscribed messages, test both the visible body link and the list-unsubscribe headers. The IETF’s RFC 8058 specification for one-click unsubscribe defines the header-based method: an HTTPS URL in List-Unsubscribe plus List-Unsubscribe-Post: List-Unsubscribe=One-Click. The endpoint must process the request directly; it should not depend on cookies, a login session or a confirmation page. The recipient and list should be identified with an opaque, hard-to-guess token rather than exposing personal data in the URL.

The body link can lead to a preference centre where that is useful, but it must work on mobile, load reliably and make the immediate choice clear. A preference centre should offer meaningful choices, such as reducing frequency or opting out of a product category, without concealing the full unsubscribe option.

Yahoo’s current sender guidance requires bulk senders to use SPF and DKIM, publish a DMARC policy, provide a functioning list-unsubscribe header for marketing and subscribed mail, show a clear body unsubscribe link and honour unsubscribe requests within two days. Yahoo’s sender requirements and recommendations also emphasise matching contact frequency to the expectation set at sign-up.

Test the actual post-unsubscribe outcome. Confirm that the recipient is suppressed in the correct programme, that a repeat request is harmless, and that the status reaches every system which can send them marketing email. A successful landing page is not enough if the address can reappear in tomorrow’s audience export.

Test the message as recipients will receive it

A preflight proof should be assembled from the same data and template logic as the live message. This is where teams catch errors that static design files cannot reveal: a missing fallback value, an incorrect currency, a personalised link pointing to the wrong account or a product block with no stock.

Choose test records that exercise real conditions, including a recipient with a long name, one with missing optional profile data, one who has multiple product interests and one who should be excluded. Review the final rendered message in a sensible set of desktop and mobile environments, using both HTML and plain-text parts.

Pay particular attention to:

• Subject line, preheader and From name: these should accurately set the expectation for the email. Avoid a subject that promises an offer, alert or deadline that the content does not support.
• Personalisation fallbacks: “Hello ,” is an obvious problem; a name or product reference from the wrong person’s data is worse.
• Links and redirects: test each prominent link after tracking has been applied, including preference, unsubscribe, account and deep links. Confirm that app and mobile-web fallbacks make sense.
• Images and accessible content: ensure that core meaning and calls to action are still clear when images do not load. Use useful alternative text where an image conveys information.
• Offer logic: validate prices, eligibility, stock messaging, dates, time zones, voucher rules and landing-page continuity.
• Plain text: it should remain coherent, include the essential links and identify the sender. It is not an afterthought for a small minority of recipients.

Scan the final output for unexpected domains in links, image sources or tracking redirects. A newly introduced third-party domain may be legitimate, but it deserves review because it affects security assessment, recipient trust and troubleshooting later.

Release volume at a pace your programme can support

A campaign’s size is not the same as its safe release volume. Compare the proposed send with recent traffic by mailbox provider, domain, IP and sending stream. A sharp rise may be justified by a sale, a new subscription flow or a reactivation effort, but it should be planned rather than launched as one uninterrupted burst.

Segment the delivery plan by observable risk. Recent, clearly engaged subscribers may be an appropriate initial cohort. Older or less certain records should not be used as a convenient way to make a launch look bigger. For a newly introduced domain, IP range or large audience expansion, release in controlled stages and review response between stages. If bounces, deferrals, complaints or inbox placement deteriorate, pause and diagnose instead of simply retrying faster.

Mailbox-provider-aware pacing is about respecting receiving systems and protecting a permission-based programme. It should never be used to sidestep provider protections or to push unwanted email through a different route.

Keep message types separate where the infrastructure allows. Microsoft advises organisations to consider a dedicated custom subdomain for bulk email rather than sending it from the same domain used for regular business mail, and to configure SPF, DKIM and DMARC for those subdomains. Microsoft’s guidance on outbound spam protection makes the wider point: authentication, list quality and accessible unsubscribing all support delivery.

Know what will be monitored after launch

Preflight should end with a monitoring plan, because delivery problems rarely announce themselves at the moment the send button is pressed. Assign named owners for the first hours of the campaign, escalation conditions and the authority to pause subsequent batches.

Monitor delivery, deferrals, hard and soft bounces, complaints, unsubscribes and engagement signals by provider and campaign cohort. Compare them with a relevant baseline rather than looking only at aggregate totals. An overall bounce rate can look ordinary while one provider is deferring a new stream heavily; a campaign-wide unsubscribe rate can hide a particular acquisition source that is producing complaints.

Use the provider data available to you. Google’s Postmaster tools can help eligible senders observe Gmail spam rate and domain reputation trends. At Outlook.com, Smart Network Data Services (SNDS) provides IP-level data and includes the Junk Email Reporting Program, which supplies reports when users mark messages as junk. Yahoo’s Complaint Feedback Loop is also worth enrolling in where eligible, because complaints should feed quickly into suppression.

These tools are diagnostic inputs, not permission to keep sending unchanged. A recipient complaint should normally result in prompt suppression from the relevant marketing stream. A sustained authentication, bounce or deferral issue calls for an infrastructure and audience investigation before the next large send.

Turn repeat checks into reliable operating controls

The strongest preflight process is built into the campaign workflow. Some checks can be automated: authentication monitoring, header validation, suppression freshness, duplicate detection, link testing, frequency caps and abnormal audience-count alerts. Others need a human decision: whether the message matches the promise made at sign-up, whether an audience expansion is appropriate and whether a launch is worth the reputational risk.

Keep a short record of the approved audience, sender identity, template version, scheduled volume, tests performed and exceptions accepted. This makes the next incident easier to investigate and helps teams distinguish a one-off campaign problem from a systemic issue.

When these controls reveal a persistent issue rather than a single failed send, an independent deliverability review can be useful. Email Foundry’s work in this area focuses on permission-based senders and can include authentication and infrastructure checks, audience and suppression review, inbox placement testing, provider-level monitoring and managed recovery planning. The right first step, however, is still the same: stop treating preflight as a final proofread and use it to decide whether the campaign is ready to earn another place in the inbox.