IP warm-up in Braze — the playbook that actually holds

You've been assigned a brand new dedicated IP — a sending IP address that only your program uses, as opposed to a shared pool where lots of senders mix. On day one, that IP has never sent a message in its life. Gmail, Yahoo, Microsoft, and Apple iCloud have no record of it. They have no idea whether you're a thoughtful operator or a spammer with a bulk list, so the safe assumption is the second one. Messages land in spam. Sends get rate-limited. Some bounce outright before they get a chance.

Inbox providers — the companies that run the email services your subscribers actually read mail in — judge a sending IP on its rolling reputation: volume consistency, bounce rates (sends that got rejected), spam complaint rates, and how many engaged recipients are opening and clicking. A new IP has none of that history.Source · GoogleEmail sender guidelinesOfficial Gmail sender requirements covering reputation, authentication, bounce rates, and complaint thresholds.support.google.com/mail/answer/81126

A warm-up schedule is how the IP introduces itself politely. Tiny volume on day one. A little more on day two. Exponentially more over two to four weeks. By the end, the inbox providers have seen enough clean sending to trust the target volume. Standard ramps run 14 to 30 days. Fourteen is aggressive — it works when the list is clean and engagement is strong. Pick thirty for unknown-quality lists, sustained sending over 500,000 a day, or a program that has scorched its reputation before and is trying again.

A 14-day ramp starts at roughly 2% of target daily volume, doubles every two days or so, and reaches 100% by day fourteen. A 30-day ramp doubles less aggressively and ends in the same place. The curve is exponential because reputation compounds — every clean early day buys the headroom for a bigger next one.

Here's the shape:

Treat each day's number as a ceiling, not a floor. If peak Tuesday is 100,000 sends and Wednesday is 30,000, warm to the peak — don't go over. Inbox providers notice volume spikes more than almost any other signal, and a single day at double the expected volume can set the warm-up back five to seven days.

Every team asks how fast to ramp. The better question is who receives the send on each day of the ramp. If day one is two thousand of your most engaged users and day fourteen is a hundred thousand users including the dormant, the complaint-prone, and the barely-opted-in, the reputation curve will collapse exactly when it matters most. You're effectively two different senders on the same IP a fortnight apart, and the inbox providers will treat you that way.

Random Bucket Numbers — RBNs — solve this. The idea is simple: at signup, assign every subscriber a stable random integer from 0 to 9,999, stored as a user attribute, never re-rolled. Bucket 0–199 is then a random 2% of your base. Bucket 0–999 is a random 10%. The numbers never move, which is the whole point.Source · BrazeRandom Bucket Number attributeOfficial Braze docs on random_bucket_number — the attribute used for consistent sampling, IP warm-up cohorts, and Global Holdout Groups.www.braze.com/docs/user_guide/engagement_tools/segments/random_bucket_number

Day one sends to bucket 0–199. Day two expands to 0–299. Each bucket expansion adds new users without removing old ones, so the behavioural mix — the ratio of engaged to lapsed, of recent signups to long-tail — stays constant as volume climbs. Every day of the ramp looks like a scaled-up version of the day before. Which is exactly what inbox providers reward.

The Orbit IP Warm-Up Plannergenerates the exact RBN ranges for each day, and carves out a Global Holdout Group — the random slice you deliberately don't send to so you can measure the program's incremental impact — if you're already running one, so the measurement program doesn't accidentally get eaten by the warm-up math.

Three failure modes keep showing up: un-engaged sending, volume spikes, and a complaint rate that quietly climbs. The pattern is almost always the same. A stakeholder wants to just test one quick campaign at full volume on day ten. Volume doubles. Bounces spike because dormant users are swept in. Complaints follow because those dormant users don't remember signing up. Microsoft temporarily blocks the IP. The recovery runs into weeks.

Defensive moves before the ramp starts. Suppress users inactive 90+ days for the full warm-up window. Quarantine any segment that arrived from a bulk import without explicit confirmation — meaning the user actively re-confirmed their subscription, not just landed in a CSV. Put the ramp schedule in writing and circulate it to every stakeholder who has the ability to request a send.

Monitor every day during the ramp. Bounce rate should stay under 2%. Spam complaints under 0.1%. Seed-test inbox placement — testing into a panel of dummy mailboxes across providers to see where your mail actually lands — above 90%. Miss any of those, slow the ramp or tighten the audience before advancing. The full deliverability guide covers what to watch once you're sending at full volume, and the Orbit Braze Deliverability Health Check skill pulls these numbers directly from the Braze API — the programmatic interface Braze exposes for reading data out of your account — so monitoring is automatic rather than a manual morning ritual.

A dedicated IP is only worth the warm-up tax if your sustained daily volume earns the isolation. Below roughly 100,000 sends a day, the Braze shared pool — an IP that's used by lots of Braze customers at once — almost always delivers better, because it inherits the reputation of thousands of other established senders. You get their good behaviour for free. Yes, occasionally their bad behaviour too. Net, it's the better deal at that scale.

Above the 100,000-a-day threshold — and especially for regulated sending, financial services, or high-volume promotional programs — a dedicated IP earns its place. You own the reputation entirely, which cuts both ways: isolation from other senders' problems, and no safety net when you cause your own. A week of bad sending on a dedicated IP undoes months of trust.

If Braze has given you multiple sending IPs, the third option is the most conservative one. Warm the new IP alongside an established one, split daily volume between them, and gradually shift more to the newcomer as reputation builds. Plan four to six weeks rather than fourteen days. You pay the time tax and get rid of the day-14 cliff where the new IP has to stand alone for the first time.

The warm-up is complete when five conditions hold together for at least a week of sending at target volume. Bounce rate under 2%. Spam complaints under 0.1%. Seed-test inbox placement above 90% across Gmail and Microsoft. Open rate on the warm-up cohort matches your normal sending cohort. Sender reputation — Google Postmaster Tools, Microsoft SNDS, whichever deliverability monitor you pay for — consistently shows High or Good.Source · GooglePostmaster ToolsGoogle's free tool for monitoring Gmail sender reputation, spam rate, authentication results, and delivery errors.postmaster.google.com

Skip any of the five and you're running at full volume on an IP that wasn't actually ready. Most common failure mode I see: opens match baseline but seed-test inbox placement is 78% instead of 92%, which means a meaningful slice of sends is quietly landing in Promotions or spam and never showing up in the open-rate number at all. Dashboard looks fine. Program isn't.

Shortest version of the take: warm slow, send to a stable mix every day, and refuse the day-ten exception. Rest is bookkeeping.