Protecting Email Deliverability

• Source: Report research library
• Frameworks applied: Google bulk sender requirements (SPF/DKIM/DMARC, PTR forward-reverse DNS, TLS), RFC 8058 and RFC 2369 one-click unsubscribe, Postmaster Tools spam-rate ceilings, warmup and volume ramp, SMTP error-code diagnosis and 4.7.28 quota recovery

Exact configuration requirements, an SMTP-code-to-remediation table, and a quota-recovery sequence with explicit do-not-shorten guardrails.

Known weakness, published as found: Almost every rule cites one Google support page; add a second independent source for the reputation and warmup claims, and note that bulk-sender thresholds change so the page should be re-checked before an audit. Split the RFC-5322 formatting rules into a gated subsection since they apply to a minority of remediation runs.

1. 1.Copy the SKILL.md text below, or download the raw file.
2. 2.Create a folder named exactly protecting-email-deliverability in your agent's skills directory.
3. 3.Save the file inside that folder as SKILL.md.
4. 4.Ask the agent one of the trigger requests below.
5. 5.Check the output against what you already know before it leaves your desk.

• Our outbound emails started going to spam after we scaled volume - audit the domain setup
• Do we need DMARC and one-click unsubscribe if we send 8,000 emails a day to Gmail?
• We are getting 550 5.7.1 and 4.7.28 rejections - diagnose and give a remediation plan

• Draft a 4T cold email for a new VP of Sales who just joined our target account
• Build the tier 1 / tier 2 account tiering model for our ABM program

---
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: <https://example.com/unsubscribe/example>
```

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 — <domain> <date>

## Volume tier
Messages/day to personal Gmail: <n> | 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: <x.xx%> (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
<every check PASS, or the blocking item>
```

## 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)).

What does the Protecting Email Deliverability skill do?

Configures and monitors sending infrastructure against bulk-sender rules and diagnoses deliverability failures by SMTP error code

Where does the Protecting Email Deliverability skill come from?

Report research library. It was written by The Revenue AI Report against a 12 criterion quality rubric and graded in an independent scoring pass.

Why was the Protecting Email Deliverability skill chosen for this library?

Exact configuration requirements, an SMTP-code-to-remediation table, and a quota-recovery sequence with explicit do-not-shorten guardrails.

When should the Protecting Email Deliverability skill not be used?

Do not use it for: Draft a 4T cold email for a new VP of Sales who just joined our target account Or: Build the tier 1 / tier 2 account tiering model for our ABM program

How do I install the Protecting Email Deliverability SKILL.md file?

Download the file, create a folder named exactly protecting-email-deliverability inside your agent's skills directory, and save the file inside it as SKILL.md. The agent loads it when a request matches the description.