How to recover a burned sending domain: a step-by-step deliverability guide

Last updated: June 2026 · Sarah Okonkwo, email deliverability consultant, 6+ years fixing cold email infrastructure

---

TL;DR — 7 things to know before reading

• A burned sending domain is a domain whose email reputation has degraded to the point where email from that domain is being delivered to spam or rejected by receiving mail servers; it is diagnosable, often recoverable, and always preventable
• This guide uniquely covers domain recovery as a protocol with specific steps, specific tools, and specific timing expectations at each step — not a general "fix your deliverability" guide but a step-by-step recovery sequence from diagnosis to prevention
• The minimum realistic recovery timeline for a domain that has reached "Low" or "Bad" reputation in Google Postmaster Tools is 4–8 weeks of active recovery work; domains with blacklist entries on multiple major lists may take 8–12 weeks
• Per Google Postmaster Tools documentation, domain reputation signals are based on a rolling window of recent sending behaviour; recovery requires demonstrating consistent positive behaviour over weeks, not days
• MXToolbox's blacklist checker is the diagnostic starting point: it checks the domain against 100+ blacklist databases and identifies which lists have flagged the domain, which determines which delisting requests to submit
• Inframail with Microsoft 365 inboxes is a faster rebuild path than attempting to recover damaged domains in high-volume production: at some damage levels, retiring the domain and rebuilding on fresh infrastructure is faster than recovery
• Prevention is the only reliable solution: the domain recovery protocol in this guide is a repair manual, not a strategy; the correct strategy is the prevention checklist at the end of this guide, which eliminates the causes of domain damage before they occur

---

Our take

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.

Step 1: Diagnosis

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.

Diagnosis step 1.1: Check Google Postmaster Tools

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:

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.

Diagnosis step 1.2: Check blacklist status

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:

Diagnosis step 1.3: Check spam complaint rate

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.

Per Gmail Sender Guidelines, spam complaint rates above 0.1% are in the "watch" range; above 0.3% Google begins throttling delivery.

Diagnosis step 1.4: Check authentication records

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:

• SPF: Check via MXToolbox SPF Lookup (mxtoolbox.com/SPFRecordLookup.aspx) — verify the domain's SPF record includes the sending server's IP or Inframail's SPF include directive
• DKIM: Check via MXToolbox DKIM Lookup — verify the DKIM record exists and is correctly formatted for the sending inbox provider
• DMARC: Check via MXToolbox DMARC Lookup — verify the DMARC policy record exists (at minimum "v=DMARC1; p=none")

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.

Diagnosis output

Step 2: Repair protocol by damage type

Repair path A: Authentication failure only (SPF/DKIM/DMARC missing or broken)

This is the fastest repair. Authentication records can be fixed in the domain registrar's DNS settings. Changes propagate in 24–48 hours.

Steps:

1. Log in to the domain registrar DNS settings
2. For Inframail-provisioned inboxes: log in to Inframail and retrieve the correct SPF include, DKIM TXT record, and DMARC TXT record for the domain
3. Add or replace the DNS records as specified by Inframail
4. Verify via MXToolbox within 48 hours
5. Resume production sends after all three authentication checks pass

Timeline: 24–48 hours for DNS propagation; 2–4 days to confirm deliverability improvement.

Repair path B: Low Postmaster reputation, no or minor blacklisting

This is the most common scenario for a domain that has been sending cold email above safe volume limits or with insufficient warmup.

Steps:

1. Pause all production sends immediately. No cold email from any inbox on this domain until reputation recovers.

2. 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.

3. Verify authentication records (Repair path A check) to rule out any authentication contribution to the reputation problem.

4. 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.

5. Submit delisting requests for any minor blacklist entries found in the MXToolbox check.

6. 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.

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

Repair path C: Moderate blacklisting (4–10 lists)

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:

1. Pause all production sends immediately.

2. Submit delisting requests for each blacklist the domain appears on. Each blacklist has its own delisting process:

   • Spamhaus: check.spamhaus.org → follow the delisting instructions for the specific Spamhaus list
   • Barracuda: barracudacentral.org/rbl/removal → submit removal request
   • SpamCop: spamcop.net → wait for the listing to expire (typically 24–48 hours after last complaint)
   • Other lists: each has a removal page accessible from the MXToolbox results

3. 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.

4. 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.

5. 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.

Repair path D: Severe blacklisting (10+ lists, including Spamhaus SBL)

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:

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

2. 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):

1. 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.

2. 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.

Step 3: Rebuild timeline

Step 4: Prevention

Every domain burn is caused by at least one of the following identifiable, preventable failures. The prevention checklist eliminates each cause.

Prevention checklist

Pre-campaign infrastructure checks:

• All sending domains are dedicated cold email domains (not the primary company domain)
• SPF, DKIM, and DMARC are configured on every sending domain and verified via MXToolbox before first production send
• All inboxes have completed a minimum 2-week warmup period before production sends begin
• Postmaster shows "High" or "Medium" reputation for all domains before campaign launch
• Daily send limit per inbox is set to 40–50 maximum (not higher)
• Production sends are ramped over 2–4 weeks (start at 15–20/inbox/day, increase by 5/week)

Pre-campaign contact list checks:

• Contact list was sourced from Quarvio (SMTP-verified) or has been SMTP-verified separately
• Contact list was cross-checked against suppression list and all previous campaign contacts removed
• Catch-all domain contacts (under 10% of list) have been segmented to a separate low-volume sub-campaign
• Spot-check of 20+ contacts confirms all are ICP-matched and have populated personalisation fields

Ongoing monitoring:

• Google Postmaster Tools checked for all domains daily during active campaigns
• Spam complaint rate alert set (Postmaster alert or manual review) for any rate above 0.1%
• Bounce rate in Instantly monitored weekly; alert if above 2% for any campaign
• MXToolbox blacklist check run monthly for all active sending domains

Response protocol:

• If spam complaint rate above 0.3%: pause all production sends on affected domain immediately
• If bounce rate above 5%: pause campaign immediately and audit contact list
• If Postmaster drops to "Low": switch to warmup-only mode; do not run production sends
• If any blacklist entry detected: submit delisting request within 24 hours

Domain recovery configuration reference

Advanced domain health tactics

Tactic 1: Use a dedicated monitoring domain for daily Postmaster checks

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.

Tactic 2: Run a monthly "canary send" to warm contacts

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.

Tactic 3: Maintain a "domain health log" for each sending domain

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.

Tactic 4: Stagger production ramp for new domains added during scaling

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.

Tactic 5: Build a "reserve domain" pool

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

Troubleshooting domain recovery

Problem 1: Postmaster reputation is not recovering after 4 weeks of warmup-only mode

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

Problem 2: Delisting request was submitted but domain is still on the blacklist 2 weeks later

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.

Problem 3: Recovery appears to be working (Postmaster shows Medium) but reply rate is still low

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.

Problem 4: Authentication records were checked and all pass, but emails are still going to spam

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.

Problem 5: New domain and inboxes are burning quickly (within 2–3 weeks of production start)

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.

Problem 6: Recovery is complete but the same domain burns again in the next campaign

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

Problem 7: Recovery is taking too long and campaigns need to restart sooner

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.

Problem 8: Deciding between recovery and retirement for a badly burned domain

Decision framework:

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.

Community evidence

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

Our actual stack

Frequently asked questions

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 →