Guide
Warming is the process of gradually increasing sending volume from a new IP address or sending domain, so that mailbox providers can build a reputation record from consistent, legitimate behavior. Sending high volume from a cold IP or domain looks like a compromised host or a spam operation, and the messages get throttled, filtered or rejected.
Last reviewed September 2026
The reason is easier to see from the receiving end. A mailbox provider decides what to do with a message using what it knows about the sender, and about a brand new IP address or domain it knows nothing. It has no delivery history, no complaint history, no engagement record. All it has is the traffic in front of it.
Traffic that appears suddenly, at volume, from a sender with no history is indistinguishable from the two things receivers spend most of their time defending against: a host that has been compromised and is now emitting mail on someone else's behalf, and a spam operation cycling through fresh infrastructure precisely because the old infrastructure got blocked. Neither of those looks any different from a legitimate business launching a new sending platform on day one.
Reputation is the record that resolves the ambiguity, and it can only be earned over time: delivery rates, complaint rates, bounce rates, and how recipients engage. Warming is how you produce that record deliberately rather than by accident. Start small enough that the receiver can evaluate you, stay consistent enough that the evaluation means something, and grow only as fast as the record supports.
The corollary is worth stating plainly, because it catches people out: a warming problem does not announce itself as a warming problem. It shows up as messages landing in spam, as deferrals that look like a receiver outage, or as a delivery rate that is fine on one provider and poor on another. By the time it is obvious, the record you were trying to build has been written.
The two get discussed as one activity because they usually happen at the same time, on the same new setup. They attach to different things and behave differently, and the difference decides what you actually have to do.
IP reputation attaches to the sending IP address. It stays with that address. Move to a different IP and you start over; sit on a shared pool and you inherit whatever the pool has already earned, along with whatever its other tenants do next.
Domain reputation attaches to the authenticated sending identity - in practice the DKIM signing domain and the key signing for it, not the domain string on its own. This distinction is the one most warming advice gets wrong, and it matters enormously in practice.
Anti-spam systems have moved away from simple IP blocklists and IP-level rate limiting toward domain-based reputation. The shift makes sense from the receiver's side: IP addresses are cheap, plentiful and easily rotated, so an IP-only defense mostly measures how recently a sender changed hosts. The DKIM-authenticated domain is what a sender actually has to keep, and it is what a receiver can hold responsible.
The practical consequence is the sentence most warming advice leaves out: a well-warmed IP address does not rescue a cold sending domain. If you spend four weeks carefully ramping volume on a dedicated IP while sending from a domain no receiver has ever seen authenticated that way, you have warmed the half that matters less.
The common claim that domain reputation simply follows your domain, so changing provider costs you nothing, does not survive contact with how receivers actually evaluate mail. Because the reputation is bound to the authenticated identity, a significant change to your DKIM signing changes what is being evaluated. Move to a new provider and you get a new DKIM keypair under a new selector, and the mail starts arriving from a different set of IPs at the same time. From the receiver's side that is a materially different sender presenting the same brand name.
So a provider change requires domain warming, not only IP warming. That is the opposite of the reassurance most migration content offers, and it is the more useful thing to know before you plan the cutover.
Routine key rotation is a different matter from a wholesale identity change, and worth handling so that it stays routine: Omnivery rotates DKIM keys through CNAME delegation rather than requiring a new record to be published for each rotation, so the signing configuration a receiver sees does not churn every time a key changes.
Side by side
The differences that decide what you actually have to do. The second row is the one that catches most senders out, and it is the opposite of what most migration advice says.
| IP warming | Domain warming | |
|---|---|---|
| Reputation attaches to | The sending IP address | The authenticated sending identity: the DKIM signing domain and its key |
| Survives a provider change | No - a new dedicated IP starts cold | No - new DKIM keys and new source IPs are a changed identity |
| Shared with other senders | Yes on a shared pool, no on a dedicated IP | Never - the signing domain is yours alone |
| Who normally manages it | The sending platform, on a shared pool | The sender, always |
| Effect of a volume spike | Throttling and deferrals from the receiver | Reputation damage that follows the domain anywhere |
| Effect of going quiet | A dedicated IP decays and needs re-warming | Decays more slowly, but engagement signals fade |
| Separable per stream | Yes - separate pools or dedicated IPs per stream | Yes - by DKIM key, sending domain or subdomain, and headers together |
| Weight in modern filtering | Declining - IPs are cheap and easily rotated | Primary - DKIM-authenticated domain reputation is what receivers lean on |
Because reputation is bound to the authenticated identity rather than to the domain string, a provider change is not the free move it is usually sold as. The new provider signs with its own DKIM keypair under its own selector, and the mail begins arriving from a different set of IPs. Both halves of what a receiver was evaluating have changed at once.
Plan a migration as a warm, then. The mechanical work of switching is genuinely small - compatible API endpoints mean most integrations move without code changes - but the reputation work is a ramp, and treating a fast technical cutover as permission for a fast volume cutover is how migrations go wrong. On a dedicated IP you are warming both sides from cold; on a shared pool the IP side is already established and the domain side still has to be rebuilt under the new signing identity.
This is the most common misreading of "the provider handles warming". A vetted shared pool means the IP reputation is already established and maintained for you. Your domain is still new to every receiver, and its record still has to be built. The pool gets your mail taken seriously enough to be evaluated; it does not do the evaluating for you.
Marketing and transactional mail should build separate reputation records, so that a campaign drawing complaints does not drag down the receipts and password resets. Subdomains are the mechanism usually named for this, and they do help - but a subdomain on its own is one signal, and it is not necessarily a stronger one than a separate DKIM key or a separate From address.
The reason to think in signals rather than in one switch is that every mailbox provider has its own recipe, and none of them publish it. One receiver may key its separation on the DKIM signing identity, another on the envelope domain, another on the IP range the mail arrived from, and the weightings change over time without notice. Betting the separation on the single mechanism a blog post recommended is a bet on a recipe you cannot read.
The robust approach is the opposite: separate on as many axes as you can, so the streams read as distinct under whichever recipe a given receiver happens to use. In practice that means distinct sending IPs, distinct DKIM keys, distinct sending domains or subdomains, and distinct message headers - the Message-Category, Precedence and List-Unsubscribe or List-Help values that mark a message as bulk or transactional, covered in the List-Unsubscribe guide.
Omnivery applies that separation on the customer's behalf: the streams run on distinct IPs, are signed with distinct DKIM keys, and carry distinct headers, with suppression state held per domain so a marketing unsubscribe never withholds a receipt.
The warming consequence is worth being clear about, because it is a real cost rather than a free win: every stream you separate is a record you have to build. Two streams properly separated means two warms, not one. For a sender running both marketing and transactional at volume that trade is almost always worth making. For a single low-volume stream, splitting it just to look tidy buys you two cold identities instead of one warming one.
SPF, DKIM and DMARC need to be published and passing before the first message, not phased in alongside the volume ramp. Authentication is how a receiver knows which domain to attribute the mail to in the first place. Warming an unauthenticated domain builds a record against nothing in particular.
This is what most people are looking for when they search for warming, so it is worth setting out - with the caveat that a day-by-day table copied from a blog post is worth very little. The right numbers depend on your list size, its quality, and which providers your recipients actually use. What generalizes is the shape, not the figures.
Do not treat any published schedule, including the shape above, as authoritative for your program. It is a starting hypothesis that your own delivery metrics will correct.
The schedule is rarely the problem. What fails is the assumption that a plan written on day zero survives contact with real sending.
None of that is an argument against warming. It is an argument for warming being enforced by the infrastructure rather than by somebody's diary.
Every sending domain on Omnivery has its own rate limit. It does two jobs at once: it protects the platform from a compromised or misconfigured sender, and it protects that sender's own reputation from the volume spike that would damage it. The limit increases by 20% once the domain reaches 75% of its current limit.
Reaching 75% is the trigger, not the whole test. The increase is not granted unconditionally just because the volume is there. The domain's sending health is assessed first - bounce rate, complaint rate and other delivery signals - and a domain whose numbers are deteriorating does not get more headroom on the strength of having used up what it already had. That is the difference between a growth ladder and a warming system: a ladder rewards volume, and this is paced against whether the volume is being received well.
The reason manual schedules fail is that holding volume when complaints tick up requires somebody to be watching complaints every day, at precisely the point in a launch when nobody is. Those are the same signals the rate limit is already evaluating, on every domain, without anyone having to remember.
The rest follows from that. Growth is tied to sending behavior and delivery health rather than to a calendar, so a sender who ramps slowly is never pushed faster than their own traffic justifies. Because the limit is a ceiling as well as a ladder, the unplanned spike that undoes most manual warms cannot happen in the first place. And when a genuine step change is coming - a campaign, a seasonal peak, a migration cutover - support can set a custom rate limit rather than leaving the sender to work around the system.
IP warming is handled by Omnivery as part of the managed infrastructure. Customers do not run IP warming schedules. The default recommendation is the vetted shared sending neighborhood rather than a dedicated IP, precisely because a dedicated IP has to be kept warm by consistent high volume and a cold one performs worse than a well-managed pool.
The rate-limit behavior is documented in the sending domain documentation, and the provider-switch path in the migration guide.
Migration content usually reassures you that your domain reputation comes with you. It is worth being straight about this, because the reassurance is wrong in the way that costs the most.
What changes: the DKIM keypair and selector, because the new provider signs with its own; and the source IPs, because the mail now leaves different infrastructure. Receivers evaluate the authenticated identity, so changing both at once presents them with a sender they have not assessed before, wearing a domain name they recognize. A provider change therefore needs a domain warm, not just an IP warm.
What still has to be moved deliberately: suppression state and complaint history. Those live with the old provider, and assuming they will follow is the classic migration mistake - it produces sends to addresses that already opted out or complained, at exactly the moment your new signing identity is being assessed. Omnivery's migration transfers suppression lists, bounces and unsubscribes.
What does not change: the domain itself, your SPF policy, and your DMARC record and alignment, which need updating for the new sending source but do not start over as a concept.
Send a small share of production traffic through the new provider first, hold it there long enough to see delivery and complaint data from your real recipients rather than from a test list, then increase. A phased cutover gives you a comparison against the old provider running in parallel, which is the only way to tell a genuine deliverability difference from normal daily variation. A hard switch gives you a step change with nothing to compare it against.
Watch delivery rate, bounce classification and complaint rate per receiving provider rather than in aggregate. A blended figure will absorb exactly the problem you are looking for.
The mechanical side is usually far smaller than the reputation side. Kiwi.com completed a full migration from SendGrid and Mailgun in 45 minutes with zero code changes, using the compatible API endpoints. That is the integration work, and it is worth separating from the ramp: the switch takes an afternoon, the warm takes weeks, and the only one of those you have to schedule is the one the platform handles for you. The provider comparison and the SendGrid alternative page cover the rest of what a switch involves.
Search for email warmup and most of the results sell something that has nothing to do with any of the above. These services generate synthetic messages, opens, clicks and replies between networks of accounts they control, and feed the resulting false engagement signals into the systems Gmail and Outlook use to decide whether a sender is legitimate.
How they attach to you varies, and the variants are not equally bad - they are bad in different ways. Some register domains resembling the customer's own and run the traffic there. Many go further and ask the brand to bring its real identity to the service: authenticate your own sending domain to them so they can sign as you, or hand over access to your ESP account so the synthetic traffic originates from your actual sending infrastructure. The closer to the source, the more convincing the fabricated signals are - and the more completely they attach to the identity you actually depend on.
Which is worth sitting with, because it inverts the usual assumption that this is a low-stakes experiment. If the vendor is signing with your DKIM key or sending from your ESP, the fake engagement is not happening next to your reputation. It is happening inside it.
There is a second exposure that has nothing to do with deliverability. Authenticating your domain to a third party, or giving one credentials to your sending platform, hands an outside company the ability to send as your brand and, depending on the access, sight of your recipient data. That is a security and data protection question before it is a deliverability one, and it is rarely the question these tools are evaluated on.
The distinction is not a matter of degree. Infrastructure warming earns a reputation record by sending real mail to real recipients who asked for it and letting their behavior be recorded. Synthetic warming fabricates that record. One produces evidence; the other produces the appearance of evidence, which is a description of fraud rather than of deliverability work.
M3AAWG - the anti-abuse working group whose members include Google, Microsoft and Yahoo, the organizations that actually decide whether your mail arrives - published its Position on Cold Email in November 2025. It leaves no interpretive room:
"Any attempts to bypass mail volume limits, avoid spam filters, mask sending domains, artificially simulate subscriber engagement, or use other tools or services that exploit loopholes in mailbox providers or cloud platforms are particularly egregious and are not acceptable in any manner."
M3AAWG, Position on Cold Email, November 2025
Until recently the argument against synthetic warming was that it does not work and might get you filtered. That has changed, and senders using these tools should understand what changed.
Validity operates the Heatwave domain blocklist, launched on 3 September 2026 and built specifically to identify this practice, which it calls deceptive reputation warming through synthetic messaging. That is the vocabulary worth searching if you are assessing a vendor. Heatwave carries over a million listed domains on a live counter that adds thousands a day, and it is used or being evaluated by Comcast, Proofpoint, Spamhaus and SURBL. If you suspect a vendor has done this on your behalf, the domain is checkable.
Two of the failure modes Validity documents are worth repeating, because both are counter-intuitive and neither is about getting caught:
Reputation attaches to your authenticated sending identity, and that identity follows you to every provider you will ever use. Where the warmup vendor has been authenticated against your own domain or given your ESP credentials, a listing does not attach to some disposable lookalike. It attaches to the identity you send everything else from, and it is not something a migration escapes.
Omnivery does not support synthetic warming, and senders who rely on it are not welcome as customers. That is an admission decision rather than a feature decision. Every customer is vetted and signs a contract, every sending domain is reviewed by a person, and there is no free tier - and the point of all three is that the sending neighborhood stays clean for everyone in it. A sender manufacturing engagement signals is doing the opposite of what the vetting exists to protect.
There is a symmetry worth naming. Non-Human Interactions are automated opens and clicks that inflate engagement metrics without anyone intending it - the reason Omnivery built classification rather than blocking. Synthetic warming is automated engagement manufactured on purpose. Both make the numbers describe something that did not happen. Only one of them is a decision the sender made.
At a glance
Questions
IP warming is the practice of gradually increasing the volume of email sent from a new IP address, so that mailbox providers can build a reputation record for it before it carries full production traffic. A brand new IP has no delivery history, no complaint history and no engagement record, so sudden volume from it is indistinguishable from a compromised host or a spam operation. Starting low and increasing steadily gives receivers something to evaluate.
Domain warming is the same gradual ramp applied to a sending domain rather than an IP address. It matters more than IP warming does, because anti-spam systems have moved away from IP-based blocklists toward domain-based reputation. Domain reputation follows the domain regardless of which IP or which provider the mail leaves from, which makes it the part of your sending identity that actually accumulates.
IP reputation attaches to the sending IP address; domain reputation attaches to the authenticated sending identity, meaning the DKIM signing domain and its key. IP reputation is lost when you move to a new dedicated IP and is shared with other senders on a shared pool. Domain reputation is yours alone, but it is not portable in the way it is often described: change provider and the DKIM keys change with it. The practical difference is that on a shared pool the IP side is handled for you and the domain side still is not. A well-warmed IP does not compensate for a cold domain.
Four to eight weeks to full volume is the range usually quoted, but it is a range rather than a schedule, and the honest answer is that it depends on your list. A large, engaged, well-authenticated list warms faster than a small or stale one, because the receiver is getting more positive signal per day. Anyone offering a precise day-by-day table without knowing your list size, its quality or your recipients' provider mix is guessing.
Broadly the same period, and for the same reasons - the two normally run together on a new setup. What differs is the consequence of getting it wrong. A damaged IP reputation can be escaped by moving to another IP; a damaged domain reputation follows the domain to every provider you ever use, which is why the domain side deserves the more conservative pace of the two.
The IP side, no - a vetted shared pool already has established reputation, and you inherit it from the first message. The domain side, yes. Your sending domain is new to every receiver regardless of which IP it leaves from, and its record still has to be built. This is the most common misreading of "the provider handles warming": the pool gets your mail taken seriously enough to be evaluated, it does not do the evaluating for you.
Not in the way it is usually described. Domain reputation is bound to the authenticated sending identity - the DKIM signing domain and the key signing for it - rather than to the domain string on its own. A new provider signs with its own DKIM keypair under its own selector, and the mail starts arriving from different IPs at the same time, so a receiver is presented with a sender it has not assessed before under a name it recognizes. Suppression state and complaint history do not transfer either; those live with the old provider and have to be moved deliberately.
Yes. Because the DKIM keys and the source IPs both change, a migration needs a domain warm rather than only an IP warm. Do it as a phased cutover rather than a hard switch: move a share of production traffic first, watch delivery and complaint data from real recipients rather than a test list, then increase. That also keeps the old provider running in parallel as a comparison, which is the only reliable way to separate a genuine deliverability difference from normal daily variation. The technical switch can take an afternoon; the ramp behind it takes weeks.
Receivers respond first with throttling and deferrals - your mail is accepted slowly or told to try later. If the volume continues, filtering follows, and messages land in spam or are rejected outright. The damage is not just the affected send: the episode is written into the reputation record you were trying to build, and on the domain side it follows you to every provider afterwards. This is why a single unplanned spike mid-warm undoes weeks of careful ramping.
No, and the risk has grown sharply. These services generate synthetic messages, opens, clicks and replies between networks of accounts they control, which fabricates a reputation record rather than earning one. How they attach to you varies: some register domains resembling your own, and many ask you to authenticate your real sending domain to them, or to hand over access to your ESP account, so the traffic originates as close to your genuine source as possible. That is the version to be most wary of - if the vendor signs with your DKIM key or sends from your platform, the fake engagement is attaching to the identity you actually depend on, and giving a third party that access is a security exposure in its own right. M3AAWG - whose members include Google, Microsoft and Yahoo - stated in its Position on Cold Email of November 2025 that artificially simulating subscriber engagement is "particularly egregious" and "not acceptable in any manner". Validity launched the Heatwave domain blocklist on 3 September 2026 specifically to identify what it calls deceptive reputation warming, it now lists over a million domains, and it is used or being evaluated by Comcast, Proofpoint, Spamhaus and SURBL. A domain can be checked against it publicly. A listing of that kind attaches to your domain and your brand, which is exactly the thing that follows you to every provider you ever use. Omnivery does not support the practice and does not accept senders who rely on it.
No. Every sending domain has its own rate limit that increases by 20% once the domain reaches 75% of its current limit, so the ramp happens as a consequence of normal sending rather than from a schedule. The increase is not unconditional: hitting 75% is the trigger, and the domain's bounce rate, complaint rate and other delivery signals are assessed before the limit actually moves, so a domain whose numbers are deteriorating does not get more headroom. That is the daily monitoring a manual warm asks of you, done by the platform. IP warming is handled by Omnivery as part of the managed infrastructure.
Yes. Where there is a genuine step change coming - a campaign, a seasonal peak, a migration cutover - support can set a custom rate limit rather than leaving you to work around the automatic one. Raising it deliberately, with the send known in advance, is a different thing from a limit being hit unexpectedly by traffic nobody planned for. It is also why a known event is worth flagging early: the automatic increase is paced against delivery health and will not leap ahead of it just because a big send is scheduled.
Every external claim on this page traces to one of these. Where a figure comes from Omnivery's own platform rather than a published source, it is linked to the documentation instead.
The four-to-eight-week figure for a manual warm is a commonly quoted industry range rather than a measured result, and is presented on this page as such. Ranges of that kind depend heavily on list size, list quality and recipient provider mix.
Warming builds the record. These cover what the record is judged on, and what you have to get right before the first message.
Every sending domain has its own rate limit that grows with your traffic, so the ramp is enforced by the platform rather than by somebody remembering to check it. The shared sending neighborhood is vetted, so the IP side is already warm on your first message.