A practical email domain warm-up plan for permission-based senders: authenticate first, ramp engaged recipients, set pause rules, and separate domain reputation from IP warm-up.
Email warm-up is the controlled introduction of legitimate mail on a new or materially changed sending identity. You begin with recipients most likely to recognize the message, increase volume only while delivery signals remain healthy, and stop when the evidence says the next increase would be reckless. The goal is not to manufacture replies or trick spam filters. It is to let mailbox providers observe consistent, wanted traffic.
Warm-up matters after moving providers, creating a new sending subdomain, adding a dedicated IP, or making a large change in volume or mail stream. It cannot repair a purchased list, weak consent, deceptive content, or broken authentication. Fix those causes before adding volume.
Domain warm-up and IP warm-up are related—not identical
LAYER WHAT CHANGES WHAT TO CONTROL
Visible From domain Brand recipients see consent, recognition, content
DKIM signing domain Authenticated domain reputation alignment, stable selectors
Return-Path domain Bounce identity and SPF alignment SPF, DMARC alignment, handling
Sending IP Network reputation shared/dedicated choice, volume
Mail stream Transactional vs marketing behavior separate subdomains and policies
Recipient cohort Who sees the first sends recency, engagement, expectationA domain can be new while an email provider's shared IPs are established. A dedicated IP can be new while the domain already has history. Amazon SES documents dedicated-IP warm-up as a gradual increase on the new IP, but a domain warm-up also depends on the aligned domains, audience, content, and complaint behavior. Do not use the terms as if they describe one interchangeable score.
Before day one: make the sender ready
- Publish SPF for the actual Return-Path path and DKIM for every platform authorized to send.
- Start DMARC at a policy and reporting posture your organization can operate; verify visible From alignment.
- Use a recognizable From name, a monitored reply path, and a stable sending subdomain.
- Separate marketing from critical authentication, billing, and account messages when their audiences and failure budgets differ.
- Process permanent bounces, complaints, and unsubscribes immediately across retries and campaigns.
- Remove invalid, role, stale, unconsented, and acquired addresses instead of using the ramp to test them.
- Set up Google Postmaster Tools and the provider dashboards or webhooks you will actually inspect.
- Write explicit advance, hold, and rollback rules before launch pressure can override them.
Google's current sender guidance calls for authentication, low spam rates, gradual volume increases, and mail only to people who want it. Bulk senders have additional SPF, DKIM, DMARC, alignment, TLS, and one-click unsubscribe requirements. Treat those controls as baseline operations, not tasks to add after the warm-up fails.
A practical four-stage email warm-up plan
STAGE RECIPIENTS DECISION
1 Recent active users; necessary product mail Establish clean baseline
2 Recent clickers/readers with clear permission Advance only if signals hold
3 Broader active permissioned audience Hold on deferrals or drift
4 Normal eligible audience and forecast volume Continue ongoing monitoring
At every stage: authenticate -> send -> observe -> advance, hold, or roll back.
Do not add old, purchased, scraped, or never-confirmed addresses at any stage.Stage 1: establish a clean baseline
Begin with necessary transactional mail and a small set of recently active subscribers who will recognize the sender. Confirm that SPF, DKIM, and DMARC pass on real received messages; links and unsubscribe actions work; the reply address is monitored; and delivery events arrive in your system. Segment results by provider because a healthy aggregate can hide a Gmail- or Microsoft-specific problem.
Stage 2: expand by recency and real engagement
Add recipients who recently clicked, purchased, signed in, requested an alert, or otherwise demonstrated a relationship appropriate to the message. An open alone is a weak signal because privacy protections and image blocking distort it. Preserve the promise made at collection: product users are not automatically newsletter subscribers.
Stage 3: broaden while keeping a control cohort
Increase volume in predictable steps, but retain a stable cohort so you can distinguish a reputation change from a weaker audience segment. Avoid changing the domain, provider, list source, template, cadence, and volume on the same day. If performance moves, you need to know which variable moved it.
Stage 4: reach normal volume without a launch spike
A successful warm-up ends in sustainable sending, not a one-day blast. Move toward the normal weekly shape, including the weekday and hourly peaks your product will produce. If a launch would greatly exceed the observed baseline, extend the ramp or divide the announcement into relevant cohorts instead of treating the final warm-up day as unlimited permission.
How fast should you increase email volume?
There is no universal daily multiplier. Starting reputation, IP model, audience quality, mailbox mix, normal volume, message class, and provider feedback all change the answer. AWS notes that dedicated-IP warm-up commonly varies by sending pattern and can take weeks; its managed standard warm-up follows its own schedule. That is evidence against copying somebody else's calendar as a guarantee.
Use a forecast as a ceiling, then gate each step with evidence. Email Bump's warm-up calculator can turn a starting volume, target, and growth assumption into a planning table, but the operational decision still comes from live signals.
Advance, hold, and rollback rules
- Advance when authentication is stable, permanent bounces are understood, complaint signals remain low, and provider-specific deferrals are not rising.
- Hold when data is incomplete, one mailbox provider deteriorates, throttling grows, or a newly added cohort performs materially worse.
- Roll back when complaints spike, a block appears, authentication breaks, an unknown list source enters the send, or hard bounces reveal poor collection.
- Investigate before resending deferred mail; blind retries can turn a temporary rate signal into sustained pressure.
- Record the exact cohort, template, domain, IP pool, and hour for every step so the decision is reproducible.
Google tells senders to keep spam rates reported in Postmaster Tools below 0.1% and avoid reaching 0.3% or higher. Those are not targets to spend. Use a much lower internal warning level, assess the absolute complaint count and cohort, and remember that complaints are delayed and incomplete.
What email warm-up should never include
- Networks of inboxes that automatically open, reply, star, or rescue messages from spam.
- Purchased, scraped, appended, or partner-shared addresses used to create volume.
- Unrelated promotional content mixed into receipts or security messages to borrow their engagement.
- Random daily volume whose only purpose is to resemble human behavior.
- Resending to hard bounces, complainers, or unsubscribed recipients.
- Switching domains whenever reputation falls instead of correcting the underlying acquisition and sending behavior.
Frequently asked questions
Do new email domains need warming up?
A new sending identity should introduce wanted mail gradually when meaningful volume is expected. Very small products may warm naturally through ordinary user activity. The important behavior is consistent authentication, permission, suppression, and volume—not completing a ceremonial schedule.
Can I warm up a domain with cold email?
Cold outreach and permission-based subscriber or product mail create different consent and reputation risks. This guide does not recommend automated engagement, scraped addresses, or invented conversations. A warm-up cannot make recipients expect mail they did not request.
Should transactional and marketing email warm up together?
Usually they should have distinct streams, policies, and often subdomains, because a marketing mistake should not endanger password resets or receipts. They may share some infrastructure, but track and control each stream separately.