Skip to content
CORDYTECH Engineered Signal Get in touch
deliverability

How to warm up a sending IP without tripping spam filters

A field-tested ramp for new sending IPs: the prerequisites that must be perfect, a provider-by-provider volume schedule, the signals to watch, and how to back off when a mailbox provider pushes back.

Short answer

Warm up a new sending IP by increasing volume gradually — start in the low hundreds per mailbox provider per day and roughly double every day or two — while keeping authentication (SPF, DKIM, DMARC), reverse DNS, and list quality flawless. Send your most engaged recipients first, watch bounce and complaint rates per provider, and slow down the moment a provider starts throttling. A clean ramp to full volume typically takes two to six weeks.

A brand-new sending IP has no reputation, and to a mailbox provider no reputation is closer to bad reputation than to good. Gmail, Microsoft, Yahoo, and the rest decide where your mail lands based on how the address behaves over time. Point a fresh IP at your full list on day one and you look exactly like a spammer who just bought an IP block — high volume, no history, no engagement — so the mail gets throttled, foldered, or blocked. Warming up is the process of building that history deliberately, at a pace the providers will accept.

This guide walks through how we warm IPs at EMG, the deliverability operation whose sending infrastructure we run: the prerequisites that have to be perfect before you send anything, the ramp schedule itself, what to send and to whom, the signals to watch, and how to back off when a provider pushes back.

01What "warming up" actually means

Mailbox providers build a reputation profile for each sending IP and, increasingly, for each sending domain. That profile is a rolling judgement based on how many messages you send, how consistent your volume is, how recipients react — opens, replies, "not spam", deletions without reading — and how many messages bounce or generate complaints. Warm-up is simply the act of generating a short, clean history so the provider has evidence you are a legitimate sender before you ask it to accept real volume.

Two things follow from that definition. First, warm-up is about consistency as much as volume: a jagged pattern of 5,000 one day and nothing for three days reads worse than a steady climb. Second, domain reputation now travels somewhat independently of IP reputation, so if you are also on a new domain you are warming two reputations at once and should be even more conservative.

02Before you send a single email

No ramp survives broken fundamentals. Get these right first, because a warm-up on a misconfigured IP just teaches providers to distrust you faster.

Authentication: SPF, DKIM, DMARC

Publish an SPF record that authorises the sending IP, sign every message with DKIM using a key you control, and publish a DMARC policy that aligns with both. Start DMARC at p=none with an rua address so you receive aggregate reports, confirm alignment, then move toward p=quarantine and eventually p=reject once you trust the data. Unauthenticated mail in 2026 is not borderline — it is filtered, and Gmail and Yahoo require authentication for bulk senders outright.

Reverse DNS, TLS, and the boring hygiene

Every sending IP needs a PTR record (reverse DNS) that resolves to a hostname you own, and that hostname should have a matching forward record. Offer opportunistic TLS so mail is encrypted in transit. Make sure the IP is not on any major bl‑list before you begin, and that your HELO/EHLO hostname, envelope-from domain, and DKIM domain tell a consistent story. Providers reward coherence; mismatched identifiers look like something to hide.

03The ramp: a schedule providers trust

The core mechanic is a gradual volume increase, segmented per mailbox provider because each one tracks you separately. A common, conservative starting point is a few hundred messages per provider per day, roughly doubling every one to two days as long as the signals stay clean. Here is a representative ramp for a single provider:

DayVolume / providerNotes
1–2200–500Most engaged recipients only
3–41,000–2,000Watch bounce & complaint rates
5–74,000–8,000Widen to 30-day actives
8–1215,000–40,000Hold a day if throttled
13–2175,000–200,000Approach steady-state volume

Treat those numbers as a shape, not a law. A list of 5,000 highly engaged recipients warms differently from a list of five million. The rule that matters is: increase gradually, keep the daily pattern consistent, and never jump by more than roughly 2× in a single step. If you must pause, ramp back up rather than resuming at the top — providers notice gaps.

04Content and list quality during warm-up

Warm-up amplifies whatever your list quality already is, so send your most engaged recipients first. People who opened or clicked in the last 30 days are the ones most likely to generate the positive signals — opens, replies, "not spam" — that build reputation. Save dormant addresses for after you have a track record; sending to them early is how you rack up bounces and complaints exactly when you can least afford them.

Clean the list before you start: remove hard bounces, run syntax and MX validation, and strip role addresses and spam traps where you can. During the ramp, keep the mail genuinely wanted — transactional and high-intent content warms better than a promotional blast because recipients engage with it. Keep a visible, one-click unsubscribe; a recipient who unsubscribes is far better for your reputation than one who hits the spam button.

05Reading the signals

Warm-up is a feedback loop, not a fire-and-forget schedule. Watch these per provider, every day:

  • Bounce rate — keep hard bounces well under 2%. A spike means list quality or a block, not a slow server.
  • Complaint rate — stay under roughly 0.1% (one in a thousand). Above 0.3% and providers will start foldering you.
  • Throttling / deferrals4xx "try again later" responses are the provider telling you to slow down. Respect them; do not hammer.
  • Engagement — opens and replies trending up is the signal that the ramp is working. Flat or falling engagement means back off and investigate.
  • Seed-list placement — monitor inbox-vs-spam placement across a seed list so you catch foldering before it shows up in your numbers.

06When it goes wrong: throttle, block, back off

Providers push back in two languages. A soft failure (4xx) is temporary: you are sending faster than they will accept right now, so reduce concurrency, honour their retry timing, and hold volume flat for a day. A hard failure (5xx) or an outright block is a reputation event — stop increasing immediately, find the cause (a bad segment, a content trigger, an authentication break), fix it, and resume from a lower step. The instinct to "push through" a block is exactly wrong; it deepens the distrust you are trying to reverse.

If you get blocklisted, do not just request delisting and carry on. Understand why you were listed — usually a spike, a dirty segment, or a compromised form — remediate it, and only then request removal. A delisting without a fix is a delisting that reverses within the week.

07Common mistakes

The failures we see most often are the avoidable ones: ramping too fast because the first few days looked fine; sending to the whole list instead of the engaged core; letting volume go jagged over weekends; warming the IP while ignoring the domain; and treating authentication as a checkbox rather than something to verify with real reports. Every one of them is a way of telling mailbox providers you are in a hurry — and senders in a hurry are the ones they are built to stop.

08How long it takes — and shared vs dedicated IPs

There is no fixed duration, only a fixed shape. A small, highly engaged list on a dedicated IP can reach steady state in about two weeks; a large list, a cold audience, or a brand-new domain alongside the IP can stretch the ramp to four or six. The honest answer is that warm-up is finished when the numbers say it is — stable inbox placement, complaint and bounce rates comfortably inside the thresholds, and no throttling at your target volume — not when a calendar says so. Pushing to "done" ahead of the data is just a slower way of starting over.

The other decision that shapes the timeline is shared versus dedicated IPs. A dedicated IP gives you a reputation you fully own and control, which is the right choice once your volume is high and consistent enough to sustain it — but it is a reputation you have to build from zero, which is exactly the warm-up this guide describes. A shared IP pool lets you inherit an established reputation and skip much of the ramp, at the cost of being affected by the other senders in the pool. As a rule of thumb: high, steady volume favours a dedicated IP; lower or spiky volume is usually safer on a well-managed shared pool. Whichever you choose, the discipline underneath is identical — consistency, clean lists, and respect for the signals the providers send back.

09How EMG does it

At EMG the ramp is not a spreadsheet someone updates by hand — it is infrastructure. The control plane schedules per-IP and per-domain warm-up curves, monitors seed-list placement and provider responses in real time, and automatically holds or backs off a segment when the signals turn. That is the whole thesis of how we build: deliverability is an engineering problem, and the difference between the inbox and the spam folder is a system that watches the signals faster than a person can. Warm up patiently, keep the fundamentals perfect, and let the data — not the deadline — set the pace.

Technical Partner

Hassan Houmaid

Hassan owns the sending infrastructure behind Cordytech's email engagements — PMTA configuration, IP warm-up, and the authentication posture clients inherit. He made the architecture calls behind Mailflow, first built at Mobicentrum and now the control plane for how that sending runs. When placement drops at one provider, the diagnosis — VMTA configuration, reputation, or a signing key that never reached every node — is his.

Working on deliverability or a product like this?

This is the kind of problem we solve as infrastructure, on the client stacks we run. Tell us what you are building.