Reputation Incident Recovery

This is the operational runbook for the days and weeks after a reputation incident — a compromised account or API key that pumped spam through your infrastructure, a list accident, or any event that collapsed IP/domain reputation. It complements Reputation Monitoring and Remediation (detection, diagnosis, blocklist delisting) and IP Warm-Up (building reputation from scratch); this article covers the recovery sequence itself, how re-warming differs from a cold warm-up, and how to read receiver push-back while you rebuild.

Post-compromise restoration sequence

The sequence below merges SendGrid's documented post-compromise restoration guidance with standard ESP incident practice. Order matters: every step assumes the previous one is complete — re-warming on top of an unsecured account or a dirty queue just re-burns the reputation you are trying to rebuild.

1. Stop the bleeding

• Pause all sending for several days. SendGrid's guidance is explicit: stop transmission to prevent additional reputation damage before attempting anything else. Mail sent while receivers are actively penalizing you deepens the hole.
• Secure the account: rotate every credential and API key, revoke unknown API keys and teammate/subuser access, enable/enforce 2FA, and audit for attacker-added domains, senders, webhooks, or templates. The compromise vector must be closed before any recovery mail goes out — otherwise the attacker resumes the moment you do.
• Purge queues. Drain or delete everything still queued or deferred from the incident window. Deferred spam retrying for hours or days after "recovery" keeps generating complaints, trap hits, and blocks under your name.

2. Rebuild the data layer

• Rebuild suppression lists. Attackers commonly delete or export suppression lists (bounces, complaints, unsubscribes) — and mail sent during the compromise generated new bounces and complaints that must be honored. Restore suppressions from backup, merge in every bounce and FBL complaint from the incident window, and treat any address the attacker mailed that was not on your opt-in list as permanently suppressed.
• Cut the send list to recently engaged recipients only ("remove unengaged recipients from your contact list" in SendGrid's wording). Recovery sending is done exclusively with your best data — recent openers/clickers — exactly as at the start of a warm-up, but with even less margin for error.

3. Re-verify infrastructure

• Confirm authentication end to end: SPF, DKIM, and an enforced DMARC record on all sending domains. SendGrid lists establishing DMARC across all sending domains as a core restoration step — it both blocks continued spoofing of your domain and signals control to receivers.
• Re-check compliance with provider bulk-sender requirements (Gmail, Yahoo, Microsoft). An incident is often when enforcement that was previously latent becomes active.
• Enroll in every monitoring channel before resuming: Google Postmaster Tools, Microsoft SNDS/JMRP, Yahoo's complaint feedback loop. These provide the per-provider verdicts that gate each ramp-up step.

4. Delist and notify

• Work blocklist delisting per the delisting workflow — with root cause fixed first; a compromise is one of the few listing causes where operators routinely delist quickly once you can show the account is secured.
• For persistent post-recovery blocks at a specific provider, contact that provider's postmaster/support channel directly with a description of the incident and remediation — SendGrid explicitly recommends engaging the major providers' support teams for tailored assistance.

5. Gradual re-ramp

• Resume with a manual warm-up process: small volumes to engaged recipients, increased gradually (schedules below). On platforms with automated warmup, the automation may need to be re-armed or the IP re-entered into warmup — an IP that kept its warmup "graduated" status internally has still lost its reputation externally.
• Expectation setting (SendGrid's stated timeline): internal reputation measures (platform-side engagement scores) recover relatively quickly; external reputation with recipient servers can take up to a month or longer of patient, consistent sending. Community-documented full inbox recovery after severe damage runs 8–12 weeks (see Recovering inbox placement).
• Track engagement-quality metrics continuously during the ramp — SendGrid points at engagement recency and unique open rate as the scores to watch; on any platform, the equivalents are per-provider open/click trends and complaint rate.

Re-warming after an incident vs cold warm-up

Re-warming reuses the mechanics of a cold warm-up but the situation differs in ways that change the plan:

Dimension	Cold warm-up (new IP/domain)	Re-warm (post-incident)
Starting reputation	Slightly negative — unknown, treated with suspicion	Actively negative — receivers have concrete bad history tied to the asset
Prerequisite	None beyond DNS/auth setup	Root cause fixed, queues purged, suppressions rebuilt, delistings requested — ramping before this re-triggers penalties
Pacing	Standard schedule (e.g., +50%/week or vendor stage plan)	Same shape but expect to hold or step back at individual providers; receivers that blocked you re-throttle harder and longer
Audience	Recently engaged recipients	Even stricter: only recent engagers, high-risk flows (winback, re-engagement, third-party) suspended for the whole recovery
Signals gating each increase	Deferral/failure rates, inbox placement	Same, plus blocklist re-check before each increase — relisting during a re-warm is treated more harshly than the first listing
Timeline	Weeks to full volume	External trust: up to a month (SendGrid) to 8–12 weeks for full inbox recovery

Two additional vendor-documented rules that bear on re-warming:

• Dormancy resets warm-up. SendGrid: if an IP has not sent in over 30 days, warm-up should be resumed before returning to volume. A recovery pause of several weeks therefore itself creates a re-warm requirement, independent of the incident.
• Prevention is cheaper. SendGrid's own framing: "establishing a positive reputation as a sender takes less effort than repairing an existing reputation." Budget recovery time accordingly.

Deferral handling during recovery

Deferrals (4xx temporary failures) are the primary real-time feedback channel during a re-ramp — receivers rarely explain a reputation penalty, but they always throttle. Concepts below are from SendGrid's deferral documentation; the mechanics generalize to any MTA.

What a deferral is: the recipient server cannot accept the message right now — a temporary condition, not a rejection; retries may succeed. All senders receive some deferrals; the signal is in the rate and the pattern, not their existence.

Retry behavior (SendGrid's implementation, typical of ESPs): deferred messages are retried with exponential backoff for up to 72 hours; if still undelivered, the message is finalized as blocked/expired. During automated warmup, a warming IP that hits its hourly cap stops sending and other account IPs carry the traffic; with no backup IPs, messages retry roughly every 15 minutes for 72 hours before expiring.

Deferral taxonomy — distinguish who is throttling:

Type	Example reasons	Meaning during recovery
External (receiver-initiated)	"IPs were throttled by recipient server"	The provider is limiting you based on your reputation — the core recovery signal
External (limit-based)	"IPs reached ISP-suggested hourly limits"	You exceeded the warmup/ramp threshold for that provider — pacing problem, not necessarily reputation
Internal (platform-initiated)	"reached ISP-suggested max connection limits", "max port limit", "max connection limit"	Your own platform is deliberately slowing delivery to protect reputation — do not fight it

Operational rules during a re-ramp:

• Rising deferral rate at one provider = hold or step back volume at that provider. Deferrals are throttling, the step before blocking (see warning signs). Do not advance the ramp while a provider is deferring at elevated rates.
• Do not blast through deferrals. Forcing more connections or re-injecting deferred mail as new messages converts throttling into blocks.
• For limit-type deferrals, reduce delivery rate (or spread across more warmed IPs); for receiver-throttle deferrals, let the retry system pace delivery — SendGrid's documented remediation table says "no action required; delivery auto-slowed."
• Measure impact via end-to-end delivery time — the gap between message acceptance by your platform and final delivery. Deferrals with low end-to-end times mean the throttle is absorbing your ramp without harming campaigns; growing end-to-end times mean you are ramping faster than the receiver will take.
• Pause entirely when deferrals at a provider convert into hard blocks or 72-hour expirations at meaningful rates — that provider is telling you the reputation isn't ready; drop volume there to near zero and rebuild with only the most engaged recipients.

Automated warmup schedules as implemented

Vendor automation is useful reference data for building your own ramp logic (per KB convention, mechanics are described conceptually; the numbers are vendor-attributed).

SendGrid automated warmup (41-day hourly-cap schedule)

SendGrid throttles a warming dedicated IP by an hourly send cap that grows ~40%/day over 42 days (day 0–41). When the cap is reached, the warming IP stops for the hour and other account IPs (including other warming IPs with headroom) carry overflow; with no backup IPs, mail retries every ~15 min for up to 72 h. After day 41 the IP exits warmup. Vendor-attributed schedule:

Day	Hourly cap	Day	Hourly cap	Day	Hourly cap
0	20	14	2,222	28	246,953
1	28	15	3,111	29	345,735
2	39	16	4,356	30	484,029
3	55	17	6,098	31	677,640
4	77	18	8,583	32	948,696
5	108	19	11,953	33	1,328,175
6	151	20	16,734	34	1,859,444
7	211	21	23,427	35	2,603,222
8	295	22	32,798	36	3,644,511
9	413	23	45,917	37	5,102,316
10	579	24	64,284	38	7,143,242
11	810	25	89,998	39	10,000,539
12	1,000	26	125,997	40	14,000,754
13	1,587	27	176,395	41	19,601,056

SendGrid's caveats: transactional streams should not be forced onto a strict schedule (you can't control trigger rates), and no schedule substitutes for sending practices — gradual ramp alone does not guarantee reputation.

Mailgun warmup (volume-stage model + API)

Mailgun's automatic warmup uses volume-based stages rather than calendar days: each stage has a daily cap, and the IP advances to the next stage once it has sent that stage's volume (stage progression and the 24-hour window are independent — sending the full stage volume advances you regardless of hours elapsed; the 24-hour window starts with the first message). Vendor-published stage caps: Stage 1 = 1,000/day, Stage 2 = 2,500/day; later stage caps are not published (a plan can run up to 15 stages per the API's schedule model). Hitting a daily cap early triggers a full-stop throttle on that IP until the 24-hour window resets. Overflow traffic is rerouted, not dropped: volume beyond the warming IP's cap rolls over to the account's shared IPs or other dedicated IPs — mail still sends, just not from the warming IP. Typical full warmup duration: 4–8 weeks.

The warmup is drivable via API (Mailgun API reference, vendor-specific):

Operation	Endpoint	Purpose
GET	/v3/ip-warmups	List in-flight IP warmup statuses
GET	/v3/ip-warmups/{addr}	Status of one in-flight warmup (current stage, stage/hourly limits, total stages)
POST	/v3/ip-warmups/{addr}	Create a warmup plan for an IP
DELETE	/v3/ip-warmups/{addr}	Cancel the warmup plan

Mailgun's manual guidance (archived help-center article, 2023 snapshot): dedicated IPs are recommended at ≥ 100,000 emails/month (this is Mailgun's house-rule; for how it sits against other vendors' minimums and the general per-IP statistical floor, see the canonical dedicated-IP volume floors table); start at 100 emails on day one and increase ~20% per day, sending daily (three sends/week or fewer works but slows trust-building); domains less than 30 days old should not be used at all — receivers associate freshly purchased domains with spammers cycling burned domains.

Design implications for your own ramp automation (what the two implementations agree on): cap the warming asset, don't queue-and-force — overflow goes to an already-warm path; grow caps geometrically (~20–50%/day); gate progression on successfully sent volume, not just elapsed time; and treat receiver push-back (deferrals) as a stop condition the automation must respect.

Replace or rehabilitate? Decision points

After a severe incident the tempting shortcut is a fresh IP or domain. The default answer is rehabilitate, because replacement rarely escapes the problem:

• New assets start negative, not neutral. A new IP is presumed to be a blocked spammer relocating (see IP Warm-Up); receivers treat domains younger than ~30 days as spammer-cycling behavior (Mailgun). Swapping assets is itself the pattern filters are built to catch.
• Reputation follows the mail, not just the asset. Domain reputation, content fingerprints, and list quality travel with you to the new IP; if root cause isn't fixed, the new asset burns faster than the old one recovered.
• Compromise-driven listings clear quickly. Blocklist operators and providers routinely reverse listings caused by a documented, remediated compromise — the rehabilitation path is genuinely available in this scenario (see delisting workflow).

Replacement (with a full warm-up from zero) is the right call only when rehabilitation is closed off or more expensive than starting over:

Factor	Favors rehabilitation	Favors replacement
Listing status	Delistable; operator responsive to remediation evidence	Permanent/repeat listing after mishandled requests; asset on lists with no practical removal path
History depth	Short incident window on an otherwise good asset	Long-running abuse history (e.g., inherited/previously-abused IP or domain) that predates you
Provider response after remediation	Deferrals easing, reputation dashboards recovering within weeks	Sustained hard blocks at major providers despite a clean multi-week re-warm
Asset role	Primary brand domain (organic/inherent reputation, BIMI, customer recognition — effectively irreplaceable)	Dedicated sending IP or sending subdomain, cheap to rotate and re-warm
Time economics	Recovery projected ≲ warm-up time (a re-warm on a rehabilitated asset can beat the 4–8+ weeks a cold warm-up takes)	Recovery stalled beyond a cold warm-up's timeline

Practical middle path for domains: never replace the organizational domain — rehabilitate it while moving mail streams to a fresh, properly delegated subdomain warmed from zero, which isolates the damage without the new-domain penalty (see M3AAWG Sending Domains BCP and Advanced IP Segmentation for stream-isolation mechanics). Whatever you replace, the burned asset should be retired cleanly (kept authenticated, protective DNS records) — see Brand Protection: Domain Management.

Related

• Reputation Monitoring and Remediation — detection, diagnosis, blocklist delisting, and the engaged-segment recovery playbook.
• IP Warm-Up — the cold warm-up baseline that re-warming adapts.
• Sending Infrastructure Practices — subdomain strategy and domain warm-up.
• Blocklists & Spamhaus — listing/delisting mechanics per list.
• Mandated & Regulatory Email — sends that cannot wait for a recovery window.