The Burned Sending-Domain Recovery Playbook: Spam Folder Back to Inbox

Your outbound domain is landing in spam or getting bounced, and you own the answer for how the mail was sent. This playbook is for recruiting operations and revenue operations teams running cold outbound who need to diagnose the cause, decide whether the domain is worth saving, and run an ordered recovery that returns mail to the primary inbox without torching a second domain in the process. It gives you the enforced thresholds to measure against, the named diagnostic sources to read first, and a dated sequence you can execute start to finish.

Most pages on this topic end by selling warmup automation or a pack of pre-warmed inboxes. This one does not. It is the vendor-neutral rehabilitation procedure a team can run itself, plus the explicit rehabilitate-versus-retire arithmetic so you stop guessing.

What counts as a burned domain, and against which numbers

A domain is burned when receiving providers filter or reject its mail because of its accumulated reputation, not because of any single message. The tell is a persistent pattern: mail landing in junk, soft or hard rejections rising, and complaint or filter signals sitting above the enforced lines below.

All three major providers have converged on one hard number for user-reported spam complaints: keep the rate under 0.1%, and never let it reach 0.3%. Gmail's own guidance is to stay below 0.10% and avoid ever hitting 0.30% or higher. Yahoo mirrors the same 0.3% threshold. Microsoft's published guidance is that complaint rates should stay under 0.3%, and sustained rates above that produce Yellow and Red filter status.

Authentication is now table stakes. All three require SPF, DKIM, and DMARC at minimum p=none for senders above 5,000 emails per day. Microsoft's enforcement of that alignment for 5,000-plus daily senders began May 5, 2025. Non-compliant mail now faces temporary rate limiting or permanent rejection, so an auth gap can look exactly like a reputation burn until you check.

One classification is worth knowing before you touch anything: if you send 5,000 or more emails per day to personal Gmail accounts, you are permanently a bulk sender. That status cannot be reverted by cutting volume. It does not doom you, but it means the bulk-sender rules apply for the life of the domain.

No provider publishes an official bounce-rate ceiling. The practitioner convention is to target under 2% and investigate anything over 3%, but treat that as convention, not enforced policy. Where a number is not publicly established, this guide says so.

The diagnostic sources to read first, and what a reading means

Before you fix anything, you need to name the failure. There are four distinct problems that all present as "mail in spam": a reputation burn, a public blacklist listing, an authentication failure, and a list-or-content problem. They have different fixes, and reading the wrong one wastes weeks. Read three sources in order.

Google Postmaster Tools v2 is now binary. As of October 2025, Google retired the v1 interface and permanently removed the IP Reputation and Domain Reputation dashboards. You now monitor a Pass/Fail Compliance Status, spam rates, and authentication results. Historically a Bad rating meant a history of sending high volumes of spam, with mail from the domain almost always marked spam or rejected. The v2 signal is coarser but faster to act on.

Microsoft SNDS uses a traffic light. Green means under 10% of sampled mail was spam-classified, yellow is 10 to 90%, and red is over 90%. Critically, this is an aggregate filtering result and does not directly show inbox or junk placement. A red status can coexist with inbox placement, and green does not prove inbox acceptance. Read SNDS as directional. SNDS also reports spam-trap hits, and the target there is always zero: any trap hit indicates a list-quality failure.

A public blacklist check such as Spamhaus is a separate system entirely. A bad Postmaster reputation is not the same as being blacklisted. The blacklist is a public DNSBL; Postmaster reputation is Gmail's private internal score. You can be clean on one and burned on the other, so check both independently.

Yahoo has no public postmaster dashboard, so for Yahoo you rely on DMARC aggregate reports and bounce patterns. That is a genuine blind spot; do not assume Yahoo health from Gmail signals.

That last point is the single most common misread. If your complaint rate looks fine but placement is collapsing, you are probably reading a domain that is already filtered, where only your surviving mail can generate complaints.

The rehabilitate-versus-retire decision, computed

Deciding whether to save a domain is arithmetic, not sentiment. Retire when the time and opportunity cost of recovery exceeds the cost of setting up and warming a new domain. That crossover is explicit and computable.

Full recovery of a burned domain runs 4 to 16 weeks of disciplined work. A replacement domain costs roughly $300 to $800 including its 60 to 90 day re-warm, and its setup-and-initial-warmup phase is about 3 to 4 weeks. So the question is whether the specific domain's brand equity and history justify weeks of constrained sending versus starting clean.

One rule overrides the arithmetic. There is no gentle recovery from a sustained complaint problem: you change targeting or you change domains. If the same audience keeps reporting you, a new domain will burn within weeks. Switching domains without fixing the underlying behavior just moves the problem to a new domain, where it recurs on the same schedule.

If you retire, retire cleanly. Let the domain expire or keep it parked so it does not become available for someone else to register and abuse with your former reputation. And know that recovery talent is scarce enough that many teams reach for automation because they cannot hire the skill.

The recovery sequence, in order

Run these eight steps in order. Skipping ahead is how domains re-burn at day 45. The whole sequence takes 4 to 16 weeks depending on severity, and the owner is your RevOps or deliverability lead working with IT on authentication.

Two details in that sequence carry more weight than the rest. First, if you are blacklisted, stop all email the second you discover the listing, because continuing to send while listed makes removal harder and slower. Second, never request delisting before the root cause is fixed and documented; unresolved removal requests get denied and can extend the block.

The re-warm ramp and per-mailbox ceilings

Recovering domains ramp slower than new ones, and the ceiling per mailbox is lower than most teams expect. A brand-new domain needs a minimum of 3 to 4 weeks, starting at 5 to 10 emails per day and increasing toward 150 to 200 per day by week 4. A domain recovering from a burn or a blacklisting typically needs 6 to 8 weeks, and you reduce all sending first, letting warmup run for at least 3 to 4 weeks with clean engagement before you reintroduce any cold email.

Hold the ceiling. The safe cold-email limit is 30 to 50 sends per day per mailbox including warmup, with a hard cap of 80 to 120 per day. The scaling lever is the number of warmed mailboxes you run, not how hard you push a single one. Volume is a function of mailbox count.

Volume is a function of how many warmed mailboxes you run, not how hard you push any single one.

The plateau, not the pause, is what prevents a re-burn. Teams that compress a 90-day ramp into 30 days see burns around day 45, precisely because they skipped the middle plateau. The mechanism is that provider systems need time to recalibrate their trust before each volume step. A fixed calendar pause does not deliver that on its own; holding a steady volume for several days between increases does.

Root cause, list purge, and delisting

You cannot ramp your way out of a problem you have not fixed. Before any re-warm, close the two causes that produce most burns: broken authentication and a dirty list. Then, only if you are on a public blocklist, request removal.

For authentication, confirm SPF, DKIM, and DMARC alignment passes on a seed test. Document the exact send that spiked complaints or trap hits, because a delist request that cannot describe the fixed cause tends to get denied. Implement RFC 8058 one-click List-Unsubscribe so recipients can leave without hitting the spam button.

For the list, the single fastest way to burn a warmed domain is a dirty list: a 6% bounce rate can undo six weeks of ramping in two sends. Warming while sending to dead or risky addresses is self-sabotage. Run every new address through a verification pass first, remove role-based, invalid, and inactive contacts, and implement double opt-in for new subscribers going forward. Any SNDS trap hit is a stop signal, because the target is always zero and any hit indicates a list-quality failure.

Finding someone who has actually run this is harder than it should be. In Refolk's index, only 30 people in the US hold a deliverability-specialist, consultant, or manager title, and just 7 in the UK. Refolk lets you ask for that skill in plain English and get the handful of people who have done the work, rather than filtering a keyword field by hand.

For delisting, Spamhaus removals for legitimate requests process in roughly 24 to 72 hours. Removal is free; any paid-removal offer is a scam. Submit through the correct list form only after the cause is fixed, and confirm the lookup returns clean before you resume any sending.

How this goes wrong: failure modes and false positives

The most valuable part of any recovery is knowing where the signals lie to you. Each failure below has a false positive and a check that beats it.

• Trusting SNDS green as inbox placement. Green while users still see junk. SNDS is a filtering aggregate, not a placement report. Check with seed tests and actual user reports, not color alone.
• Requesting delisting before fixing the cause. The request fails and can extend the block, because Spamhaus denies unresolved requests. Check that the root cause is documented before you submit.
• Reading the spam rate while already filtered. The denominator is inboxed mail, so a burned domain under-reports complaints; filtered recipients cannot complain. Check IP and domain acceptance, not just the complaint percentage.
• Re-warming on a dirty list. One 6% bounce batch undoes weeks of work. Check that every address passed verification before the send.
• Switching domains without behavior change. The new domain burns within weeks. Check that targeting, list, or content actually changed, not just the domain name.
• Compressing the ramp. Teams collapsing 90 days into 30 see burns at day 45. Check that plateaus were held and cold volume stayed under roughly 20% early.
• Assuming Postmaster Bad equals blacklisted, or the reverse. They are different systems with independent state. Check both.

The through-line here is that no single dashboard is a verdict. Provider signals are lagging, aggregated, and sometimes structurally misleading. Triangulate before you act.

Verify before you call it recovered

Run this checklist before declaring the domain rehabilitated and returning it to normal cold volume. If any item fails, do not scale.

Keeping the domain healthy after recovery

Recovery is not a one-time fix; it is a baseline you defend. The domains that stay in the inbox are the ones whose owners keep reading the same three sources on a schedule and treat any drift toward 0.1% as a signal to slow down, not a number to ignore.

Set a standing cadence. Check Postmaster v2 Compliance and spam rate weekly, watch SNDS for trap hits, and re-run a blacklist lookup after any volume increase. Because thresholds and dashboards change - the v1 reputation dashboards were removed in October 2025, and Microsoft's auth enforcement began May 5, 2025 - re-read each provider's current bulk-sender guidance quarterly rather than trusting a number you memorized. The mechanism is stable even when the exact interface is not: providers measure complaints, authentication, and list quality, and they enforce a converging 0.3% line.

Keep the list clean continuously. Verify new addresses on entry, hold double opt-in, and remove inactive or bouncing contacts on a regular sweep, because a domain re-burns fastest through the same dirty-list path that burned it the first time. And keep total volume tied to warmed mailbox count, so you never have to push a single mailbox past its ceiling to hit a number. The playbook that recovered the domain is the same one that keeps it healthy.