How to warm up a new sending domain, and the twenty-nine minutes that taught us why

To warm up a new sending domain is to send a small volume on its first day and roughly double it daily until mailbox providers have enough history to judge you by. Everybody in email knows this. We knew it. What we did not have was anything in the platform that enforced it, and this is what that cost, with the numbers.

Twenty-nine minutes

The domain is the marketing subdomain of one of Common Ninja's five products — a newsletter identity, freshly verified, with its transactional traffic on a separate subdomain as always.

Ninety per cent of that went to one provider.

Every provider took all of it except Gmail. The campaign reported a 1.4% open rate — 180 unique openers against 13,258 delivered — which is the same fact seen from the other end: most of the Gmail half was filtered rather than read. Days later, mail from that domain was still being classified as spam.

One aside, because it is a trap worth naming. The campaign also reported 131 unique clickers, and about 123 of them clicked every link in the message, including two near-identical pages. That is security-gateway prefetch, not people. A 73% click-to-open ratio is not a human audience. We did not use those clicks for anything, and neither should you.

The number that actually mattered

Google's Postmaster Tools snapshot for the organisational domain, dated 8 September — the day before the campaign — was compliant on every line but one. SPF and DKIM authentication, From: alignment, DMARC, encryption, DNS, one-click unsubscribe, honouring unsubscribe: all compliant. The exception:

User-reported spam rate — Needs work. Keep below 0.3%.

The blast did not create the problem. It amplified one that was already over the line. That is the honest reading, and it is why we stopped chasing the message content: three genuine defects were found and fixed in the same two days — a tracking pixel on a shared third-party host, campaigns going out as single-part HTML with no plain-text alternative, a remote stylesheet reference the clients could not use — and not one of them moved the outcome.

Google's own diagnosis on the same page named the actual causes:

Common reasons for this are a new domain, a restart in sending after a pause, or a large percentage of messages sent to inactive accounts. Recommended action: continue to send at a steady rate, and don't increase sending volume too quickly.

All three applied at once. A warm-up ramp fixes exactly one of them — and it would not have made a stale list into a good one. What it would have bought is six days between the first message and the eighteen-thousandth: six days of bounces, complaints and silence arriving as signal, at a volume small enough to act on, instead of as a verdict.

Nothing in the platform stopped it

Two limits existed. Neither was relevant.

The first is a per-second send rate that paces the whole account. It is real, it is enforced in one place for every sending path, and it knows nothing about which domain the mail is leaving from. The second is the monthly allowance on the workspace plan, which is billing.

Neither has any notion of a domain being new. Every tenant who adds a subdomain could have done precisely this. The only reason it was our own product is that we got there first.

The ramp

Each identity now has a daily ceiling on marketing volume for its first fourteen days:

200 · 500 · 1,000 · 2,500 · 5,000 · 10,000 · 20,000
40,000 · 75,000 · 125,000 · 200,000 · 300,000 · 500,000 · 750,000

The shape matters more than the exact numbers. Start small enough that a bad list shows up as bounces before it shows up as a reputation loss, and grow slowly enough that engagement signals accumulate. The 18,113 above would have drained in six days.

Day one is the first send, not the day DNS verified

The ramp is anchored on an identity's first send, not on when it was verified.

This is the part that is easy to get wrong, and getting it wrong quietly disables the whole feature. A domain verified a month ago and never used is exactly as cold as one verified this morning, because mailbox providers judge sending history, not DNS records. Anchor the ramp on verification and a sender can add a domain, wait two weeks, and start on "day 15" of a ramp they never walked — with no history at all, which is the state the ramp exists to protect.

A cap that pauses instead of refusing

A campaign that runs out of warm-up budget does not fail. It goes paused with its remainder still pending, and the next day's run resumes at the next step of the ramp. One large campaign therefore spreads over days.

That is the warm-up. The implementation is mostly a schedule plus one more reason to pause — it reuses the same path as running out of sending quota, because the useful behaviour was already there.

Which makes the wording in the dashboard load-bearing. A warm-up pause is the intended outcome, not a degraded one, and the campaign page says so; offering a bare "continue it now" button next to a scary yellow banner invites a sender to undo the one thing protecting their domain. Campaigns are not the only way to send at volume, so the same ceiling is enforced a second time at the last point before the provider, for marketing mail that is not part of a campaign — an automation draining a sequence, or an API key in a loop. The two are scoped so they can never both count the same message.

Transactional is never capped

A password reset cannot wait for tomorrow's step.

It does not have to, because it leaves from a different subdomain with a different reputation and a different configuration set. That split is the whole reason transactional and marketing are separate identities here, and this is the day it pays for itself: the marketing domain was in a hole for a fortnight and not one password reset was delayed.

The corollary is a rule, not a suggestion. Never move marketing onto the transactional identity to get around a warm-up cap. It trades a paused campaign for the one mailbox that must never be filtered.

What a ramp does not fix

The list. Ours told people they were receiving it "because you have an account", and an account list is not a subscription — that is where a spam rate over 0.3% comes from, and no pacing schedule repairs it.

So the recovery is not a deploy. It is: stop sending; rebuild the audience from people who actually opened something in the last ninety days, which on a 1.4% measured open rate is hundreds, not thousands; restart at 200 a day and hold at each step until the spam rate is under 0.10%; widen only after reputation has held for two weeks. And do not spin up a fresh subdomain to escape it — Google weighs the organisational domain, so a new one inherits the problem and splits the reputation you are trying to rebuild.

Reputation is earned over weeks and lost in an afternoon. It is the one deliverability mistake with no cheap recovery, which is why this is now on by default for every new identity, rather than a paragraph in the docs telling you to be careful.