Ahosting Logo
Knowledge Base

How to Warm Up a New Sending Domain

A new domain has no history, and history is what is judgedStart smallto your most engagedrecipients firstIncrease graduallyover days and weeks,not hoursWatch the signalsbounces, complaints,and whether opens holdupSlow down on a bad signalrather than pushingthrough itA sudden large send from an unknown domain looks exactly like the thing filters are built to stop.

A new domain, or a new sending address on an existing one, has no history. Receiving systems judge senders largely by history, so the first messages are judged cautiously and the first large send is judged harshly.

Records first, before any message

SPF, DKIM and DMARC must be in place before the first message goes out.

Mail sent without them does not simply arrive unverified: it starts building a reputation from a worse position than no history at all, and adding the records afterwards does not undo the impression.

Understanding SPF, DKIM and DMARC explains writing them. Start DMARC in its reporting mode rather than rejecting, so you can see what is happening before enforcing anything.

Increase gradually

The principle is simple: small volumes, growing over several weeks.

A workable shape is tens of messages in the first days, then hundreds, then thousands, roughly doubling every few days while watching what happens. Two weeks to reach a few thousand a day is unremarkable; two hours is not.

What matters is not the exact schedule but that the growth is visible and steady rather than a step change.

Send to people who want it first

Engagement is a positive signal. Opens and replies tell receiving systems that recipients want this mail; deletions without opening and complaints tell them the opposite.

So the first sends should go to your most engaged recipients, recent customers, people who signed up this month, colleagues who will actually reply.

Sending first to the oldest, least engaged part of a list is the most common way a warm-up fails, and it is the exact opposite of what people instinctively do with a new system.

Clean the list before starting

Addresses that no longer exist are one of the clearest signals that a sender is not maintaining their list, and a new domain has no goodwill to absorb it.

Remove anything that has hard-bounced before, and anything that has not engaged in a year unless you have reason to believe it is real.

Never start a new domain on a purchased or scraped list. That combination (no history, high volume, unengaged recipients) produces a domain that is effectively unusable within days, and the damage follows the domain instead of the campaign.

Understanding bounces and delivery codes explains acting on the results.

Watch, and slow down when it worsens

Read the reporting after each increase: delivery rate, bounces, complaints, and whether messages are landing in inboxes rather than spam folders.

If any of them worsens, stop increasing and hold at the current volume until it recovers. Continuing to grow through a deteriorating signal is what turns a slow start into a lasting problem.

A relay service provides this reporting directly. Sending application email through a relay service explains setting one up, and it is the practical way to see any of this.

Separate the streams

Transactional mail and marketing mail should not share a sending identity.

Password resets have very high engagement; marketing has lower engagement and generates complaints. Mixing them means the marketing damages the deliverability of the mail people genuinely need.

Use a subdomain for one of them, typically marketing on something like news.example.com, so their reputations are tracked separately. This also protects the main domain if a campaign goes badly.

A new address on an established domain

Easier, because the domain's reputation already exists and largely carries.

Still worth increasing gradually, and still worth checking the address is not sending to a list that has never received anything from your organisation before.

Reputation decays

A domain that sends nothing for months is not quite a new domain, and it is not a warm one either. Resuming at previous volumes after a long gap can be treated like a new large send.

Regular modest sending maintains it better than occasional bursts. Sending a newsletter properly goes into the ongoing practice.

Watch the reports rather than the send count

Warming up is judged by how the mail is received, and the aggregate reports are the only view of that.

dig _dmarc.example.com TXT +short
dig example.com TXT +short | grep -i 'v=spf1'

Set the reporting address before the first message, not after the first problem. The reports arrive daily and they show which receiving systems accepted the mail and which did not, per source.

What you are looking for during a warm up is a pass rate that stays high as volume rises. A rate that falls as you increase means the increase is too fast, and the correct response is to hold at the previous volume rather than to push through.

The bounces tell you when to stop

Two figures decide whether a warm up is going well, and both come from what comes back.

exim -bp | wc -l
grep -c 'rejected' /var/log/exim_mainlog 2>/dev/null
grep -oiE '5\.[0-9]\.[0-9]' /var/log/exim_mainlog 2>/dev/null | sort | uniq -c | sort -rn | head

A permanent refusal means the address does not exist and it should be removed from the list immediately. A temporary one means the receiving system is throttling you, which is the signal to slow down.

Sustained temporary refusals from one large provider while others accept normally is the classic warm up signal. Continuing at the same volume turns a throttle into a block, and a block takes considerably longer to clear than the delay would have cost.

Keep the transactional mail away from the rest

Receipts, password resets and order confirmations are the mail that must arrive, and mixing them with anything promotional puts them behind the same reputation.

Send them from a separate subdomain with its own authentication, so a marketing campaign that attracts complaints cannot affect whether a customer receives their password reset.

dig mail.example.com TXT +short
dig send.example.com TXT +short

The separation has to exist in the records rather than only in the sending system, since that is what receiving systems evaluate. Two subdomains with independent authentication are two independent reputations, which is the entire point. Stopping your domain being used for spoofing covers the records.