How to warm up a new email sending domain

You registered a fresh domain, pointed the DNS, sent your first campaign, and half of it landed in spam. The domain has no history, so mailbox providers treat it as guilty until proven trustworthy.

Warming up a new sending domain means starting at low daily volume and increasing it gradually, over roughly 4 to 6 weeks, while keeping recipients engaged and complaints near zero. A brand-new domain has no reputation. Gmail, Outlook, Yahoo, and the rest cannot tell a legitimate sender from a spammer who just registered acme-deals-2026.com an hour ago, so they default to suspicion: low send caps, aggressive filtering, and a spam folder placement until you prove otherwise.

This guide walks the warmup the way you would do it by hand: the schedule, the signals providers actually score, and the mistakes that reset your progress. It is honest about the tedium, because the tedium is the point. At the end, I will show how a Cloudflare-native stack paces sends so you do not babysit a spreadsheet, but the schedule below works regardless of what you send through.

What does warming up a domain actually mean?

Warming up a domain means building sending reputation by ramping volume slowly while demonstrating that humans want your mail. Reputation is a score that each mailbox provider keeps about your domain, derived from how recipients react to what you send. A new domain starts at zero, which is functionally negative: no signal means no trust.

The mechanism is straightforward. When you send from an established domain, the provider has months of history saying "mail from this domain gets opened and rarely reported." When you send from a new one, there is no history, so a sudden burst of a few thousand messages looks exactly like a spam cannon. Providers respond by rate-limiting (deferring your mail with a temporary 4xx SMTP response) or by filing it under spam to see whether anyone digs it out.

Warmup defuses that by making your early sends small, consistent, and well-received. Every clean send adds a little signal: this domain sends mail that people open, reply to, and do not report. After a few weeks of that, the provider raises your effective send caps and stops reflexively filtering you.

Two things to internalize before the schedule:

• Reputation is per-provider. Gmail's view of your domain is separate from Outlook's. You can be golden at Gmail and throttled at Outlook on the same day. Warm up against all of your major recipient providers, not just the one you use yourself.
• Reputation decays. A warm domain that goes silent for a few weeks cools off. Warmup is not a one-time gate; consistent volume is what keeps the score up.

How long does warming up a new domain take?

Plan for 4 to 6 weeks to reach a few thousand messages a day, and 6 to 8 weeks for tens of thousands. The exact duration depends on your target volume and your engagement rates, not on a fixed countdown. If your recipients open and reply, you can ramp faster. If complaints creep up, you stretch the schedule out.

The reason it cannot be rushed is that providers score trends, not single days. They want to see a smooth, predictable increase that looks like an organic, growing business rather than a list bought yesterday. A domain that jumps from 50 to 50,000 in a week reads as a compromised or throwaway sender no matter how clean the content is.

Here is a concrete reference ramp for a target of roughly 5,000 messages/day. Treat the daily numbers as ceilings, not quotas: if you have less mail to send on a given day, send less.

Day range	Daily volume ceiling	Send to
1-3	50	Most engaged recipients only
4-6	100	Most engaged recipients
7-10	250	Engaged recipients
11-14	500	Engaged recipients
15-18	1,000	Engaged + recently active
19-24	2,500	Active recipients
25-32	5,000	Full active list
33+	Scale as needed	Full list, monitor reputation

Notice the shape: roughly doubling every 2 to 3 days early on, then easing as the numbers get large. The early days are where reputation is most fragile, so they stay smallest.

What is the difference between IP warmup and domain warmup?

IP warmup builds the reputation of the sending IP address; domain warmup builds the reputation of your from-domain and DKIM signing domain. They are scored separately, so you can have one warm and the other cold at the same time.

This distinction trips up people who move to a shared sending service and assume warmup is handled. On a shared IP pool, the provider has already warmed the IPs, so IP reputation is established. But your from domain and the d= domain in your DKIM signature are still brand-new, and mailbox providers track domain reputation independently. A new domain on a warm shared IP will still get filtered until the domain earns trust. The schedule in this guide is a domain warmup, which is what matters on Cloudflare-native and HTTPS-API senders where you do not control a dedicated IP.

If you are on a dedicated IP, you warm both simultaneously, and the IP is usually the slower of the two to forgive a volume spike, so pace to the IP.

What do you do before you send a single warmup email?

Get authentication passing first. SPF, DKIM, and DMARC must all validate on day one, because a warmup ramp on an unauthenticated domain builds nothing. Providers will not credit reputation to a domain whose mail they cannot cryptographically tie back to you.

Concretely, publish these DNS records before the first send:

; SPF: authorize your sending source
example.com.  TXT  "v=spf1 include:_spf.yoursender.example ~all"

; DKIM: publish the public key your sender signs with
selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEB..."

; DMARC: start in monitor mode so you see failures without blocking mail
_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; fo=1"

Verify each one actually resolves and passes before sending. A quick check from the command line:

# Confirm the records exist
dig +short TXT example.com | grep spf1
dig +short TXT selector1._domainkey.example.com
dig +short TXT _dmarc.example.com

If dig returns nothing, the record has not propagated or has a typo, and you are not ready to send. The full record-by-record setup is its own topic; see the SPF, DKIM, and DMARC setup guide for the details, and how to confirm authentication is actually passing at the receiver rather than just present in DNS.

Start DMARC at p=none (monitor only) during warmup so a misconfiguration does not silently bin your mail. Tighten to quarantine and then reject after you have read a couple of weeks of clean aggregate reports.

Who should you send to first during warmup?

Send to your most engaged recipients first: people who opened or clicked your mail recently on your old domain, or who explicitly signed up and confirmed. Engagement is the single strongest reputation signal, so you want your earliest sends to generate the best possible open and reply rates.

This is the part automated warmup tools cannot fake well. The goal is not to hit a volume number; it is to teach each provider that mail from your domain gets wanted. Concretely:

• Segment by recency. If you have engagement history, send first to people who opened in the last 30 days, then 90 days, then expand. If you do not have history (genuinely new list), send first to people who double-opted-in most recently.
• Never start with a stale list. A list you have not mailed in a year is full of dead addresses and spam traps. Sending to it on a new domain is the fastest way to torch a warmup, because high bounces and complaints early on are catastrophic.
• Prefer mail that invites a reply. Onboarding sequences, confirmations, and one-to-one-feeling messages generate replies, and replies are a strong positive signal. Save the big broadcast for after the ramp.

The number to watch is the complaint rate. Keep it under 0.1% (one complaint per thousand messages). Bulk-sender rules at Gmail and Yahoo now treat 0.3% as a hard ceiling that gets you blocked, so during warmup you want a comfortable margin below that. If complaints spike, stop expanding and figure out why before you continue. The mechanics of catching complaints early are covered in handling bounces and suppression.

Should you separate transactional and marketing mail during warmup?

Yes. Put transactional mail (receipts, password resets, confirmations) and marketing mail (campaigns, newsletters) on separate subdomains, and warm them independently. Mixing them means a single bad campaign drags down the reputation that delivers your password resets, which is the worst possible failure.

The standard pattern is to send transactional from something like mail.example.com and marketing from news.example.com or e.example.com, each with its own DKIM key and its own warmup ramp. Transactional mail usually warms faster because it has naturally high engagement (people open their receipts and reset links), so it is a good first stream to bring online. The full reasoning is in why you separate transactional and marketing sending, and it pairs with the deliverability fundamentals in the email deliverability guide.

A related trap: do not run cold outreach from your warmed domain at all. Cold email earns complaints by design, and complaints are exactly the signal that destroys reputation. Keep it on a throwaway domain you are willing to burn.

How do you know warmup is working?

Watch three numbers daily: complaint rate, bounce rate, and inbox placement. If complaints stay under 0.1%, bounces under 2%, and your seed tests land in the inbox rather than spam, the ramp is healthy and you can keep doubling. If any of those degrades, hold volume flat until it recovers.

Practical monitoring during the ramp:

• DMARC aggregate reports tell you whether your authentication is passing at real receivers. Read them weekly; a sudden drop in the pass rate means something broke.
• Seed inbox tests (sending to addresses you control across Gmail, Outlook, Yahoo) show actual folder placement, not just acceptance. Acceptance with a 250 OK does not mean the inbox; it can still be spam.
• Provider postmaster tools (Google Postmaster Tools, Microsoft SNDS) give you the provider's own view of your domain reputation. Set these up on day one; they are free and they are the closest thing to seeing your own score.

If everything stays green for a couple of weeks at your target volume, the domain is warm. Keep sending consistently to hold it there. If you stop for a few weeks, expect to do an abbreviated re-ramp when you start again.

Or skip the spreadsheet: let the stack pace it

Everything above is a manual discipline: track yesterday's volume, decide today's ceiling, segment by engagement, watch complaints, and resist the urge to blast the full list early. It works, and if you are sending through any provider it is worth doing by hand. But it is exactly the kind of bookkeeping that a system should run for you.

Tinbox is a self-contained email stack you deploy onto your own Cloudflare account: D1 for storage, R2 for attachments, Queues for sending, all on your infrastructure. Because the campaign sender runs on Cloudflare Queues, sends are already batched and paced rather than fired in one burst, which is the natural substrate for a warmup ramp. You own the data and the from-domain, so the reputation you build is yours and does not reset if you change vendors, because there is no vendor to change. Transactional and marketing streams are designed to run as separate sending domains, so the separation this guide recommends is the default shape rather than something you bolt on. And there is no per-recipient pricing, so a slow, careful warmup to a large list does not cost more than a reckless blast.

One honest caveat: Tinbox warms your domain on Cloudflare's HTTPS-based sending path. It does not magically grant reputation, and it cannot warm a domain you are also using for cold outreach. The schedule in this guide still applies; the stack just runs it instead of you.

Deploy this yourself: npx tinbox init example.com. The deploy walks you through the SPF, DKIM, and DMARC records you need in place before the first send, so you start the warmup authenticated. See the docs for the campaign scheduling and per-stream domain setup.