--- name: protecting-email-deliverability description: >- Configures and monitors outbound sending infrastructure against bulk-sender requirements — SPF, DKIM, DMARC, PTR, TLS, one-click unsubscribe, spam-rate ceilings, warmup and volume ramp — and diagnoses deliverability failures from SMTP error codes and Postmaster Tools reputation data. Use when the user says emails going to spam, deliverability, SPF DKIM DMARC, DMARC failing, spam rate, Postmaster Tools, domain reputation, bulk sender requirements, one-click unsubscribe, List-Unsubscribe header, domain warmup, inbox rotation, 5.7.26, 4.7.28, 550 5.7.1, blocklisted domain, or asks why open and reply rates collapsed after a volume increase. Use this skill whenever the problem is whether mail arrives, even if the user frames it as a copy or list problem. Do NOT use for cadence and message design (see designing-outbound-sequences), for list construction and enrichment (see building-icp-and-target-lists), or for signal routing and SLAs (see running-signal-based-plays). metadata: version: "1.0" --- # Protecting email deliverability Configure the sending domain and IP so outbound mail is authenticated and accepted, monitor the spam-rate and reputation signals that govern acceptance, and diagnose specific delivery failures. One job: whether mail arrives. Message copy, cadence, and account selection are out of scope. Treat the Gmail sender guidelines as the binding constraint set; large providers including Google, AOL, and Yahoo typically follow these guidelines ([Google](https://support.google.com/a/answer/81126)). Configure once to the strictest requirement rather than per mailbox provider. ## Workflow Copy this checklist into your reply and tick items as you complete them: ``` - [ ] 1. Establish sending volume tier and mailbox inventory - [ ] 2. Verify authentication: SPF, DKIM, DMARC, TLS - [ ] 3. Verify forward and reverse DNS on the sending IP - [ ] 4. Implement one-click unsubscribe headers - [ ] 5. Segregate From: addresses and IPs by message type - [ ] 6. Set the warmup and volume ramp plan - [ ] 7. Wire monitoring: spam rate, reputation, SMTP errors, Safe Browsing - [ ] 8. Validate the whole stack, fix, re-validate until every check passes - [ ] 9. If failing, run the diagnosis path by error code ``` **1. Establish the volume tier.** Bulk-sender obligations attach at 5,000+ messages per day to personal Gmail accounts; below that, senders must still have SPF or DKIM, and bulk senders must have SPF, DKIM, and DMARC ([Google](https://support.google.com/a/answer/81126)). Count messages across *all* domains and mailboxes in the program, because splitting volume across inboxes does not change what the receiving side measures on your domain reputation. **2. Verify authentication.** These are exact requirements, not preferences — unauthenticated messages "might be marked as spam or rejected with a `5.7.26` error" ([Google](https://support.google.com/a/answer/81126)): - SPF record published and including every sender for the domain. - DKIM key of 1,024 bits or longer; use 2,048-bit, which is Google's recommendation ([Google](https://support.google.com/a/answer/81126)). - DMARC published, with SPF or DKIM (or both) passing **and** the authenticating domain matching the domain in the `From:` header — alignment is the part that silently fails after a sending-tool migration ([Google](https://support.google.com/a/answer/81126)). - TLS in use for transmission, which is a requirement, not an option ([Google](https://support.google.com/a/answer/81126)). **3. Verify forward and reverse DNS.** The sending IP needs a PTR record resolving to a hostname, and that hostname needs an A record (IPv4) or AAAA record (IPv6) resolving back to the same public IP; forward and reverse DNS must agree ([Google](https://support.google.com/a/answer/81126)). On a shared IP you inherit the reputation of every other sender on it, so check blocklist status before you send anything ([Google](https://support.google.com/a/answer/81126)). **4. Implement one-click unsubscribe.** Required for senders of more than 5,000 messages per day on marketing and subscribed messages, using both headers ([Google](https://support.google.com/a/answer/81126)): ``` List-Unsubscribe-Post: List-Unsubscribe=One-Click List-Unsubscribe: ``` Implement per RFC 2369 and RFC 8058 ([Google](https://support.google.com/a/answer/81126)). Do not substitute a body link for the headers — the header is what the mailbox client renders, and its absence is a compliance failure independent of your footer. Also confirm each recipient's address before subscribing, periodically re-confirm, and unsubscribe recipients who never open ([Google](https://support.google.com/a/answer/81126)). **5. Segregate senders by message type.** Use separate IPs and `From:` addresses per message class — for example receipts, promotions, and notifications on distinct addresses — and never mix promotional content into transactional messages ([Google](https://support.google.com/a/answer/81126)). Never purchase email addresses ([Google](https://support.google.com/a/answer/81126)). Formatting rules that gate acceptance ([Google](https://support.google.com/a/answer/81126)): format per RFC 5322; include a valid `Message-ID`; keep `From:`, `To:`, `Subject:`, and `Date:` to one instance each with exactly one address in `From:`; never begin a subject with `Re:` or `Fwd:` unless the message really is a reply or forward; no emoji or non-standard characters imitating graphic elements or implying verification; no content hidden with HTML or CSS. The display name must identify the sender only — patterns such as `URGENT REQUEST`, `Last Chance`, `[1] New Message`, or the recipient's first name as the display name are prohibited, and an `@gmail.com` domain should not be used as the display name for bulk email ([Google](https://support.google.com/a/answer/81126)). **6. Set the warmup and ramp plan.** Send at a consistent rate, avoid bursts, start low with engaged users, and increase slowly; "immediately doubling previously sent volumes could result in rate limiting or reputation drops" ([Google](https://support.google.com/a/answer/81126)). After changes to infrastructure or header structure, ramp the modified traffic segment separately, and if you change bulk-email format, increase volume with the new format gradually ([Google](https://support.google.com/a/answer/81126)). If messages begin bouncing or deferring, reduce volume until the SMTP error rate falls, then increase slowly again ([Google](https://support.google.com/a/answer/81126)). Know the quota mechanics before you plan volume: Gmail limits volume per domain and per IP, DKIM and SPF quotas are domain-specific, the IP quota is shared by every sender on that IP, and when the IP hits quota all domains on it stop sending ([Google](https://support.google.com/a/answer/81126)). **7. Wire monitoring.** Monitor server responses, spam rate, and sending-domain reputation on a standing cadence, using Postmaster Tools for spam markings, delivery problems, authentication status, and domain and IP reputation. Check regularly that the domain and its linked domains are not listed as unsafe with Google Safe Browsing ([Google](https://support.google.com/a/answer/81126)). The two hard numbers that govern the program: keep the Postmaster Tools spam rate **below 0.10%**, and **never reach 0.30% or higher**; a low spam rate makes a sender more resilient to occasional spikes in user feedback, while a high spam rate leads to increased spam classification, and improvements take time to show up in classification ([Google](https://support.google.com/a/answer/81126)). **8. Validate, fix, re-validate.** Run every check. On any failure, fix it and re-run the entire block, because authentication changes interact — a DMARC pass can regress when an SPF include is added. Only resume or increase sending when every line passes. ``` - [ ] SPF resolves and includes every sending source - [ ] DKIM signs with a 2,048-bit key; selector resolves - [ ] DMARC record present; SPF or DKIM passes AND aligns with From: domain - [ ] PTR resolves to a hostname whose A/AAAA returns the same IP - [ ] TLS negotiated on outbound connections - [ ] Both List-Unsubscribe headers present on marketing/subscribed mail - [ ] Postmaster Tools spam rate < 0.10% - [ ] Domain and IP reputation not Low or Bad - [ ] Domain and linked domains clear in Safe Browsing - [ ] Sending IP not on a blocklist - [ ] No subject beginning Re:/Fwd:; display name identifies the sender only - [ ] Planned volume increase is incremental, not a doubling ``` **9. Diagnose by error code.** Map the observed failure to its stated cause before changing anything, because the remediations are mutually exclusive ([Google](https://support.google.com/a/answer/81126)): | Symptom | Stated cause | Action | |---|---|---| | `5.7.26` rejection | Message not authenticated | Fix SPF/DKIM, then DMARC alignment | | `4.7.28` rejection | Sending quota exceeded | Run the quota recovery procedure below | | `421 4.7.0` | Sending IP not on the recipient domain's allowed list | Do not retry harder; contact the recipient domain | | `550 5.7.1` | Sending IP on a suspended list, common on poor-reputation shared IPs | Move off the shared IP | | `550-5.7.1` IPv6 PTR message | PTR record for the sending server not using IPv6 | Publish an IPv6 PTR, or confirm the provider uses one | Quota recovery after `4.7.28` — run exactly this sequence, and do not shorten the waits, because resuming at full concurrency re-trips the same quota ([Google](https://support.google.com/a/answer/81126)): 1. Stop sending for at least 10 minutes. 2. Assume all three quotas (DKIM, SPF, IP) are affected unless the error says which one. 3. After 10 minutes, resume from a single connection. 4. On failure, wait another 10 minutes. On success, add connections one at a time. If bounces and deferrals persist at low volume, inspect individual messages, and use a blank test message to check for issues ([Google](https://support.google.com/a/answer/81126)). ## Output format Use this exact structure for any deliverability audit or remediation report, because the checks are re-run against it. Commentary is yours to adapt. ```markdown # Deliverability audit — ## Volume tier Messages/day to personal Gmail: | Bulk obligations apply: yes/no ## Authentication | Control | Required | Observed | Status | | SPF | present, all sources | ... | PASS/FAIL | | DKIM | >=1024-bit, 2048 recommended | ... | PASS/FAIL | | DMARC | pass + From: alignment | ... | PASS/FAIL | | TLS | required | ... | PASS/FAIL | | PTR / A-AAAA | forward and reverse agree | ... | PASS/FAIL | | One-click unsubscribe | both headers | ... | PASS/FAIL | ## Reputation Spam rate: (ceiling 0.10%, never 0.30%) | Domain rep: <...> | IP rep: <...> ## Failures observed | SMTP code | Volume | Stated cause | Remediation | Owner | ## Ramp plan | Week | Daily volume | Segment | Gate to proceed | ## Re-validation result ``` ## Gotchas - Low open rates are not evidence of a deliverability problem. Google does not track open rates and cannot verify third-party open reporting, so diagnose from Postmaster Tools spam rate, reputation, and SMTP responses instead ([Google](https://support.google.com/a/answer/81126)). - Spam rate is the ceiling that determines whether volume strategy is viable at all: below 0.10%, never 0.30% or higher ([Google](https://support.google.com/a/answer/81126)). That is the mechanical reason low-volume, high-relevance outbound outperforms spray at scale; the same sub-0.1% requirement governs sequence design ([Apollo](https://www.apollo.io/insights/what-is-the-ideal-number-of-touches-in-an-outbound-sales-sequence)). - Spam-rate recovery lags the fix: improvements take time to reflect positively in spam classification ([Google](https://support.google.com/a/answer/81126)), so hold reduced volume for a monitoring window instead of declaring success the day the metric dips. - Inbox rotation does not dilute a domain reputation problem. Quotas and reputation are tracked per domain and per IP, and when a shared IP hits quota every domain on it stops sending ([Google](https://support.google.com/a/answer/81126)). - Do not send test phishing messages or test campaigns from the sending domain; it can damage reputation and land the domain on blocklists ([Google](https://support.google.com/a/answer/81126)). - Google does not accept allowlist requests from email providers and cannot guarantee that provider-sent mail passes Gmail spam filters ([Google](https://support.google.com/a/answer/81126)). There is no escalation path that substitutes for fixing authentication and complaint rate. - Waterfall-enriched lists raise match rate but not accuracy, and unverified addresses drive the complaints and bounces that breach the spam-rate ceiling ([Clay](https://www.clay.com/waterfall-enrichment)). Verify before the first send, not after the first bounce spike. - Affiliate and partner sending under your brand is your exposure: if a brand is associated with marketing spam, other messages from that brand might be marked as spam, so monitor affiliates and remove those that spam ([Google](https://support.google.com/a/answer/81126)).