Use this technical launch gate for one campaign and every platform sending it. The output is a dated go/no-go record with evidence, an owner, and a next action. For ongoing client handover, use the separate client domain-health checklist.
1. Identify the actual sending path
- ☐ Record the campaign, scheduled send, visible From address, email platform, and person approving launch.
- ☐ List every sending stream involved, including automated follow-ups and transactional messages.
- ☐ Send a test through the real platform to a mailbox where you can inspect the original message. A test from your personal mailbox does not validate the campaign platform.
2. Check SPF authorization and lookup budget
dig +short TXT example.com
# Windows alternative:
nslookup -type=TXT example.com
- ☐ Check the domain actually used for the envelope sender/Return-Path; it may differ from the visible From domain.
- ☐ Confirm one SPF policy beginning
v=spf1 at that name. Other unrelated TXT records are normal.
- ☐ Confirm the platform's documented authorization is present. Do not paste a second SPF policy beside an existing one.
- ☐ Check the 10 DNS-lookup limit across the full SPF evaluation path, including nested includes. The terms that count are
include, a, mx, ptr, exists, and redirect. Counting only visible includes is insufficient; ip4, ip6, and all do not consume that budget.
- ☐ Check void lookups separately. These are DNS queries that return no records or an NXDOMAIN response. RFC 7208 §4.6.4 says implementations should limit them to two during one SPF evaluation; exceeding the receiver's limit can produce a permanent error.
3. Verify DKIM on a real message
- ☐ Read
d= (signing domain) and s= (selector) from the test message's DKIM-Signature header.
- ☐ Query the selector at that signing domain. Substitute your actual values in the example below.
- ☐ Confirm the receiving mailbox reports a DKIM pass. A published key alone does not prove the platform is signing correctly.
dig +short TXT s1._domainkey.example.com
dig +short TXT _dmarc.example.com
4. Confirm DMARC alignment
- ☐ Compare the visible From domain to the SPF-authenticated domain and the DKIM signing domain.
- ☐ Confirm at least one passing method also aligns. An SPF pass for an unrelated vendor domain is insufficient by itself.
- ☐ Record the DMARC policy.
p=none requests observation without DMARC-specific enforcement; it is not an authentication failure.
- ☐ If authentication or alignment fails unexpectedly, hold the affected sending stream and fix it. Do not weaken policy across the domain merely to rush a launch.
5. Sign off and retain evidence
- ☐ Confirm the audience has an appropriate basis for receiving the mail, suppression lists are applied, and unsubscribe works.
- ☐ Review the relevant mailbox providers' current sender requirements for this traffic.
- ☐ Save the test timestamp, platform, redacted headers, DNS results, unresolved issues, and approver. Recheck after any sender or DNS change.
The Beacon free check can help establish the public-DNS baseline. It does not replace message testing or guarantee delivery. Technical references: RFC 7208 and RFC 7489.