Newsletter Deliverability Checklist 2026

The 2026 newsletter deliverability checklist: authentication, list hygiene, bounce control. Everything between you and the inbox.

The Newsletter Deliverability Checklist (2026): Everything Between You and the Inbox

Every deliverability guide starts with SPF/DKIM/DMARC and stops there, as if authentication were the whole game. It isn't. Authentication gets you through the door. What keeps you in the inbox is everything else — list quality, sending cadence, engagement signals, and the one thing nobody warns you about until it's too late: stale lists kill accounts.

This is one of the most reported failure patterns in newsletter deliverability: a 5,000-subscriber list, a sending pause of a few weeks, then a single send to the same list. The stale addresses bounce. Amazon SES sees the bounce spike and shuts the account down. The appeal is denied. A small four-figure-a-month income stream, gone — because of addresses that were collected honestly and then let rot.

This checklist is the whole system, in order. Work it top to bottom and your deliverability is defensible. Skip the middle and SPF won't save you.


1. Authentication (the baseline — non-negotiable)

  • [ ] SPF record published for every sending domain, with all senders included
  • [ ] DKIM signing with 2048-bit keys, aligned to the From domain
  • [ ] DMARC at least p=quarantine with reporting to an address you actually read
  • [ ] No "via amazonses.com" or "via sendgrid.net" in the From line (custom MAIL FROM configured)

If you're not here yet, stop and fix this before anything else. But don't stop here either — this is the part every guide covers, and it's the part that matters least once you have it.

2. List hygiene (the part that actually kills accounts)

This is where most deliverability deaths actually happen.

  • [ ] List pruned of chronic non-openers — addresses that haven't opened in 6+ months are dead weight that poisons engagement metrics
  • [ ] Stale addresses re-verified before any resumed sending — if you paused for weeks or months, treat the whole list as suspect, not just the addresses that look bad
  • [ ] Syntax + MX validation run on every new intake — bad addresses should never enter the database
  • [ ] Role addresses and disposable domains flagged or removed (info@, admin@, temp-mail services)
  • [ ] Bounce history honored — any address that ever hard-bounced is suppressed, permanently, across all sends
  • [ ] Full list exportable on demand — if you can't get your list OUT of the platform in one click, you're a hostage, not a customer

The math that matters: SES starts warning around 5% bounce rate and pauses around 10%. On a 5,000-subscriber list, that's 250 stale addresses — an entirely normal accumulation over a few quiet months. One send is all it takes.

3. Sending infrastructure

  • [ ] Dedicated IP or warmed shared pool — know which you're on and what its reputation is
  • [ ] Warmup schedule after any pause or new IP — ramp volume over 2–4 weeks, never blast a cold list
  • [ ] Bounce/complaint handling automated — bounces must trigger suppression in minutes, not when someone remembers to check
  • [ ] Complaint rate under 0.1% (this is stricter than the bounce math, and mailbox providers watch it)
  • [ ] List-unsubscribe headers present (Gmail/Apple increasingly penalize mail without one-click unsubscribe)

4. Content and engagement

  • [ ] Consistent sending cadence — erratic senders look like compromised accounts; weekly beats monthly
  • [ ] Subject lines that match the content — misleading subjects earn spam complaints, which are worse than bounces
  • [ ] Plain-text part included — some filters still weigh it
  • [ ] Image-to-text ratio sane — one giant image with no text is the classic spam fingerprint
  • [ ] Engagement segmented — your most engaged subscribers should get mail first; warming the reputation before the long tail sees anything

5. Monitoring (the ongoing part)

  • [ ] Postmaster tools registered — Google Postmaster Tools and Microsoft SNDS at minimum
  • [ ] DMARC reports actually reviewed (monthly at least)
  • [ ] Bounce and complaint rates trended, not just spot-checked — a slow climb is the early warning
  • [ ] Seed-list testing before important campaigns — send to a test panel first, check where it lands

6. The exit plan (the checklist item nobody writes)

  • [ ] You can leave. Full export, portable addresses, no contractual lock-in, no platform that owns the unsubscribe event.

Every item above assumes your sending platform is a service you use. But if the platform itself disappears — account suspended, appeal denied — the whole checklist becomes moot. So the final item is the one that protects all the others: own the rails. Export the list. Keep it clean on infrastructure you control. Rent as little as possible of the path between you and your readers.

That's the architecture the rest of this site is about. The checklist gets you compliant; ownership makes you unkillable.


The 10-minute version

Don't have time for the full list? Do these three, today:

  1. Export your list right now — verify the export actually works before you ever need it.
  2. Suppress every address that hard-bounced on your last three sends — they're pure risk with zero upside.
  3. Set DMARC reporting to an address you'll read — free early warning.

Then work the full checklist this month.


Want the version that does the work for you? Run a free ListProof self-audit checklist against your list — every address classified deliverable / risky / disposable / invalid, with a stated bounce prediction for the safe segment. If the safe segment bounces above the prediction on your first send, we re-run the analysis free. [Run the free checklist →]

Keep Exploring

Use the Workflow Library to browse more guides, comparisons, and integration examples to continue your evaluation.

Keep reading

If this one helped, the next two are the natural follow-ups.