/deliverability-incident-response

name: deliverability-incident-response
description: Triage playbook for when cold email deliverability breaks. Decision-tree guidance for "I landed in spam", "bounce rate spiked", "domain blacklisted", "inbox blocked in warmup", "reply rate dropped". Tells you what to check first, what to fix, and how long the fix takes. Pair with /email-deliverability-audit for diagnosis.

Deliverability Incident Response

Things break. When they do, you need a playbook — not panic. This skill is the triage decision tree.

The five incident types

| Symptom | Most likely cause | First action | Fix time | |---|---|---|---| | Reply rate dropped sharply | Deliverability — emails in spam | Run spam placement test | 1-14 days | | Bounce rate spiked >3% | Bad list OR domain reputation | Check bounce types | 1-3 days | | Domain blacklisted | Shared IP bad actor OR your domain got flagged | Check blacklists, rotate if needed | 7-30 days | | Inbox blocked in warmup | Warmup network flagged sending patterns | Pause, investigate, maybe replace | 1-7 days | | Gmail marking as promotional | Content triggers (links, images, HTML) | Simplify content | 1-3 days |

Decision tree: "my reply rate dropped"

Step 1: Quantify the drop

Was this week's reply rate < 50% of last 4 weeks' average?
  Yes → real drop, continue triage
  No  → noise, wait another week

If drop is real:

Step 2: Is it campaign-specific or fleet-wide?

Are ALL campaigns dropping, or just one?
  All → fleet-level issue (infrastructure or copy pattern)
  One → campaign-specific (targeting, copy, list)

Step 3: Fleet-wide drop — check these in order

1. **Smartlead Smart Delivery spam test** (`/email-deliverability-audit` → `run-spam-test.ts`)

• If inbox placement <70% → real deliverability issue, skip to Step 4
• If inbox placement >85% → deliverability is fine, look at copy/targeting instead

2. **Check domain authentication** (`/email-deliverability-audit` → `check-domain-auth.ts`)

• Missing DKIM on any domain → fix immediately (see `/zapmail-domain-setup-public` for reconnect steps)
• DMARC policy=reject with alignment failures → temporarily lower to quarantine

3. **Check warmup status** (`/smartlead-inbox-manager` → `list-health.ts`)

• If multiple inboxes blocked in warmup → warmup network flagged you
• If reputation dropped "good" → "fair" on many inboxes → slow down sending volume

4. **Check bounce rate** (`/email-deliverability-audit` → `audit-performance.ts`)

• If bounce >3% → list quality degraded
• If bounce <1% but reply rate low → emails landing in spam (Step 1 result)

Step 4: You have a spam-placement problem — what to do

Time-ordered actions:

1. **Immediate (today):** Pause the highest-volume campaign. Stop damage. 2. **Day 1:** Run spam placement test on 2-3 sender subsets (tag=active vs tag=new). Find which cohort is worst. 3. **Day 1:** Check the spam-filter-details report from Smart Delivery — specifically which filters are firing. Common: `DKIM_INVALID`, `HTML_MESSAGE`, `LINK_REDIRECT`. Each has a specific fix. 4. **Day 2:** Fix the identified issues:

• DKIM_INVALID → verify DKIM records across all domains, re-publish if needed
• HTML_MESSAGE → simplify email body (fewer fonts, no inline CSS, no tracking pixels)
• LINK_REDIRECT → remove or reduce links in email 1 (ideally 0 links)

5. **Day 3-14:** Slow down send volume. Cut daily send per inbox by 50% for a week. Reputation rebuilds slowly. 6. **Day 14:** Re-test spam placement. If back above 85% → resume normal volume.

Decision tree: "bounce rate spiked"

Step 0: Do you have enough bounces to read?

**50 sends** before a bounce *rate* means anything. Below that, one dead address reads as 2% and two read as 4% — straight through the 3% line. **30 classified bounces attributed to that specific sending domain** before the bounce *composition* means anything. A domain with no sampled bounces has a 0% sender-originated share purely by construction, which looks exactly like a rotten list — and that is how an unmeasured domain gets a confident "go revalidate your list" verdict.

Step 1: Classify the bounces by SMTP code, not by hard/soft

Hard-vs-soft is too coarse to act on. The **enhanced SMTP status code** in the bounce DSN tells you whose fault it is. Pull the DSN from the bounced lead's message history and take the **first** `[45].\d+.\d+` code in the body — DSN templates repeat the code and often quote unrelated examples further down in the "more info for admins" boilerplate.

| Bucket | Codes | Reading | Action | |---|---|---|---| | **LIST** | `5.1.1`, `5.1.10`, `5.1.0`, `5.2.1`, `5.4.1`, `5.5.0` | The mailbox does not exist. | Revalidate the list. Keep verified-valid only; a catch-all result is a *not found*, not a pass. | | **SENDER (auth)** | `5.7.1`, `5.7.0`, `5.7.23`, `5.7.26`, `5.7.509`, `5.7.520` | We were refused on policy or authentication. | Fix SPF/DKIM/DMARC first, re-check in 7 days. **Fixable — do not replace the domain.** | | **BURNED** | `5.7.606`-`5.7.614`, or DSN text naming a blocklist/Spamhaus | The recipient world has specifically banned this sender. | `/inbox-lifecycle-manager` as a cancel candidate. DNS fixes will not help. | | **THROTTLE** | any `4.x.x` — `4.7.x`, `4.4.2`, `4.4.7`, `4.2.2` | Temporary. Greylisting or rate limiting. | Cut daily volume per inbox by 50% for a week. **Never cancel a domain on 4.x codes.** | | **NOISE** | `5.2.2` (mailbox full), `5.3.4` (too large), `5.7.133` (restricted distribution group) | Recipient-side configuration. Not a reputation signal. | Count them so the denominator is honest, then exclude them from every share calculation. |

⛔ **`5.7.133` is noise, full stop.** It means "the group only accepts messages from inside its organization" — someone else's distribution-list setting. It is frequently the single most common code in a real sample, and bucketing it as a sender problem will manufacture "burned domain" cancel candidate