# Playbook: Deliverability Warmup

**Deliverable type this produces:** `deliverability-audit`
**Derives from:** applied email-engineering standards, not a single guru — the 2024 Gmail/Yahoo bulk-sender requirements, RFC 8058 (one-click unsubscribe), and standard ISP-reputation warm-up practice. This is Layer 0 of the manual's architecture (§3): the road every other playbook drives on. Ken McCarthy's measurement-conscience doctrine (§4.7 — "the click as the unit of measurement, test/track everything") is the philosophical ancestor of the instrumentation half of this playbook.
**Engine (the science):** Hard technical mechanics, not psychology — SPF authorizes sending servers via DNS, DKIM cryptographically signs mail against a DNS-published key, DMARC sets alignment policy. Effective February 2024, Gmail/Yahoo require all three for bulk senders (≥5,000 msgs/day), a hard spam-complaint ceiling of <0.3% (Google's target: <0.1%), and honored one-click unsubscribe within 2 days. A domain that has never sent must ramp volume gradually to build reputation — mailbox providers treat sudden high volume from an unknown sender as a spam signal regardless of content quality.

## When to use it

- Always first, for any domain that has never sent bulk commercial email — this is exactly 19Keys' situation (Resend + `outreach_worker`, armed but never fired).
- Before any other playbook in this directory is allowed to run its first send. Per the manual's build order (§6): "9 (warm-up) → 8 (segment) → 1 (welcome) → 2 (daily) → ... You cannot run 1-8 until 9 clears the CAN-SPAM/DMARC blockers."
- Periodically, as an audit — even a warmed domain should have its authentication and spam-rate status re-verified on a standing cadence, not just once at launch.

## When NOT to use it

- This playbook has no "wrong time" — it's a prerequisite, not a situational choice. The only wrong usage is skipping it or treating it as optional because "the copy is ready" (§8.2 #6 names this as *the* live risk for 19Keys specifically: sending before SPF/DKIM/DMARC + postal address + warm-up is the fastest way to permanently poison a domain).
- Don't run a full-volume send the moment authentication passes — warm-up is a ramp, not a switch. Treating "DNS records are published" as equivalent to "the domain is warm" is a common and costly mistake.

## The step-by-step build

1. **Publish SPF** on the sending domain — the DNS TXT record authorizing Resend's sending servers.
2. **Publish DKIM** — verify Resend's DKIM key is published and the signature validates.
3. **Publish DMARC** — at minimum `p=none` (monitoring mode) with at least one of SPF/DKIM aligned to the visible `From:` domain. `p=none` satisfies the 2024 Gmail/Yahoo requirement; stricter policies (`quarantine`/`reject`) can follow once confidence is established.
4. **Resolve the CAN-SPAM postal-address blocker** — obtain a real physical address, registered-agent address, or PO box and populate `OUTREACH_POSTAL_ADDR`. For 19Keys this is the literal, named, single unlock for the entire channel (§9.2) — file it as a P0 with `owner-action-chaser` if not already resolved; do not proceed past this step without it.
5. **Wire RFC 8058 one-click unsubscribe** — `List-Unsubscribe` + `List-Unsubscribe-Post` headers, honored within 2 days, plus a visible in-body unsubscribe link. Confirm Resend's support is correctly configured, not just theoretically available.
6. **Connect Google Postmaster Tools** to the sending domain — this is the dashboard that reports spam-complaint rate, domain reputation, and authentication pass percentage; nothing downstream can be measured without it connected.
7. **Build the warm-up ramp plan.** Since the domain has never sent: start with hundreds of messages/day to the most-engaged/most-recent segment (the Hot RFM bucket, per `rfm-segmented-sending`), and increase gradually — low thousands/day over weeks, not days. Document the specific ramp schedule (day-by-day or week-by-week volume targets) as part of the audit artifact.
8. **Seed-test before any real send.** Send to a small internal/seed list across major providers (Gmail, Yahoo, Outlook) and confirm inbox placement, not spam-folder placement, before ramping to real segments.
9. **Define the list-hygiene/sunset rule** that keeps the ramp from being undermined — e.g., "non-openers after N sends get suppressed from further ramp volume" — a warm-up that includes dead weight burns reputation faster.
10. **Monitor the spam-rate ceiling continuously** — <0.3% is the hard enforcement threshold where Google begins throttling/blocking; <0.1% is the recommended target, not the minimum bar to clear. Treat 0.3% as a red alarm, not a target to approach.
11. **Record each checklist item with an evidence line** — not just a checkbox, but what was actually verified and how (e.g., "SPF verified via `dig TXT` on [date], record matches Resend's published value").

## Worked mini-example (19Keys / Resend + outreach_worker)

| Item | Status | Evidence |
|---|---|---|
| SPF | `[todo]` | Not yet published — DNS TXT record for Resend not found on domain lookup as of audit date |
| DKIM | `[todo]` | Resend DKIM key generation pending domain verification |
| DMARC | `[todo]` | No DMARC record published; plan: publish `p=none` once SPF/DKIM confirmed |
| One-click unsubscribe (RFC 8058) | `[todo]` | Resend supports `List-Unsubscribe`; not yet wired into `outreach_worker` templates |
| CAN-SPAM postal address | `[failed]` | `OUTREACH_POSTAL_ADDR` env var confirmed empty — this is the P0 blocker filed with `owner-action-chaser` |
| Google Postmaster spam-rate reading | `[todo]` | Not yet connected — no domain history to report |
| List-hygiene / sunset rule | `[todo]` | Draft rule: suppress non-openers after 3 consecutive ramp sends |
| Warm-up plan (new domain) | `[todo]` | Draft ramp: week 1 ~200/day to Hot segment only, week 2 ~500/day, week 3 ~1,500/day, reassess spam-rate before scaling further |

## How the verify gate applies

Per §8.1 `deliverability-audit` rubric, checked for:
- Must verify and record **SPF present**, **DKIM aligned**, **DMARC policy stated**, **one-click unsubscribe (RFC 8058) status**, **Google Postmaster spam-rate reading (with the <0.3% threshold explicitly stated)**, a **list-hygiene rule (sunset policy defined)**, and a **warm-up plan if new domain.**
- **Each item must be marked `[verified|failed|todo]` with an evidence line** — an item with no evidence line fails the linter outright, even if the status marking itself looks correct. A checklist that just says "SPF: verified" with nothing else is not a passing artifact.
- This deliverable is the literal gatekeeper referenced in §5.5 ("the permission/law gate — veto power over all above"): if this audit shows any `[todo]` or `[failed]` on the postal-address, DMARC, or warm-up items, no other playbook in this directory is allowed to fire a real send, regardless of how well-built that other deliverable is.