The deliverability mistakes that burn domains in a week

A sending domain takes weeks of disciplined behaviour to build and can be destroyed in under seven days, because reputation damage is asymmetric: providers extend trust slowly and withdraw it fast. The mistakes that do the burning are a short, predictable list — volume spikes, unverified data, missing authentication, sending from the main company domain — and every one of them is preventable by design rather than vigilance. Here is the list, and the failure sequence that connects them.

Why can a domain burn so fast?

Because filtering systems are built to catch compromised accounts and spam operations, both of which announce themselves through sudden behavioural change. A domain that has sent 30 emails a day for weeks and abruptly sends 400 looks hacked; a domain bouncing 8% of its mail looks like it's working through a scraped list. The filters act in hours, not quarters — and as the Cold Email Deliverability guide sets out, the score they act on is the accumulated asset your entire outbound operation stands on.

The asymmetry is the design: trust is expensive to earn precisely so that it's expensive to fake. Which means prevention is cheap and cure is not.

The seven mistakes, in order of how often we see them

1. Sending to an unverified list. The single fastest burn. Dead addresses hard-bounce, bounces are logged, and a 6–8% bounce rate can push a domain into filtering territory within days.
2. Spiking volume. Going from 30 to 300 sends overnight — usually after "the campaign is working, let's scale". Scale comes from more mailboxes, not louder ones; each inbox holds at 25–40 cold emails a day.
3. Skipping authentication. No SPF, DKIM or DMARC means every filter meets you as a stranger who can't prove identity. Increasingly this isn't a penalty but a bar to entry.
4. Sending cold email from the main company domain. This converts a contained risk into an existential one: when the domain burns, invoices, proposals and support all burn with it. Cold outbound lives on secondary domains, full stop.
5. Blasting one mega-send instead of steady dailies. Fifty emails a day for a month beats 1,500 on the first of the month, on identical totals — consistency is itself a scored behaviour.
6. Ignoring early signals. Bounce rate creeping up, replies sagging below 3% positive, placement tests slipping: the instrument panel was flashing for days before the mail stopped arriving.
7. Image-heavy HTML, link trackers and attachments. Cold email should look like a person wrote it, because filters score mail that looks like marketing as marketing.

How does the failure actually unfold?

The mechanism is a compounding loop, and it explains the "one week" in the title. When a bad input lands — say an unverified list — then bounces spike within the first sends. When bounces spike, then the domain's reputation drops and placement falls. When placement falls, then opens and replies collapse, and mail nobody engages with is itself negative evidence — so the score falls further. When the sender responds to the silence by sending more ("the campaign needs volume"), then every reinforcing signal accelerates, and by day five or six the domain is filtered nearly everywhere. When that loop has run its course, then recovery is no longer a tweak but a protocol — and sometimes a new domain.

Note the human step in the middle: the instinctive response to silence is more volume, which is precisely the wrong move. Systems beat instincts here, which is the recurring lesson of this cluster.

What does prevention look like as a system?

Not vigilance — design. Every mistake above can be made structurally impossible:

• Verification wired into the list pipeline, so unverified contacts physically can't be loaded.
• Sending-tool caps at 25–40 a day per inbox, so a spike requires deliberately removing a guardrail.
• Authentication checked at domain setup, before the first warm-up email, as covered in why a warmed mailbox is worth more than a bigger list — warming and authenticating are the constructive twin of this article's destructive list.
• Secondary domains only, with the main domain never connected to any cold-sending tool — related to, but distinct from, the reasons you don't send cold email from your main ESP.
• A weekly monitoring habit: bounce rate, positive-reply rate, placement score.

Built this way, deliverability stops depending on everyone remembering everything, which is the only version that survives contact with a busy firm.

The founder pattern behind the burns

Most burned domains we encounter share a backstory: outbound was run personally by the founder, part-time, between everything else — and the guardrails above were "known" but not installed. Under time pressure, known-but-not-installed always loses. That is less a deliverability observation than a business-design one, and it's the territory of the Founder-as-Bottleneck Report: activities that punish inconsistency should not depend on the busiest person in the company behaving consistently.

Burn a domain once and you lose weeks. Design the system so it can't burn, and the whole question becomes boring — which, in deliverability, is the win condition.

---

Next step: the Growth System Audit — £450, seven days, credited against any build — maps where your growth system leaks and what to build first.