IP address migration for mail: warming up a new sending IP without losing deliverability on the old one

Moving outbound mail to a new IP is one of the easiest ways to damage a healthy stream by accident.

The new IP starts cold. The old IP may still be carrying the reputation that keeps your important traffic stable. If you swing all mail over at once, mailbox providers do not see a careful migration. They see a sender that changed infrastructure abruptly and immediately asked for trust on an IP with little or no history.

That is why the safe migration pattern is not "cut over and hope." It is controlled overlap: keep the old IP behaving normally while the new IP earns trust gradually.

The short version

If you need the operating sequence first, use this order:

1. keep SPF, DKIM, DMARC, PTR, and EHLO correct on the new IP before real traffic moves
2. leave the old IP active during the overlap instead of shutting it off on migration day
3. start the new IP with your cleanest, most engaged recipients
4. move one stream at a time, not all transactional and marketing traffic together
5. increase new-IP volume gradually and avoid sudden spikes on either IP
6. watch deferrals, complaint rate, spam placement, and postmaster data every day
7. slow down or pause the ramp if the new IP starts getting throttled or complained on
8. retire the old IP only after the new IP is stable and the old stream is genuinely idle

Google's sender guidance explicitly says to increase sending volume slowly, send at a consistent rate, start with engaged users, and reduce volume if bounces or deferrals rise. Outlook.com says new IPs typically have no reputation yet, are more likely to have deliverability issues, and often need a couple of weeks or more to ramp depending on volume, list accuracy, and complaint rate. Sources: Google's Email sender guidelines and Microsoft's Outlook.com Postmaster troubleshooting.

Why IP migrations go wrong

An IP move often combines several risks into one event:

• a cold IP with no positive history
• a sudden change in SMTP source identity
• different connection patterns or volume shape
• accidental authentication drift during the move
• list-quality mistakes hidden inside the migration

Mailbox providers evaluate more than raw authentication. Microsoft documents that inbound decisions also use sender reputation, sender history, recipient history, and behavioral analysis in addition to SPF, DKIM, and DMARC. That means a technically valid new path can still perform badly if its traffic pattern looks risky or untrusted. Source: Email authentication - Microsoft Defender for Office 365.

Do not treat the new IP as a pure infrastructure swap

The visible sender identity should stay as stable as possible during the migration.

If you change all of these at once, troubleshooting gets much harder:

• sending IP
• MAIL FROM / bounce domain
• DKIM signer or selector
• visible From: domain
• mail stream mix
• send frequency

The cleaner pattern is to change the IP first while keeping the domain story boring and consistent. If the new IP uses the same aligned DKIM domain and the same intended stream, receivers can evaluate one major change instead of five.

If you are also changing MTAs or providers, Email server migration checklist and Email provider migration playbook are the right companion posts.

What must be correct before the first warm-up send

Before you send even a small warm-up batch through the new IP, verify:

1. SPF authorizes the new path.
2. DKIM signs with an aligned domain.
3. DMARC passes on real test messages.
4. The new IP has valid reverse DNS and matching forward DNS.
5. The SMTP EHLO/HELO name is sane and consistent.
6. TLS is enabled where receivers expect it.

Google requires valid forward and reverse DNS, authenticated mail, and DMARC alignment for bulk direct mail. Outlook.com's sender requirements now also require SPF, DKIM, and DMARC for high-volume senders. If this layer is wrong, the migration is not warming up. It is launching broken mail on a fresh IP.

Why the old IP should stay in service during the overlap

This is the part teams most often skip.

If the old IP is healthy, it is already carrying reputation with providers that have seen its traffic, complaints, and engagement over time. Turning it off too early forces all trust-building onto the cold IP immediately.

Keeping the old IP alive gives you three operational advantages:

1. It protects important traffic while the new IP proves itself

You do not need invoices, receipts, or password resets to be the experiment.

2. It lets you compare old-IP and new-IP behavior side by side

If only the new IP starts seeing throttling, junk placement, or blocks, the migration problem is much easier to isolate.

3. It avoids a volume cliff on the old path and a volume spike on the new one

Receivers distrust abrupt changes in both directions. A clean overlap keeps the overall program more predictable.

Start the new IP with the mail most likely to succeed

When warming the new IP, do not begin with your largest or stalest audience.

Start with recipients who are most likely to recognize, open, and want the mail:

• recent purchasers
• recent logins or active users
• recent openers or clickers
• low-complaint transactional recipients
• small, well-understood segments

Google's guidance says to start with engaged users and increase volume slowly. Amazon SES also recommends sending to your most active users during warm-up so complaint rates stay low, and notes that some providers may need around two weeks while others can take much longer. Sources: Google's Email sender guidelines and Amazon SES Warming up dedicated IP addresses.

What not to use first:

• old imported lists
• re-engagement segments
• complaint-prone promotions
• mixed transactional and marketing traffic on one cold IP
• one-off bursts created only to "speed up" warm-up

Migrate one stream at a time

The cleanest warm-ups separate traffic by purpose.

For example:

• leave password resets and receipts on the old IP initially
• move one low-risk marketing or lifecycle segment first
• migrate a second stream only after the first looks stable

This matters because complaint tolerance and recipient expectations differ by stream. A promotional stream that underperforms can poison the new IP before your critical mail ever reaches it.

If you do need both transactional and marketing traffic on new infrastructure eventually, isolate them during the ramp. Transactional vs marketing email separation and Shared IP vs dedicated IP for email explain why that separation protects reputation.

How to ramp without harming the old IP

The migration target is not "move as fast as possible." The target is "increase trust on the new IP without destabilizing the current trusted path."

That usually means:

1. keep the old IP sending its normal healthy baseline
2. carve out a small, clean slice for the new IP
3. increase the new-IP share in steps, not in jumps
4. hold or reduce the new-IP share if provider signals worsen
5. only shrink the old-IP share after the new path stays stable

Twilio SendGrid's warm-up guidance makes the same basic point from the ESP side: cold IPs should begin at low to moderate volume and increase gradually because ISPs use volume and engagement patterns to evaluate new sources. Source: Twilio SendGrid IP warm-up.

The exact numbers depend on your sender history, recipient quality, message type, and provider mix. The shape matters more than one universal schedule:

• gradual growth is safer than doubling abruptly
• daily sending is easier to model than sporadic bursts
• stable message categories are safer than mixed traffic experiments

Watch the signals that tell you whether the new IP is trusted yet

During the overlap, monitor both IPs every day.

Look at:

• SMTP deferrals and throttling
• hard rejects
• complaint rate
• invalid-recipient and bounce rate
• spam-folder placement
• domain and IP reputation dashboards
• DMARC pass and alignment consistency
• Authentication-Results on received samples

For Gmail, watch Postmaster Tools closely. Google says spam rates should stay below 0.1% and should never reach 0.3% or higher. If you start getting 4.7.28 deferrals during the ramp, that is a sign to slow down and investigate. See Gmail Postmaster Tools compliance dashboard and How to troubleshoot Gmail 4.7.28 throttling.

For Outlook.com, SNDS and JMRP are especially valuable during IP migration because they help separate cold-IP issues from complaint-driven issues. How to use Microsoft SNDS and JMRP goes deeper on that workflow.

Common migration mistakes

Moving all mail on day one

This creates the largest possible blast radius and tells receivers nothing good about your control discipline.

Warming with weak recipients

Warm-up is supposed to generate positive signals. Old, stale, or surprise recipients do the opposite.

Breaking alignment during the IP move

If SPF now passes for a non-aligned bounce domain and DKIM changed to a provider-owned signer, DMARC can fail even though the migration team thinks authentication is "present."

Mixing transactional and promotional traffic immediately

One weak campaign can damage the new IP before critical mail has a stable place to land.

Turning down the old IP too fast

If the old path drops to near zero before the new one is trusted, you lose the safety net and often create a second reputation shock.

Trying to power through throttling

Google explicitly recommends reducing sending if bounces or deferrals rise. Pushing harder into a bad signal usually lengthens the recovery.

A practical overlap playbook

Use this sequence when migrating from one dedicated sending IP to another:

1. verify SPF, DKIM, DMARC, PTR, forward DNS, and TLS on the new IP
2. send test messages and inspect Authentication-Results
3. keep the old IP carrying normal production traffic
4. move a small, high-quality recipient slice to the new IP
5. monitor provider responses and complaint signals for at least a full sending cycle
6. increase the new-IP share gradually if signals stay healthy
7. keep critical transactional traffic on the old IP until the new IP is clearly stable
8. update SNDS, JMRP, Postmaster Tools, and any internal dashboards to include the new IP
9. pause or roll back the most recent increase if deferrals, complaints, or junking worsen
10. retire the old IP only when its traffic is truly drained and the new IP has a stable pattern

That playbook is less dramatic than a clean cutover, but it is much more compatible with how mailbox providers actually build trust.

When the old IP should finally be retired

You are usually ready to remove the old IP after all of these are true:

• the new IP has handled sustained normal traffic, not just one successful batch
• complaint and bounce behavior stayed acceptable during the ramp
• major providers are no longer showing cold-IP symptoms
• critical streams have been tested on the new IP successfully
• no hidden systems are still routing mail through the old path

Only then should you remove old routing, SPF references, or dashboards tied to the old source.

Bottom line

The safest way to migrate to a new sending IP is to keep the old IP stable while the new one earns reputation gradually.

Do not make the new IP prove itself with your worst list, your most important traffic, and a same-day full cutover. Keep authentication and identity steady, warm the new IP with your best recipients, move one stream at a time, and let provider feedback determine the ramp speed.

That is how you build trust on the new IP without throwing away the deliverability the old one already earned.