Warming a dedicated IP without getting throttled

A dedicated IP has no reputation on day one, and receivers treat an unknown IP sending real volume as suspicious by default. Warming it means increasing volume slowly enough that each major receiver can build a positive history, while watching for the 4xx deferrals that mean you are moving too fast.

The first decision is whether you should have one at all.

When a dedicated IP is the wrong answer

A dedicated IP needs high and consistent volume. Reputation on an IP decays when it goes quiet, so a sender with large campaigns twice a month will keep re-warming forever and will perform worse than on a well-maintained shared pool. Signals you are not ready:

• Your volume varies by an order of magnitude week to week.
• You send only outreach from mailboxes — that volume is nowhere near enough, and you cannot put a dedicated IP in front of Google Workspace or Microsoft 365 sending anyway.
• You cannot staff bounce and complaint handling. On a shared pool the provider absorbs some of that; on your own IP you absorb all of it.

The genuine reasons to take one: you need to be insulated from other senders on the pool, you need stable IP reputation for high-volume transactional mail, or a receiver has asked you to separate streams.

A ramp that works

Volume per day, across all receivers, with the engaged-first rule applied inside each day:

Two rules matter more than the exact numbers:

1. Segment by receiver. Gaining reputation at Gmail does nothing for you at Microsoft. If 70% of your list is Microsoft 365, your ramp is really a Microsoft ramp.
2. Hold, do not push through. If volume rises and deferrals rise with it, stay at the previous day's volume for two or three more days rather than continuing the curve.

The codes that mean slow down

• 421 4.7.0 and similar — too many messages or connections from this IP right now. Reduce concurrency first, then volume.
• 451 4.7.1 — rate limited by the receiver. Normal in small quantities during a ramp; a rising share of your traffic means stop increasing.
• 550 5.7.1 policy rejections — not a throttle. This is a reputation or content block, and continuing to send makes it worse.
• 452 mailbox or system full on the receiver side — retry later, not a signal about you.

A deferral is the receiver asking for patience; your ESP will retry. A 5xx is final. Treating them the same is how a ramp turns into a block.

How the platforms automate this

• SendGrid has an automated IP warmup setting on dedicated IPs, configured with the IP under *Settings → IP Addresses*. While it is on, SendGrid caps daily volume per IP on a built-in schedule. You can also create IP pools on the same screen and assign streams to them, which is how you keep transactional mail off the marketing IP.
• Amazon SES offers managed dedicated IPs, where AWS shifts traffic between shared and dedicated capacity as the IP warms, and standard dedicated IPs with an automatic warm-up mechanism you can switch off if you are migrating an already-warm IP.
• Mailgun assigns dedicated IPs to your domain and supports pools; the ramp is yours to manage.
• Postmark keeps you on well-managed shared infrastructure by default and separates reputation by message stream, which removes most of the reasons to want a dedicated IP.

Whichever you use, register the IP with Microsoft SNDS and the Junk Mail Reporting Program. SNDS data is only available to the party that controls the IP, and it is the only direct feedback Microsoft gives senders.

What not to do

• Do not warm an IP with a cold or unverified list. You are teaching receivers that this IP sends unwanted mail, which is the opposite of the exercise.
• Do not ramp two IPs in parallel with the same list. You halve the reputation signal each one builds.
• Do not pause for a week mid-ramp. Gaps reset progress.
• Do not point a brand-new domain at a brand-new IP. Warm the domain first on shared infrastructure, then move it, so only one variable is new.
• Do not interpret a burst of 421 responses as a reason to switch IPs. Switching restarts the warm-up.

Mailbox-level and domain-level reputation are a separate axis from IP reputation, and both have to be in place for a ramp to land. MailPilot warms mailboxes over OAuth or SMTP, verifies SPF, DKIM and DMARC on the sending domain, and measures per-provider inbox placement daily — so during an IP ramp you can tell whether a Microsoft problem is the new IP or the domain it is sending for.