Recovery Playbook
The pause and stop thresholds in Monitoring & Stop Rules tell you when to stop. This page is what happens next. A breached hard stop is not the end of the migration — recovery is possible, and usually successful — but it takes discipline, not panic. The clubs that fail recovery are the ones that change three things at once, restart too fast, or quietly keep sending.
One rule above all: nothing leaves the subdomain until you know why the incident happened. Resuming on a guess is how a recoverable wobble becomes a burned domain.
When to invoke
Invoke this playbook when any of the following occurs:
| Trigger | Threshold |
|---|---|
| Spam complaint rate | ≥0.30% on any send (hard stop) |
| Hard bounce rate | Above 3% on any send (hard stop) |
| Provider blocks | Sustained blocks or rejections (e.g. repeated 5xx policy refusals from Gmail or Microsoft) across send days |
| Failed pause recovery | A pause (complaints above 0.20%, or bounces above 2%) that has not recovered after two clean re-tries |
If you are below these levels but above the green thresholds (complaints below 0.10%, hard bounces below 0.50%), you are in pause-and-hold territory — follow the monitoring page, not this one.
The staged response
Work through the stages in order. Do not skip Stage 2.
Stage 1 — Stop all sends, same day
- Stop every send from the subdomain the same day the threshold is breached — no "finishing the batch".
- Pause any scheduled GHL workflows, campaigns, and automations that send from the subdomain.
- Confirm nothing else (transactional triggers, third-party tools) is still sending through the Mailgun domain.
Stage 2 — Diagnose before changing anything
Do not edit templates, swap segments, or touch DNS until you know the cause. Work through, in order:
- Mailgun logs: which provider is rejecting (Gmail, Microsoft, BT, etc.), which SMTP codes, and whether the event mix is complaints (FBL), hard bounces, or blocks/deferrals.
- Authentication pass rate: confirm SPF, DKIM, and DMARC are still passing on recent sends — a broken DNS record can masquerade as a reputation problem.
- Segment audit: which tier or segment was in the last sends before the breach? Most incidents trace to a dirty segment added too early — lapsed members, an old prospect list, or addresses that skipped data prep.
- Content triggers: new template, new link domain, attachment, or URL shortener introduced in the failing sends.
Write the diagnosis down in the per-club runbook before moving to Stage 3.
Stage 3 — Communicate via the bridge
If the Intelligent Golf bridge is still live, urgent club communications go out from there while the subdomain rests. The club does not go silent because the new domain is recovering — that is exactly what the bridge is for.
Stage 4 — Cool-off (minimum 5–7 days)
- Suppress every complainer and every bounced address permanently — they never re-enter any segment.
- Re-clean the list per Data Preparation standards: re-verify the segment that caused the incident.
- Fix the diagnosed cause (segment, content, or DNS) — one fix, documented.
- Send nothing from the subdomain for at least 5–7 days. Replying to inbound member emails from GHL Conversations is fine — those 1-to-1 replies are positive signal, not volume.
Stage 5 — Re-entry
Re-entry is a stricter, slower version of the original ramp in the Ramp Schedule:
- Run a seed-panel placement check before the first re-entry send — if seeds land in spam, extend the cool-off.
- Restart at Tier A only, at roughly half the previous Day-1 volume (so a club that started at ~105 restarts at ~50–55).
- Require 3 consecutive clean send days per stage before advancing — stricter than the normal 2–3.
- Keep the daily monitoring dashboard running with the same hard-stop thresholds.
Stage 6 — Last resort: a fresh subdomain
Only if re-entry fails repeatedly and Mailgun logs show persistent hard rejections against the subdomain itself: spin up a fresh variant (e.g. mail2.<club>.co.uk) and run the full warm-up from zero. One respin maximum.
Rotating domains without fixing the underlying cause is the exact pattern mailbox providers classify as abuse (snowshoeing). A second domain carrying the same dirty list or the same broken content will burn faster than the first — and drag the root domain's reputation with it. Respin only after a clean diagnosis, a clean list, and a documented fix.
Stage 7 — Escalation and ownership
The named decision-maker in the per-club runbook owns the invoke/resume/respin decisions — not the club manager mid-panic, and not whoever happens to be watching the dashboard. The same-day pause rule applies throughout recovery: any breach during re-entry stops sends that day, no exceptions, no "one more send to confirm".
Decision table
| Symptom | Likely cause | Jump to |
|---|---|---|
| Complaint spike (FBL events) on one send | Dirty or cold segment added too early; content mismatch with audience | Stage 2, then Stage 4 list re-clean |
| Hard bounce spike above 3% | Unverified addresses skipped data prep | Stage 2 segment audit, Stage 4 re-verify |
| Gmail-only deferrals/blocks, other providers fine | Gmail reputation throttling — ramped too fast | Stage 1, short cool-off, Stage 5 at half volume |
| Blocks across all providers + auth failures in logs | Broken SPF/DKIM/DMARC record | Stage 2 authentication check — fix DNS, often no full cool-off needed |
| Seeds in spam but metrics look clean | Silent placement degradation | Stage 4 cool-off, Stage 5 seed check before re-entry |
| Re-entry fails twice with persistent hard rejections | Subdomain reputation not recovering | Stage 6 — one respin maximum |
Cross-reference: Monitoring & Stop Rules for the thresholds that trigger this page, and the Ramp Schedule for the normal-path volumes that re-entry halves.
Monitoring & Stop Rules
Daily metrics dashboard, thresholds, decision logic, and red-flag response playbook for the Intelligent Golf → GHL email migration ramp.
Templates
Production-ready email and SMS templates for the Intelligent Golf → GHL LC Email migration, with format guidance and copy rules for the warm-up period.