Warming Up a New Sending IP: A 30-Day Deliverability Playbook
A dated 30-day ramp for a brand-new sending IP: exact daily volumes, engagement-first segmentation, seed lists, and the Postmaster Tools and SNDS signals that tell you to hold, slow, or push.
EvilMail TeamJuly 8, 202613 min read
A brand-new sending IP has no history, and to a mailbox provider "no history" reads as "guilty until proven innocent." Gmail, Microsoft, and Yahoo do not extend a fresh IP the benefit of the doubt. They greylist it with 4xx deferrals, cap connections, and drop your mail straight into Spam while they decide who you are. Warm-up is the work of nudging that decision in your favor, one predictable day at a time.
The most common way warm-ups fail is treating the ramp as a fixed calendar. Senders double volume on schedule while ignoring the one number that actually gates everything: the spam-complaint rate. Volume is the numerator you control; complaints are the denominator that decides whether you get to keep sending. This playbook hands you a dated 30-day ramp, but the ramp is a floor, not a promise. You advance only when the signals stay green.
Why a fresh IP starts in the penalty box
Reputation is not one score. It is tracked per IP and per sending domain (the DKIM d= domain), and both have to warm together. You can inherit a clean IP and still land in Spam because the d= domain is unknown, and vice versa. Providers hash your IP, your HELO name, your DKIM domain, and your From domain into a reputation profile, then judge today's behavior against that profile.
With no profile, the defaults are hostile:
Rate throttling — a hard cap on messages per connection and connections per hour. Exceed it and Gmail answers 421 4.7.0 and drops the connection.
Greylisting — a 451 4.7.1 deferral on first contact, on the assumption that a well-behaved MTA will retry. Spam cannons often do not.
Spam-folder-by-default — even accepted mail lands in Spam until engagement proves otherwise.
Kill the myth that a big provider "just needs a few days." It needs *consistent, low-complaint volume over weeks*. There is no shortcut, and a burst of 50,000 on day two is the fastest way to earn a Bad reputation band you will spend a month digging out of.
Prerequisites you must land before day 1
Warming a misauthenticated IP is throwing money into a furnace. Land all of this first — verified, not merely present — before a single production message leaves the queue.
SPF ending in -all (hardfail), listing only the warming IP.
DKIM 2048-bit, published, and signing *verified* against live mail, not just visible in DNS.
DMARC at p=none to start, with aggregate reports flowing so you can confirm alignment before you tighten.
PTR / rDNS matching your HELO name, plus forward-confirmed rDNS (the A record of the HELO name resolves back to the IP).
TLS with modern ciphers, opportunistic or enforced, plus MTA-STS and TLS-RPT published.
One IP, one purpose. Never mix transactional and bulk marketing on a warming IP. Different traffic classes carry different complaint profiles, and you cannot debug a blended one.
The DNS side, concretely:
dns
; SPF — only the warming IP, hardfail
evilmail.pro. TXT "v=spf1 ip4:203.0.113.10 -all"
; DMARC — start permissive, reports on
_dmarc.evilmail.pro. TXT "v=DMARC1; p=none; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1"
; PTR (set at your provider): 203.0.113.10 -> mail.evilmail.pro
; FCrDNS check: mail.evilmail.pro must A-record back to 203.0.113.10
; TLS reporting
_smtp._tls.evilmail.pro. TXT "v=TLSRPTv1; rua=mailto:[email protected]"
On the Postfix side, the HELO name must match your PTR, and you slow each destination deliberately:
ini
# /etc/postfix/main.cf
smtp_helo_name = mail.evilmail.pro
smtp_tls_security_level = dane
smtp_dns_support_level = dnssec # dane requires DNSSEC-validated lookups
smtp_tls_protocols = !SSLv2, !SSLv3, !TLSv1, !TLSv1.1
smtp_tls_loglevel = 1
# global politeness during warm-up
default_destination_concurrency_limit = 2
default_destination_rate_delay = 1s
# per-provider transports (see master.cf)
transport_maps = hash:/etc/postfix/transport
If your resolver chain is not DNSSEC-validating, drop back to smtp_tls_security_level = may and lean on MTA-STS for enforced TLS instead — a broken DANE setup silently defers mail.
The 30-day ramp schedule
Here is the core. These volumes are per mailbox provider, weekday-only, sent at a consistent time of day. Gmail, Microsoft, and Yahoo count you independently: 5,000 to Gmail and 5,000 to Outlook is two separate reputations built in parallel, so track and throttle them separately.
Day
Volume/provider
Day
Volume/provider
1
50
12
10,000
2
100
15
20,000
3
250
18
40,000
5
1,000
22
75,000
8
2,500
26
120,000
10
5,000
30
150,000+
The pattern is a rough 2–3x step every two to three days. That is aggressive enough to reach real volume inside a month, yet smooth enough that a provider sees a trend rather than a spike. Predictability is itself a reputation signal. A sender that pushes 5,000 every weekday at 14:00 UTC looks like a business; one that does 200 on Monday and 40,000 on Thursday looks like a compromised host.
The non-negotiable rule: you advance to the next row only if yesterday's reputation held. If Gmail's spam rate ticks toward 0.3% or the reputation band drops, you do not double — you repeat the same volume, or you cut it. The table is the ceiling of what you are *allowed* to send, gated by the feedback loop below.
Engagement-first targeting
Who you send to during warm-up decides whether it works, full stop. A fresh IP survives on positive engagement and near-zero complaints, so you feed it your best-behaved recipients first.
Rank your list by recency of engagement: opens, clicks, and especially replies in the last 7, 30, and 90 days. For the first week, send only to the most-engaged 5–10% — people who opened something in the last seven days. Widen the window as reputation builds: 30-day engagers in week two, 90-day in week three.
Openers and repliers do two things a warming IP desperately needs. They generate the positive signals Gmail weighs heavily — opens, clicks, replies, and the strongest of all, a move from Spam to Inbox — and they almost never hit "report spam." That keeps your complaint denominator clean while volume climbs.
Two hard rules: suppress anyone not engaged in 90+ days until the IP is fully warm, and never touch a purchased or unverified list on a warming IP. One spamtrap hit early can end a warm-up before it starts. Cold acquisition mail is what you send *after* week four, not during.
Seed lists and inbox-placement monitoring
Postmaster reputation is not inbox placement. You can sit at "Medium" reputation and still land in Spam at Gmail because of content or engagement — and Postmaster Tools will not tell you where the message physically landed. Seed lists will.
Build a seed set spanning Gmail, Outlook/Hotmail, and Yahoo, plus corporate Google Workspace and Microsoft 365 addresses, whose filtering differs from the consumer side. Drop a real seed into each warm-up send and use a seedbox tool — GlockApps, Inbox Insight, or a self-hosted seed panel — to report Inbox vs. Spam vs. Missing per provider, per send.
The diagnostic that pays for itself: if Gmail seeds land in Spam while SNDS and Postmaster are green, it is a content or engagement problem, not IP reputation. Rewrite the message and tighten the segment. Do not cut volume, because the IP is fine.
Reading Postmaster Tools, SNDS, and the feedback loops
This is your instrument panel. Read trends, not single days — every one of these carries a 24–48 hour reporting lag, so today's green does not clear yesterday's send.
Google Postmaster Tools — verify your domain with a DNS TXT record, then watch:
IP and Domain reputation: Bad / Low / Medium / High. Both must climb.
Spam rate: keep it under 0.1%. 0.3% is the hard ceiling — cross it and Gmail actively filters you.
The authentication, encryption, and delay/error dashboards for silent breakage.
Microsoft SNDS — enroll the IP, then join JMRP (the Junk Mail Reporting Program feedback loop) so Outlook complaints come back to you. Watch the complaint-rate color bands: green / yellow / red. Yellow is a warning; red means freeze.
Yahoo/AOL — enroll in the Complaint Feedback Loop (CFL) so their spam reports route to you for immediate suppression.
Decision rules, applied on the trend rather than a single reading:
Spam rate creeping toward 0.3% → freeze volume, hold at yesterday's number.
Reputation drops a band, or SNDS turns red → cut volume 50% and hold three days.
Auth failing or a fresh blocklist listing → stop and investigate; do not send more into the problem.
All green for two consecutive days → advance to the next ramp row.
Handling deferrals and bounces without torching reputation
During a ramp, 4xx deferrals from Gmail and Yahoo are normal throttling, not failure. A 421 4.7.0 or 451 4.7.1 means "slow down." A well-behaved MTA respects the retry timing, backs off, and tries again later. Hammering a deferral is how you turn a soft throttle into a hard block.
Distinguish the two cases clearly:
Soft 4.x.x (4.2.2 mailbox full, 4.7.x rate limited) — queue and retry with backoff. Do not suppress.
Hard 5xx (550 user unknown, 554 blocked) — suppress the address immediately. Repeated 550s inflate your bounce rate and signal a dirty list.
Set up a per-provider throttle transport so one slow destination does not stall the queue:
And check blocklists daily — Spamhaus, Barracuda, SURBL. A spamtrap hit or a fresh listing is a hard STOP, not a slow. Fix the source (almost always a bad list segment that slipped in) before sending another message.
Warm-up pre-flight and daily-ops checklist
Pin this next to the ramp table.
Auth verified: SPF -all, DKIM 2048-bit signing confirmed on live mail, DMARC p=none with reports arriving.
