Order queue open · Verified lists delivered within 24–48 hours
How to recover a burned sending domain: step-by-step diagnosis, repair protocol, realistic timeline, and prevention checklist so it doesn't happen again.
Sarah Okonkwo
Email deliverability consultant, 6+ years fixing cold email infrastructure · Updated June 24, 2026
Last updated: June 2026 · Sarah Okonkwo, email deliverability consultant, 6+ years fixing cold email infrastructure
TL;DR — 7 things to know before reading
Domain burning is one of the most disruptive events in a cold email operation. Campaigns stop producing results overnight. Reply rates drop from 8–12% to 1–2%. Emails that were landing in inbox are now going to spam. The sending domain that took weeks to build is damaged.
The unique angle of this guide is the recovery protocol: a sequential, step-by-step process that starts with diagnosis (what is actually wrong), proceeds through repair (specific steps for each type of damage), covers the realistic recovery timeline, and ends with the prevention checklist that makes the protocol unnecessary in the future.
This is a technical guide. It is specific. Each step has a tool, a command, or a check. At the end of the guide is the prevention checklist: the reason the domain burned, documented as a set of pre-campaign checks that eliminate the root causes before they occur.
Before any repair work begins, diagnose exactly what is wrong with the domain. There are three distinct types of domain damage, each requiring a different repair approach.
Google Postmaster Tools is the primary diagnostic tool for Gmail inbox placement (which handles a large proportion of all B2B email receiving). Postmaster shows domain reputation on a four-level scale: High, Medium, Low, Bad.
How to check: Log in to Postmaster → select the domain → view "Domain Reputation" chart. The chart shows the reputation by day over the past 30–120 days.
What the reputation levels mean:
| Reputation level | Inbox placement | Spam placement | Recovery timeline |
|---|---|---|---|
| High | 90%+ inbox | Under 10% spam | No action needed |
| Medium | 70–90% inbox | 10–30% spam | Monitor, reduce volume, improve list quality |
| Low | Under 50% inbox | 50%+ spam | Active recovery protocol needed |
| Bad | Near 0% inbox | Near 100% spam | Severe recovery or domain retirement |
Note: Postmaster only shows data for domains with sufficient sending volume to Google domains. If Postmaster shows "Not enough data," the domain may not be damaged — it simply hasn't sent enough email to Google domains for Postmaster to build a reputation profile.
MXToolbox Blacklist Check checks the domain (and associated IP addresses) against 100+ email blacklist databases. A domain that is not blacklisted but has Low Postmaster reputation has a different problem than a domain that is on multiple blacklists.
How to run: Go to mxtoolbox.com/blacklists.aspx → enter the domain name → run the check.
Interpreting results:
| Result | Meaning | Recovery path |
|---|---|---|
| No blacklists | Domain is not on any major blacklist | Postmaster reputation recovery only |
| 1–3 minor blacklists | Low-impact blacklisting | Submit delisting requests; minor impact on deliverability |
| 4–10 blacklists | Moderate blacklisting | Submit delisting requests for all; Postmaster recovery |
| 10+ blacklists including Spamhaus or Barracuda | Severe blacklisting | Domain retirement recommended |
In Postmaster Tools, the "Spam Rate" metric shows what percentage of your email Gmail users are marking as spam. This is the most direct signal of why the domain is burning.
| Spam rate | Status | Action |
|---|---|---|
| Under 0.1% | Healthy | No action |
| 0.1–0.3% | Watch closely | Reduce volume, review list quality |
| 0.3–0.5% | Threshold approached | Pause production, audit contact list |
| Above 0.5% | Threshold breached | Pause all production immediately |
Per Gmail Sender Guidelines, spam complaint rates above 0.1% are in the "watch" range; above 0.3% Google begins throttling delivery.
Per Mailgun's email authentication guide, SPF, DKIM, and DMARC failures are a common cause of deliverability problems that appear similar to "burned domain" symptoms but are actually authentication configuration issues.
How to check:
If any of the three authentication records are missing or misconfigured, fix the DNS records before starting any other recovery work. Authentication issues cause immediate deliverability problems regardless of domain reputation.
| Check | Result | Recovery path |
|---|---|---|
| Postmaster reputation | Low, Bad, Medium, or High | Noted |
| Blacklist status | Count and severity | Noted |
| Spam complaint rate | Percentage | Noted |
| Authentication (SPF/DKIM/DMARC) | Pass/Fail for each | Noted |
This is the fastest repair. Authentication records can be fixed in the domain registrar's DNS settings. Changes propagate in 24–48 hours.
Steps:
Timeline: 24–48 hours for DNS propagation; 2–4 days to confirm deliverability improvement.
This is the most common scenario for a domain that has been sending cold email above safe volume limits or with insufficient warmup.
Steps:
Pause all production sends immediately. No cold email from any inbox on this domain until reputation recovers.
Switch all inboxes on the domain to warmup mode only. In Inframail, disable production sends and enable warmup-only mode. The warmup exchanges positive email engagement that rebuilds reputation.
Verify authentication records (Repair path A check) to rule out any authentication contribution to the reputation problem.
Check and clean the contact list. Review the most recent campaign's contact list: what was the bounce rate? What was the spam complaint rate? If either was above threshold, the contact list contributed to the reputation problem. Remove the source of bad contacts before resuming any production sends.
Submit delisting requests for any minor blacklist entries found in the MXToolbox check.
Wait. Postmaster reputation recovers based on positive sending behaviour over time. With warmup-only activity on the domain, recovery from Low to Medium typically takes 3–6 weeks. Recovery from Low to High takes 6–12 weeks.
Resume production at reduced volume. When Postmaster shows "Medium" reputation, resume production at 10–15 sends per inbox per day (vs. the previous 40–50). Increase by 5 sends per inbox per week if reputation holds or improves.
Timeline: 4–8 weeks from pause to cautious production resumption.
Moderate blacklisting typically indicates a significant spam complaint event (a batch of bad contacts, a message angle that triggered mass unsubscribe/complaint, or a burst of high-volume sends from a new domain).
Steps:
Pause all production sends immediately.
Submit delisting requests for each blacklist the domain appears on. Each blacklist has its own delisting process:
Identify the root cause. Review the campaign that caused the blacklisting: what was the contact list source? What was the send volume? Was there a sudden spike in volume that triggered the blacklisting? Document the root cause before resuming any sends.
Fix the root cause. If the cause was bad contact data: source a new verified list from Quarvio. If the cause was volume spike: rebuild the warmup ramp. If the cause was content flagging: rewrite the sequence.
Complete Repair path B (warmup-only recovery period) after all blacklist delistings are confirmed.
Timeline: 6–10 weeks, depending on the severity of blacklisting and how quickly delisting requests are processed.
Severe blacklisting — especially on Spamhaus SBL (Spamhaus Blocklist, the most widely used blocklist by enterprise mail servers) — typically means the domain has been sending volume that triggered Spamhaus's manual review and listing. Enterprise mail servers that check Spamhaus SBL will reject all email from the domain regardless of content or authentication.
Recommendation: domain retirement, not recovery.
The time and reputational cost of recovering a severely blacklisted domain often exceeds the cost of purchasing new domains and building fresh infrastructure via Inframail. Before investing 8–12 weeks in recovery attempts:
Calculate the cost of recovery: time spent on delisting requests, lost campaign performance during the recovery period, and the uncertain outcome of Spamhaus SBL delisting (Spamhaus can re-list a domain that they believe is sending abusively).
Compare to the cost of fresh infrastructure: 3 new domains ($30–60 total), 9 new Inframail inboxes, 3–4 weeks of warmup. Total: $100–$200 and 4 weeks to reach initial production-ready state.
In most cases, fresh infrastructure is the faster and more reliable path to resumed production.
If recovery is required (e.g., the domain is tied to brand identity):
Submit Spamhaus SBL delisting request: account.spamhaus.org → submit removal request. Spamhaus requires: (1) evidence that the sending issue has been resolved, (2) explanation of why the domain should be delisted, (3) commitment to comply with sending policies.
Follow Repair path B after Spamhaus delisting is confirmed.
Timeline: 8–16 weeks. Spamhaus SBL delisting can take 2–4 weeks to process and is not guaranteed.
| Week | Action | Milestone |
|---|---|---|
| 1 | Pause production. Run diagnosis. Fix authentication if needed. Submit all delisting requests. | Root cause documented |
| 2 | Warmup-only on recovering domain. Begin new domain setup (if rebuilding). | Delisting requests submitted |
| 3–4 | Continue warmup. Monitor Postmaster daily for reputation signal change. | Domain shows improvement in Postmaster (if recoverable) |
| 5–6 | If Postmaster shows Medium: begin limited production (10–15 sends/inbox/day). | First production sends resumed |
| 7–8 | Ramp production by 5 sends/inbox/week if reputation holds. | 30–40 sends/inbox/day (pre-incident level) |
| 9+ | Full production resumes on recovered domain or fresh infrastructure is at full warmup. | System restored |
Every domain burn is caused by at least one of the following identifiable, preventable failures. The prevention checklist eliminates each cause.
Pre-campaign infrastructure checks:
Pre-campaign contact list checks:
Ongoing monitoring:
Response protocol:
| Metric | Healthy | Monitor | Pause trigger | Pause action |
|---|---|---|---|---|
| Postmaster reputation | High | Medium | Low | Warmup-only mode |
| Spam complaint rate | Under 0.08% | 0.08–0.1% | Above 0.1% | Pause production |
| Bounce rate | Under 1.5% | 1.5–2% | Above 2% | Audit contact list |
| Blacklist entries | 0 | 1–2 minor | 3+ or any major | Submit delistings |
| Open rate | Above 25% | 15–25% | Under 15% | Check spam placement |
Rather than logging into Postmaster manually for each domain, set up Postmaster monitoring for all active sending domains under a single Google account. Create a shared "deliverability monitoring" Google Workspace account (one that has Postmaster access for all active domains). Daily monitoring then requires a single login and a visual scan of all domain reputation charts. At 3+ active domains, consolidated monitoring is essential for catching reputation drops before they become burns.
A "canary send" is a small batch (50–100 emails) sent to highly engaged contacts (previous positive reply list) once per month on any domain in warmup or slow-send mode. The purpose is to keep the domain's positive engagement signal active during low-volume periods. Even a domain not running active campaigns benefits from periodic small-volume positive engagement sends; this prevents reputation decay during campaign gaps.
For each active cold email domain, maintain a simple log: date of purchase, date of first production send, weekly Postmaster reputation ratings, any blacklist events and resolution dates, campaign volume history. The log makes it possible to identify patterns before damage occurs: if reputation has been declining slowly for 3 weeks, the log makes the trend visible in a way that weekly spot-checks do not. The log also accelerates diagnosis if damage occurs.
When adding new domains to expand sending capacity, stagger their production launch by 1–2 weeks. Do not add all new domains to production simultaneously. Adding 9 new inboxes to a campaign on the same day creates an inbox-volume spike signal for email providers — a sudden jump from 9 inboxes to 18 inboxes in a campaign is a detectable anomaly. Staggering the ramp (add 3 inboxes per week for 3 weeks) produces a gradual increase that email providers interpret as organic growth.
Maintain 2–3 domains in permanent warmup mode that are never used for production sends. These are reserve domains: if a production domain is burned and requires recovery, the reserve domains are already warmed up and can be promoted to production within days rather than weeks. The cost is low (domain registration + Inframail inbox fees on the reserve pool), and the insurance value is high (preventing 4–8 weeks of production downtime during a domain recovery event).
Symptom: The domain has been in warmup-only mode (no production sends) for 4 weeks. Postmaster still shows "Low" reputation.
Cause: The warmup-only mode is not generating sufficient positive engagement volume to overcome the negative reputation signals accumulated during the damage event. Or, the warmup tool is sending warmup emails to a small pool of warmup-network inboxes that doesn't have enough Google domain coverage to affect Postmaster reputation.
Fix: Increase warmup volume (if the warmup tool allows it). Check whether the warmup tool's network includes a significant proportion of Google-hosted (gmail.com, Google Workspace) inboxes, as Postmaster only reflects Gmail engagement. If the warmup network is primarily non-Google inboxes, Postmaster reputation may not improve even with high warmup volume. Consider adding Google-domain-specific warmup engagement (e.g., sending small batches to known Google Workspace accounts that have agreed to act as warmup partners).
Symptom: Submitted a delisting request to a major blacklist 2 weeks ago. MXToolbox still shows the domain as listed.
Cause 1: The delisting request was not submitted correctly (wrong form, incomplete information, or not following the specific blacklist's process). Cause 2: The blacklist operator reviewed the delisting request and denied it because the root cause of the listing was not adequately addressed.
Fix: Check the email confirmation from the blacklist operator (most send a confirmation). If no confirmation was received, re-submit the request. If a denial was received, address the specific reason cited in the denial before re-submitting. For Spamhaus, the most common denial reason is "sending behaviour that led to the listing has not changed" — ensure production sends have been fully paused and warmup-only mode is active before re-submitting.
Symptom: Postmaster is showing "Medium" reputation after 5 weeks of recovery. Production was resumed at reduced volume. But reply rate is still 2–3% instead of the pre-incident 8–10%.
Cause: "Medium" reputation in Postmaster means 70–90% of email is reaching the inbox, but 10–30% is still going to spam. At reduced send volume (10–15/inbox/day), the number of inbox-placed emails is lower than the pre-incident volume, which produces fewer replies in absolute terms. Additionally, the same contact list may have been re-used, and the portion of contacts who received emails during the damage period may have been trained to ignore or spam the domain.
Fix: Verify that reply rate (not just open rate) is being tracked separately from inbox rate. At "Medium" reputation and 15 sends/inbox/day, the expected absolute replies are proportionally lower than at "High" and 40 sends/inbox/day. Calculate reply rate per 100 sends: if it's back to 8–10%, the system is healthy but volume is still restricted. Continue the ramp (add 5 sends/inbox/week) and track reply rate. Also, source a fresh contact list from Quarvio for the recovery campaign rather than re-using the pre-incident contact list.
Symptom: SPF, DKIM, and DMARC all pass MXToolbox checks. Postmaster shows "High" reputation. But the open rate is 10% (spam placement level), not 30%+ (inbox placement level).
Cause: Postmaster reputation reflects Google's assessment of the domain for Gmail users. Some recipients may be on non-Google email providers (Outlook, Yahoo, corporate Exchange servers) that have different spam scoring criteria. A domain with perfect Postmaster metrics can still be delivered to spam by non-Google providers based on: content scoring, IP reputation, or provider-specific blacklists.
Fix: Send test emails to accounts at different email providers (Gmail, Outlook, Yahoo) and check delivery location. Use a tool like Mail-Tester (mail-tester.com) to evaluate spam score. Identify which email providers are delivering to spam and investigate their specific spam filter criteria. Common non-Google spam factors: commercial-sounding subject lines, links in the email body (especially to domains with spam history), certain formatting patterns.
Symptom: Fresh domains purchased and Inframail inboxes provisioned. Warmup completed. First production campaign started. Domain is showing "Low" reputation after 3 weeks.
Cause: One or more of: (a) warmup was insufficient (under 2 weeks), (b) production volume started too high (jumped to 40–50/inbox/day without ramping), (c) contact list has too many invalid or catch-all emails producing high bounce rate, (d) the email content is triggering spam filters.
Fix: Diagnose the specific cause by checking: (1) Postmaster spam complaint rate (if above 0.1%, the message is being marked as spam by recipients — content or targeting issue), (2) Instantly bounce rate (if above 2%, contact list issue), (3) Warmup duration check (was warmup at least 2 full weeks before production?), (4) Send volume ramp (did it start at 15–20/inbox/day and increase gradually?). The first cause that fails is the one to fix.
Symptom: Domain recovered to "High" reputation. New campaign launched. Domain burns again within 3 weeks.
Cause: The root cause of the first burn was not identified and fixed before re-launching. The same sending behaviour that caused the first burn is occurring in the second campaign.
Fix: Before re-launching any campaign on a recovered domain, complete the prevention checklist in full. Specifically: confirm the contact list is sourced from Quarvio (verified), confirm the production volume ramp was followed, confirm Postmaster monitoring is active. If the same domain burns twice without obvious cause, review the sending IP (Inframail uses Microsoft 365 infrastructure; if the Microsoft IP itself is on a blacklist, all inboxes on the domain will be affected regardless of domain reputation).
Symptom: Domain is in recovery (Repair path B), Postmaster shows Low, and the business needs to resume campaign sends within 2 weeks.
Cause: There is a timeline conflict between the recovery timeline (4–8 weeks minimum) and the business need for resumed sending.
Fix: Purchase new domains and begin fresh infrastructure build via Inframail in parallel with the recovery. The fresh infrastructure (new domains, new inboxes, full warmup) can be at initial production-ready state in 2–4 weeks. The recovered domain can resume its ramp when ready. Running fresh infrastructure in parallel eliminates the timeline conflict without rushing the recovery of the damaged domain.
Decision framework:
| Factor | Favours recovery | Favours retirement |
|---|---|---|
| Domain age | 12+ months old (significant warmup history) | Under 6 months old |
| Blacklist severity | Minor lists only (under 5) | Spamhaus SBL or 10+ lists |
| Business association | Domain is tied to brand identity | Generic outreach domain |
| Recovery cost (weeks × monthly infrastructure cost) | Under $200 | Over $500 |
| Probability of full recovery | High (single damage event, known root cause) | Low (repeated damage, unclear root cause) |
For most cold email outreach domains (generic outreach domains, not brand-tied), retirement and fresh infrastructure is the faster path to recovered sending performance than attempting to fully rehabilitate a severely damaged domain.
Google Postmaster Tools documentation describes the domain reputation system used to determine Gmail inbox placement. The documentation confirms that domain reputation is a rolling average of recent sending behaviour, meaning: (1) damage accumulates over weeks, not days, and (2) recovery requires consistent positive behaviour over weeks, not a single clean send. The rolling average nature of the system is why the recovery timeline in this guide is measured in weeks, not days.
Mailgun's email authentication guide documents that SPF, DKIM, and DMARC are required for sender authentication and that missing any of the three significantly increases spam filter scoring across all major email providers. The guide confirms that authentication failures are both a root cause of domain damage and a co-factor that amplifies other damage signals.
"We burned a domain that had been running for 8 months and thought recovery was possible. We spent 6 weeks on recovery attempts while our campaigns were down. Meanwhile, we should have just bought 3 new domains and rebuilt. The lesson: for outreach-only domains with no brand association, retirement and rebuild is almost always faster than recovery. We learned that the hard way." — G2 reviewer, Inframail reviews on G2
| Component | Tool | Notes |
|---|---|---|
| Cold email infrastructure | Inframail | Microsoft 365, automated DNS, fast provisioning |
| Contact data | Quarvio | SMTP-verified, prevents contact-quality-related burns |
| Email sending | Instantly | Built-in bounce rate alerts, warmup integration |
| LinkedIn (parallel channel) | Aimfox | Reduces email volume dependence during recovery |
How long does a burned domain take to recover?
Realistic recovery timeline: Low reputation with no blacklisting: 4–6 weeks. Low reputation with minor blacklisting (under 5 lists): 6–8 weeks. Bad reputation or major blacklisting: 8–16 weeks, or domain retirement recommended. These timelines assume active recovery work (warmup-only mode, delisting requests submitted) and are not guarantees — some domains with persistent damage signals (ongoing spam complaint sources) may not fully recover.
What is the difference between domain reputation and IP reputation?
Domain reputation is the assessment of the sending domain (company-growth.io) by email providers. IP reputation is the assessment of the sending IP address. Inframail uses Microsoft 365 infrastructure, which provides shared IP addresses from Microsoft's pool. Microsoft 365 IPs are generally well-regarded and do not typically require individual IP management. If Microsoft's sending IPs are on a blacklist, Inframail will generally resolve this at the infrastructure level — individual users are not responsible for managing Microsoft 365 IP reputation.
Can I recover a domain that has been on Spamhaus SBL?
Sometimes. Spamhaus SBL delisting requires: (1) proving to Spamhaus that the sending behaviour that triggered the listing has stopped, (2) explaining how the issue was resolved, and (3) committing to compliance with Spamhaus's policies. Spamhaus's manual review process can take 2–4 weeks. For cold email outreach domains (not brand-primary domains), the time and uncertainty of Spamhaus recovery usually makes domain retirement a better use of resources.
What is the fastest way to get back to 40 sends per inbox per day after a recovery?
Do not rush the ramp. Jumping from 0 to 40 sends/inbox/day immediately after recovery will re-damage the domain faster than the original damage. The correct ramp: start at 10–15/inbox/day, add 5 per week, monitor Postmaster daily. At this rate, reaching 40/inbox/day takes 5–6 weeks from recovery start. This is frustrating but necessary. The alternative — re-burning the recovered domain — sets the recovery timeline back another 4–8 weeks.
How many domains should I have to avoid downtime if one burns?
For a 300-send/day operation: 3 active domains (9 inboxes) + 2 reserve domains (6 inboxes in permanent warmup). If one active domain burns, the two remaining active domains maintain 200/day capacity while the burned domain recovers. The reserve domains can be promoted to production (starting at 10–15/inbox/day) if more capacity is urgently needed. Building a reserve pool is the most effective protection against production downtime from domain burns.
Does sending volume cause domain burning directly?
High volume alone does not burn a domain. What burns a domain is a combination of: high volume + low-quality contacts (bounces, spam complaints) + insufficient warmup. A perfectly warmed domain with verified contact data can sustainably send 40–50 emails per inbox per day. The same domain with a 5% bounce rate from bad contacts will burn within 1–2 weeks at the same volume. Volume is a multiplier on other risk factors, not a risk factor in isolation.
Should I tell clients or stakeholders that a domain burned?
Yes. Transparency about domain burns is important for two reasons: (1) campaign performance has dropped and stakeholders will notice; an unexplained performance drop is more alarming than an explained one. (2) The root cause analysis may require information from the client (were any unusual contacts added to the list? Was the volume higher than agreed?). Frame the communication as: "We identified a deliverability issue, here is what caused it, here is the recovery timeline, here is what we are doing to prevent it happening again."
How do I verify that the domain is fully recovered before running full production?
Three confirmation checks before resuming full production: (1) Postmaster shows "High" reputation for at least 2 consecutive weeks, (2) No blacklist entries on MXToolbox, (3) First 200 production sends (at the reduced volume ramp) show open rate above 25% and bounce rate below 1.5%. All three checks must pass simultaneously before increasing volume above the reduced recovery rate.
Fresh infrastructure prevents domain burns from happening.
Inframail provisions Microsoft 365 cold email inboxes with automated SPF, DKIM, and DMARC setup on dedicated domains — so authentication is never the cause of deliverability problems. Flat rate per inbox, no per-email fees.
Set up your cold email infrastructure with Inframail →
