Careers
Part of The honest guide to email deliverability
Working through the email deliverability checklist in order
Email deliverability checklist covers sender ownership, recipients, authentication, transmission, unsubscribe, suppression, traffic, monitoring, and incidents.
What to take away
- Mark each item pass, fail, unknown, or not applicable with evidence, owner, correction, and review date.
- Do not launch while sender identity, audience source, suppression, or rollback remains materially unknown.
- Repeat the checklist after changes to providers, domains, DNS, volume, acquisition, content, tracking, or market scope.
An email deliverability checklist should make the sending system explainable and testable. Mark each item pass, fail, unknown, or not applicable. Record evidence, provider scope, owner, corrective action, accepted risk, and review date. Recheck current provider and legal requirements.
Work these steps in order.
Step 1: Sender inventory and ownership
Sender inventory and ownership
- 1.1 Every domain, From address, return path, DKIM domain, IP, provider, stream, vendor, volume, market, and list source is inventoried.
- 1.2 Business, technical, data, content, security, requirement, vendor, and incident responsibilities have named owners.
- 1.3 New senders require approval; obsolete infrastructure, credentials, DNS, and data have retirement procedures.
- 1.4 Pass testExport the provider sender list and match it to DNS records; pass when every sending domain has a named owner.
Step 2: Recipients and purpose
- 2.1 Permission or other basis, signup language, source, date, topics, sender, frequency, market, and proof are documented.
- 2.2 Purchased, harvested, appended, deceptive, and unexplained data is blocked from promotional sending.
- 2.3 Security, receipt, account, service, marketing, sales, support, and user-generated streams have clear classifications.
- 2.4 Pass testTrace a signup source to date, language, and market; pass when no purchased list is present.
Step 3: Authentication and transmission
IETF SMTP TLS reporting standard RFC 8460 defines reports for failures involving SMTP TLS, routing, DNS, MTA-STS, and DANE. If the applicable systems support it, include ownership, destination, privacy, alerting, and response tests for TLS reports rather than treating encryption as an unchecked box.
IETF RFC 8689 on REQUIRETLS defines an SMTP option through which a message can require TLS and certificate validation during onward relay. It is a scoped transport mechanism with deployment limits, so verify support and failure behavior before using it for sensitive streams.
Authentication and Transmission
- SPF authorizes current systems only
- DKIM signatures work on production paths
- DMARC alignment, reporting, policy staged
- Forward and reverse DNS pass checks
- TLS, routing, time, headers, format pass
- Include RFC 8460 TLS report tests
Authentication and transmission
- 3.1 SPF, DKIM, DMARC, MTA-STS, DANE, TLS, and DNSSEC settings are documented for every sending domain.
- 3.2 Alignment, subdomain policy, reporting addresses, key rotation, and failure behavior are tested across providers.
- 3.3 Pass testCount SPF DNS lookups; pass at 10 or fewer. Check DKIM d= alignment; pass when it matches From.
Step 4: Unsubscribe and suppression
- 4.1 Required List-Unsubscribe mechanics and visible body links work for the provider and message scope.
- 4.2 Withdrawal, complaints, hard failures, invalid addresses, preferences, and exclusions propagate across platforms and queues.
- 4.3 Imports, migrations, backups, and restored automations cannot reactivate suppressed promotion.
- 4.4 US FTC CAN-SPAM requires a clear opt-out, honored within 10 business days, with no fee and no extra personal information beyond an email address. Canadian CASL requires consent and an unsubscribe mechanism in every commercial electronic message, honored within 10 days and valid for 60 days. Suppression must block future promotional sends in both markets.
- 4.5 Pass testInspect headers for List-Unsubscribe and List-Unsubscribe-Post; pass when one-click unsubscribe removes the address from suppression.
Step 5: Traffic, content, and infrastructure
Traffic, content, and infrastructure
- 5.1 Critical streams are protected from avoidable promotional risk without creating unowned fragments.
- 5.2 Volume changes, migrations, domains, IPs, templates, headers, links, tracking, and vendors use phased release.
- 5.3 Sender identity, subjects, content, links, reply paths, accessibility, and destinations are accurate and recognizable.
- 5.4 Infrastructure contracts cover logs, queues, suppression, security, incidents, portability, retention, deletion, and exit.
- 5.5 Pass testRun a Litmus or Email on Acid check; pass when links, sender, and tracking match the intended stream.
Step 6: Monitoring and incidents
Monitoring and incidents
- 6.1 SMTP responses, acceptance, deferral, rejection, bounce, complaints, authentication, and provider dashboards use defined denominators.
- 6.2 Alerts detect volume anomalies, missing signatures, suppression failures, compromised credentials, queue growth, and provider shifts.
- 6.3 Runbooks cover pause, evidence preservation, recipient scope, correction, vendor coordination, phased restart, and post-incident review.
- 6.4 Pass testIn Google Postmaster Tools, keep spam rate under 0.10%; fail at 0.30% or higher. In AWS SES, keep bounce under 5% and complaint under 0.1%.
Step 7: Checklist decision record
Checklist decision record
| Status | Meaning | Action |
|---|---|---|
| Pass | Current evidence supports control | Record and review |
| Fail | Control does not work | Correct before exposure |
| Unknown | Evidence is missing | Assign investigation |
| N/A | Outside verified scope | Record rationale |
Sample evidence record:
Checklist decision record
| Item | Owner | Date | Artifact | Correction | Review |
|---|---|---|---|---|---|
| 3.2 DKIM alignment | Deliverability lead | 2025-06-01 | DNS TXT for selector s1 matches From example.com | None | 2025-09-01 |
Pass test: Check each row for status, owner, date, artifact, correction, and review date; fail when a high-consequence item is unknown.
Step 8: Privacy and acquisition checks
The W3C Privacy Principles statement gives web-system designers shared privacy concepts and warns against shifting privacy work to individuals. Map it to item 2.1: consent and data handling need owner, evidence, and review date.
Privacy concepts from the W3C also shape how senders answer common questions about consent and data handling, which is where email deliverability questions get practical.
The CISA software acquisition fact sheet covers development practice, supply-chain exposure, deployment, and vulnerability management. Map it to item 5.4: infrastructure contracts need owner, evidence, and review date.
Pass test: Check that item 2.1 and item 5.4 cite the source, name an owner, and set a review date.
Common questions
Who should own the checklist?
One accountable program owner should coordinate audience, domain, security, infrastructure, legal, service, analytics, and vendor owners without absorbing their specialist decisions.
Is a passed checklist permanent?
No. Providers, systems, domains, data, requirements, threats, and customer expectations change. Review on a risk-based schedule and after material change.
What should block launch?
Block when a material audience, identity, suppression, security, transmission, rollback, monitoring, or incident-response control is failed or unknown.
