A burned sending domain is one whose reputation has degraded to the point that mailbox providers filter it aggressively, and the tricky part is that it never announces itself. There is no email from Google saying "your domain is finished." It's a gradual, quiet slide: replies stop, opens drop, and the messages that do land sit in spam or promotions rather than the inbox.
Most teams find out late, because the signals are easy to misread. A reply-rate dip looks like a targeting problem. A deliverability drop looks like a content problem. And by the time it's unmistakable, the domain has been accumulating reputation damage for weeks.
Knowing what burned-domain behavior actually looks like is what separates a fixable problem from a slow-motion one.
What "burned" means technically
A domain's reputation with mailbox providers is built from many signals, but the ones that matter most are consistent across the major providers: the volume you send, the authentication status of that mail, and — most of all — how recipients respond.
Recipient response is the load-bearing one. Every provider counts how often your recipients hit the spam button, mark you as junk, or never open your mail. When the complaint rate climbs past the point providers consider acceptable — commonly cited as roughly 0.3% of sends — your domain's reputation takes a hit that takes a long time to recover. If the complaints keep coming, that reputation is rebuilt downward until a meaningful share of your mail is filtered before it ever reaches an inbox.
That's what a burned domain is: a domain whose reputation has been driven below the level where it can carry sending volume reliably. It isn't a technical failure. It's a trust failure, and trust isn't restored by waiting.
The quiet signs, in order of how early they show
Burn rarely happens overnight, and the earlier signs are subtle:
Reply rates decline before opens do. Replies are the most sensitive signal, because a reply requires the recipient to have read, decided, and acted. When deliverability starts slipping, the least-engaged messages are the first not to reach inboxes, and those are disproportionately the ones that would have been ignored anyway. The replies you still get come from a pool that's slightly narrower than before, so the drop can look like a mild targeting drift rather than a deliverability problem. Opens drop but the sender-side dashboard looks fine. When you send from a domain that's being filtered, your sending infrastructure still reports the messages as delivered to the provider. The provider accepted them; it just put them somewhere the recipient isn't looking. So the metric that goes silent is the recipient-side one — opens and clicks — while your sent count stays flat. That mismatch, sent-count steady while engagement slides, is the classic early signature. Spam complaints tick up as a percentage even if volume is unchanged. This is often the mechanism driving the decline rather than a symptom of it, and it compounds: more spam-button hits push reputation down, which pushes more mail to spam, which puts it in front of people who are already annoyed, which produces more complaints. You start seeing the same complaints from people you'd expect to be receptive. When your best-fit prospects — the ones genuinely in your ICP, who should plausibly want to hear from you — are the ones complaining, the targeting isn't the problem. Real recipients are reacting to the message arriving in the wrong place. Authentication starts failing sporadically. A domain under suspicion can have its DMARC alignment evaluated more strictly. You'll see occasional auth failures on mail you know you sent, which is the provider's way of scrutinising the domain harder rather than a config error you haven't noticed.How to confirm it before you blame the wrong thing
Diagnosis is a process of elimination, because most of these signs have an innocent explanation:
- Verify you're actually reaching the inbox. Send a test message to a handful of inboxes you control across the major providers and check placement, not just delivery. Tools that report inbox vs spam placement do this properly; your sending dashboard does not.
- Check authentication from the receiving side. Look at the raw headers of a message that landed in spam. If SPF, DKIM, and DMARC all pass and it's still filtered, the problem is reputation, not authentication.
- Look at complaint rate specifically, not bounce rate. Bounces are a different problem with different causes. The number that tracks burn is complaints, and your provider's dashboard should show it per domain.
- Isolate by domain. If you run multiple sending domains, compare their engagement. One domain down while the others hold is a domain-reputation problem; all down together is more likely infrastructure or content.
- Check the timeline. Burn correlates with a change: a big volume spike, a badly-targeted blast, a list from a cold-bought database, a stretch of unmonitored sending. If reputation started declining after a specific event, the cause is usually that event.
What can be saved, and what should be retired
The uncomfortable truth is that most recovery advice is really a bet on time, and time only pays if the behavior that caused the damage has stopped.
A mild decline can recover. If authentication is solid, you've stopped whatever caused the complaints, and you drop to a much lower, steady volume while the reputation rebuilds, a slightly-degraded domain can climb back over weeks or months. This is the warm-up cycle in reverse: slow, consistent, boring sending that demonstrates the domain isn't a spam source. A hard burn generally cannot. When a domain is so flagged that a meaningful share of mail is filtered even at low volume, recovery is not a matter of patience — it's a matter of the provider having classified the domain itself as a source of spam. That classification doesn't reset because you paused for a month, and it doesn't reset because you switched content. The honest answer is often to retire the domain and move sending to a fresh one.The cost of holding on to a burned domain is real and hidden: every message sent from it trains the provider's filters a little more, and every bounce or complaint is wasted spend on top of the reputation damage. Sometimes the cheapest fix is to stop spending the domain's remaining goodwill.
How to retire it properly
Retiring a domain isn't just pointing mail at a new one. The new domain inherits nothing automatically, which is the point — but it also inherits none of the mistakes, so don't recreate them:
- Set up the new domain correctly from day one. SPF, DKIM, and DMARC on the new domain, independently, before sending a single message.
- Warm it up. A fresh domain has no history, which means no reputation. Ramp from very low volume over weeks rather than starting at full send.
- Fix the cause first. A new domain sent at the same volume to the same bad list will burn just as fast. Whatever created the complaints — targeting, list sourcing, cadence — has to be corrected before the fresh domain goes to work.
- Keep a hard stop. Decide in advance what complaint rate or engagement floor means the new domain is also in trouble, so you don't repeat the slow-motion discovery.
The part that matters more than the infrastructure
Domain reputation is downstream of recipient response, and recipient response is downstream of targeting. A well-targeted list at modest volume rarely stresses a domain at all; a badly-targeted list burns one no matter how it's configured. Every infrastructure fix in this post is a floor, not a strategy.
The reason so many teams hit this is that they optimise the setup and inherit the list. The targeting problem is the one worth the most attention, and it's what [AutoReach](/register) is built around — finding businesses that genuinely match your ICP and scanning them for real context, so the people receiving your outreach have an actual reason to read it. Get that right and the domain-reputation question gets much easier, because you need a lot less of the infrastructure that burns.