You already did the DNS. Good.
This is what keeps you in the inbox after you start sending volume and the filters get mean. It is a weekly operating system. Agencies run it because they like paying rent. In-house SDR teams run it because pipeline dies fast when deliverability slips.
TL;DR
Run a weekly cold email deliverability checklist with 12 checks: inbox placement, seed tests, bounces by class, complaints, blocklists, list hygiene, content drift, link hygiene, throttling by domain, follow-up spacing, suppressions, and intent segmentation. Put it on a dashboard with thresholds and a kill switch. Your DNS records do not save you from bad ops.
Cold email deliverability in 2026: what changed (and what did not)
Deliverability is reputation plus behavior plus hygiene. The basics did not change.
What changed is enforcement and visibility:
- Spam complaint rates now have hard lines. Google explicitly says to keep spam rates in Postmaster Tools below 0.10% and avoid 0.30% or higher. (documentation.onesignal.com)
- Yahoo and Google bulk sender requirements pushed the ecosystem to treat complaints as a primary control metric, not a “marketing team KPI.” (emaillabs.io)
- Microsoft started rolling out stricter bulk sender requirements in 2025, which means Outlook is no longer the “wild west” inbox where anything goes. (inboxeagle.com)
So this guide is not “set up SPF.” This is the weekly system that stops the slow bleed.
The weekly deliverability operating system (SOP layout)
Run this every week. Same day. Same time. No exceptions.
Owner: Outbound Ops (agency: deliverability lead, in-house: RevOps or SDR ops)
Cadence: Weekly, plus daily automated alerts for kill switch triggers
Inputs: ESP logs, Postmaster Tools, seed test results, bounce logs, blocklist checks, CRM outcomes
Outputs:
- “Green / Yellow / Red” status by mailbox provider (Google, Microsoft, Yahoo, Others)
- Actions list with owners and deadlines
- Updated suppressions and routing rules
Tools you will use (minimum viable stack)
- Google Postmaster Tools (Gmail reputation and user-reported spam rate) (socketlabs.com)
- Seed testing (inbox placement tests across providers)
- Bounce parsing (you need SMTP codes and enhanced status codes)
- Blocklist monitoring (Spamhaus and friends)
- A suppression list mechanism that works across all sending domains
The 12-point cold email deliverability checklist teams run weekly
This is the checklist. Copy it into a Notion page. Then actually run it.
1) Inbox placement monitoring (by provider, not “overall”)
Goal: Know where messages land. Not whether they were “sent.”
What to track weekly
- Inbox vs Promotions vs Spam placement split (seed test + manual sampling)
- Placement by provider:
- Gmail and Google Workspace
- Microsoft (Outlook, Hotmail, M365)
- Yahoo/AOL
Thresholds
- Green: 85%+ inbox (seed) at top 2 providers
- Yellow: 70%-85% inbox or sudden Promotions shift
- Red: <70% inbox or any provider hits “all spam” behavior
Actions
- Yellow: throttle, tighten list hygiene, reduce links, increase intent segmentation
- Red: trigger kill switch (see point #10)
Why this matters: Gmail reputation is domain-driven and trend-based. Postmaster is laggy. Seed tests show the present.
2) Seed testing (control group you trust)
Seed tests are your canary. Done wrong, they lie.
Weekly SOP
- Maintain a stable seed list across Gmail, Outlook, Yahoo, plus a few corporate domains (Proofpoint and Microsoft Defender environments if you can).
- Send 2-3 standardized test emails:
- Plain text
- Light personalization variant
- Your most common campaign template variant
- Record placement and any header anomalies.
Rules
- Do not change the seed list every week. Consistency beats novelty.
- Seeds do not predict every inbox. They detect drift and sudden filtering shifts.
3) Bounce classification (hard vs soft, then root cause)
Most teams watch “bounce rate.” That is toddler math.
You need bounce classes so you can fix the right thing.
Use enhanced status codes
- 5.X.X = permanent failure (hard bounce)
- 4.X.X = temporary failure (soft bounce) RFC 3463 defines the structure and meaning of these codes. (datatracker.ietf.org)
Weekly dashboard cut
- Invalid mailbox (5.1.1)
- Domain not found (5.1.2)
- Policy / spam related blocks (often 5.7.x)
- Rate limits / throttling (often 4.2.x)
- Mailbox full (4.2.2)
Thresholds
- Hard bounces: keep under 1%. Treat 2% as a stop-and-fix signal.
- Policy blocks (5.7.x): any spike is urgent. That is reputation or content.
Actions
- High invalid mailbox: list hygiene failure (point #6)
- High 5.7.x: content, links, reputation, or sending pattern (points #7-#9)
4) Spam complaint signal tracking (the metric that ends you)
Spam complaints are the loudest “no.” Google’s guidance is blunt.
- Keep Postmaster Tools spam rate below 0.10%.
- Avoid 0.30% or higher. (documentation.onesignal.com)
Weekly SOP
- Pull Gmail Postmaster Tools:
- User-reported spam rate
- Domain reputation trend
- Pull Yahoo complaint signals if you have access via your tooling or feedback loops.
- Compare complaint spikes to:
- List source
- Segment
- Message template
- Offer
Thresholds (practical ops)
- Green: <0.08%
- Yellow: 0.08%-0.10% (you are flirting with pain)
- Red: 0.10%-0.30% (you are actively burning)
- Nuclear: ≥0.30% (you are done, fix before sending more) (documentation.onesignal.com)
Actions
- Spike tied to one segment: isolate, suppress, rewrite, slow down
- Spike across everything: throttle by provider, cut volume, rotate message pattern, tighten intent
5) Blocklist monitoring (Spamhaus and “invisible” reputation hits)
You do not need to be “a spammer” to get listed. You just need to look like one.
Spamhaus listings can cause major delivery problems depending on the list and receiver behavior. (suped.com)
Weekly SOP
- Check domains and sending IPs across:
- Spamhaus (SBL/XBL/DBL depending on what you run)
- Common RBL aggregators (MultiRBL, MXToolbox style checks)
- Log listings with:
- Date detected
- Affected domains
- Likely trigger campaign
Thresholds
- Any new listing = incident
- Repeated listings = infrastructure and list sourcing problem, not “bad luck”
Actions
- Pause the affected domain(s)
- Identify the trigger (list batch, template, redirect chain, or volume jump)
- Delist if appropriate, then reintroduce volume slowly
6) List hygiene rules (weekly scrubs, not monthly “cleaning”)
List hygiene is not a one-time enrichment step. It is ongoing damage control.
Weekly SOP
- Remove all hard bounces from future sends immediately
- Suppress:
- Role accounts (info@, support@) unless your model truly needs them
- Known complainers (from feedback loops where available)
- Prior “do not contact” requests
- Re-verify stale leads:
- If last verified > 30 days ago, re-verify before sending
- Watch catch-all domains:
- High catch-all density often correlates with higher bounce volatility
Thresholds
- Invalid rate trending up week-over-week = list sourcing issue
- Hard bounce clustering by a single data vendor = stop using that source
Action
- Tighten your ICP inputs.
- Stop buying dead databases and calling it “pipeline.”
If you want “why,” it is simple: Gmail and others treat repeated invalid sends as a reputation signal.
7) Content drift control (your templates rot)
Cold email content drifts. Fast.
You start with clean copy. Then:
- SDRs add links.
- Someone adds tracking.
- Someone pastes a fancy signature.
- Suddenly every email looks like a phishing attempt.
Weekly SOP
- Pick your top 3 live templates.
- Compare this week vs last week:
- Word count
- Link count
- Image count (should be zero for cold)
- “Spammy” term density (free, guarantee, act now, etc.)
- Force a controlled template library. No “creative freedom” in outbound infrastructure.
Thresholds
- Any template crosses 2 links = yellow
- Any template adds images = red for cold outbound
- Sudden similarity across thousands of sends = risk (filters cluster patterns)
Actions
- Rotate phrasing, structure, and opening lines weekly.
- Keep the core offer stable, change the wrapper.
For personalization, use proof-based patterns that do not scream “LLM wrote this.” Link this internally: proof-based personalization patterns for cold email.
8) Link and redirect hygiene (the silent deliverability killer)
Deliverability dies in the click path.
Weekly SOP
- Audit every URL in live sequences:
- Is it a redirect?
- Does it chain multiple redirects?
- Does it land on a domain with bad reputation?
- Keep links minimal:
- Prefer zero links in first email when volume is high
- If you must use one, use a clean, consistent domain and avoid sketchy shorteners
Thresholds
- Redirect chain length > 1 = fix it
- Multiple unique tracking domains across templates = risk spike
Actions
- Replace with plain-text CTAs
- Move “assets” to later steps or post-reply
9) Throttling by domain and provider (you cannot brute force Gmail)
Mailbox providers behave differently. Treat them differently.
Weekly SOP
- Segment sending volume by provider:
- Gmail: strict on complaint rate and behavior signals
- Yahoo: can be volatile, complaint thresholds matter
- Microsoft: increasingly strict, tends to throttle and filter based on different patterns (inboxeagle.com)
- Apply throttles:
- Per sending domain
- Per target provider domain group
Simple rules that work
- If Gmail placement slips, cut Gmail volume first.
- Keep Microsoft steady. Do not spike it.
- Do not ramp multiple domains at the same time.
Actions
- Create per-provider queues
- Use lower daily caps during “yellow” status
10) Follow-up spacing rules (stop machine-gunning inboxes)
Follow-ups are good. Rapid follow-ups to people who never asked for you are not “relentless.” They are a complaint generator.
Weekly SOP
- Review follow-up cadence for top sequences:
- Days between touches
- Total touches before stop
- Review per-segment outcomes:
- Replies
- Bounces
- Complaints
- Spam placement
Thresholds
- Complaint rate rises after follow-up #3? Cap it at 3.
- Reply rate drops while volume stays constant? You are hitting lower intent and generating negative signals.
Actions
- Increase spacing.
- Reduce total touches for colder segments.
- Reserve higher touch counts for high intent segments.
11) “Kill switch” thresholds (write them down, then obey them)
This is where teams pretend they are disciplined and then keep sending anyway.
Build an explicit kill switch.
Kill switch triggers (pick yours, here’s a strong default)
- Gmail Postmaster spam rate ≥ 0.30% any day this week (stop sending from that domain) (documentation.onesignal.com)
- Seed inbox placement drops below 60% at Gmail or Yahoo (pause, investigate)
- Policy bounces (5.7.x) spike 2x week-over-week (throttle hard)
- New Spamhaus listing for sending domain or primary redirect domain (pause) (suped.com)
Kill switch actions
- Pause campaigns on affected domain(s)
- Freeze template edits
- Pull last 7 days of segments and list sources
- Remove risky links and tracking
- Resume with reduced volume and stricter segmentation
12) Suppression lists and intent segmentation (send less, book more)
Deliverability improves when your audience actually wants the email. Shocking.
Weekly SOP
- Update global suppressions:
- Hard bounces
- Unsubscribes
- Do-not-contact
- Known complainers
- Segment by intent and fit:
- High fit + high intent
- High fit + low intent
- Low fit (do not send, or send only if intent spikes)
This is where Chronic’s scoring approach matters. Use dual fit + intent scoring and route volume to the safest, highest-return segments. Link this: AI lead scoring.
Actions
- Push high intent first.
- Slow down or stop low intent when reputation softens.
- Use enrichment to avoid missing signals (tech stack, hiring, funding, job posts). Link: lead enrichment.
SOP: weekly deliverability review (copy/paste)
Run this as a checklist.
Step 0: Pull the data (15 minutes)
- Gmail Postmaster Tools: spam rate, domain reputation, delivery errors (documentation.onesignal.com)
- ESP logs: bounces with SMTP and enhanced status codes
- Seed test results: placement by provider
- Blocklist scan results (Spamhaus etc.) (suped.com)
- Campaign stats: sends, replies, positive replies, unsubscribes
Step 1: Assign status by provider (10 minutes)
For each: Gmail, Microsoft, Yahoo:
- Green / Yellow / Red
- Primary reason (complaints, bounces, blocks, placement)
Step 2: Run kill switch check (5 minutes)
If any trigger hits, pause first. Diagnose second.
Step 3: Identify the culprit segment (20 minutes)
Cut by:
- List source
- Campaign
- Template
- Persona
- Industry
- Target provider
Pick the smallest cut that explains most of the damage. Then suppress it.
Step 4: Apply fixes (30-60 minutes)
- Hygiene: scrub bounces, suppress complainers, re-verify stale
- Content: reduce links, simplify formatting, rotate opening lines
- Volume: throttle by provider, reduce daily caps
- Segmentation: route volume to higher intent
Step 5: Document and ship (10 minutes)
Log:
- What changed
- What you paused
- What you will test next week
Dashboard template outline (metrics, thresholds, actions)
Build this in a spreadsheet, Notion, Looker, whatever. Just make it visible.
Section A: Global health (weekly)
- Total sends
- Total replies
- Positive reply rate
- Hard bounce rate
- Soft bounce rate
- Unsubscribe rate
- Complaint rate (Gmail Postmaster spam rate) (documentation.onesignal.com)
- Seed inbox placement %
Action column: auto-populated with rules:
- If hard bounce > 1% - re-verify last import, suppress bad domains
- If spam rate > 0.10% - reduce volume, tighten targeting (documentation.onesignal.com)
- If spam rate ≥ 0.30% - kill switch (documentation.onesignal.com)
Section B: Provider breakdown
For Gmail, Microsoft, Yahoo:
- Seed inbox placement %
- Policy bounce rate (5.7.x share)
- Throttling signals (4.2.x share)
- Status: Green/Yellow/Red
- Volume cap for next week
Section C: Template risk
For each active template:
- Links count
- Redirect chain length
- Similarity score (basic: how many identical lines across templates)
- Placement impact (seed)
- Decision: keep, revise, pause
Section D: Segment risk
For each segment:
- Source (vendor, scrape, inbound list, event list)
- Intent tier
- Bounce rate
- Complaint rate proxy (unsub + negative replies + placement drop)
- Decision: scale, hold, suppress
Where Chronic fits (without the SaaS fluff)
Ops wins when the stack is coherent.
Chronic runs outbound end-to-end till the meeting is booked. The deliverability checklist still matters, but execution gets cleaner when:
- ICP stays tight: ICP Builder
- Enrichment stays fresh: Lead Enrichment
- Scoring routes volume to safer segments: AI Lead Scoring
- Copy stays controlled and personalized: AI Email Writer
- Outcomes tie back to pipeline, not vanity metrics: Sales Pipeline
If you are duct-taping Apollo, Instantly, Clay, and a CRM, you can still run this SOP. You just do more manual work and you miss signals. That is the trade.
(If you want the direct comparison pages: Chronic vs Apollo, Chronic vs HubSpot, Chronic vs Salesforce.)
Common failure patterns when volume rises (and filters tighten)
Pattern 1: “We scaled volume, then Gmail died”
Cause: complaint rate drift plus low intent lists. Gmail draws a hard line. (documentation.onesignal.com)
Fix: throttle Gmail, re-segment by intent, simplify content, kill switch early.
Pattern 2: “Bounces climbed, then everything got worse”
Cause: invalids and policy bounces feeding reputation decay. Fix: weekly re-verification, bounce-class routing, stop sending to risky domains.
Pattern 3: “We added tracking and links, then placement tanked”
Cause: link reputation, redirect chains, template fingerprinting. Fix: link hygiene, reduce links, move assets later.
FAQ
What is a cold email deliverability checklist?
A cold email deliverability checklist is a recurring ops routine that tracks inbox placement, complaints, bounces, list hygiene, content risk, and sending patterns. It prevents reputation decay when outbound volume increases.
What spam complaint rate is “safe” in 2026?
For Gmail, aim for below 0.10% and avoid 0.30% or higher, based on Google’s guidance tied to Postmaster Tools spam rates. (documentation.onesignal.com)
Why does Postmaster Tools show higher spam rates than my ESP?
Gmail does not provide per-recipient spam complaint feedback to most ESPs. Postmaster Tools reports Gmail-specific user-reported spam rates, which can appear “delayed” because complaints arrive after the send. (socketlabs.com)
What bounce codes matter most for outbound?
Track enhanced status codes. Hard bounces (5.X.X) indicate permanent failures. Soft bounces (4.X.X) indicate temporary failures. RFC 3463 defines the classes and structure, which makes weekly classification consistent. (datatracker.ietf.org)
Should we pause sending if we hit a blocklist?
Yes. A Spamhaus listing often correlates with immediate deliverability problems, depending on the list and mailbox provider. Treat new listings as an incident, pause, diagnose, then reintroduce volume slowly. (suped.com)
How do agencies keep deliverability stable while increasing volume?
They segment by intent, throttle by provider, run weekly bounce and complaint audits, keep templates controlled, and enforce kill switch thresholds. Volume goes to high fit + high intent first. Low intent gets cut the second signals soften.
Run the checklist. Ship the fixes. Keep the inbox.
Put the dashboard somewhere visible. Assign an owner. Write the kill switch rules in plain English.
Then do the boring part weekly. That is the job.
If you want the DNS and authentication piece that teams still mess up, pair this with: Cold Email Deliverability in 2026: The Authentication Setup Most Teams Still Get Wrong (SPF, DKIM, DMARC, Alignment).