Contents
- Why warming matters
- Do you even need a dedicated IP
- Prerequisites before email one
- The 4 to 8 week timeline
- Engagement-recency segmentation
- The volume ramp schedule
- Configuring VMTA throttling for warmup
- Per-ISP warmup considerations
- Thresholds that pause a warmup
- The 30-day reputation decay
- When a warmup stalls
Why warming matters
IP warming is the process of gradually increasing email volume on a new or dormant dedicated IP so that mailbox providers can recognize, identify, and evaluate the sending behavior before the full list is exposed. The alternative, sending full volume on a fresh IP, is one of the most reliable ways to destroy a sending infrastructure before it ever functions: the ISP does not know the IP, does not trust it, treats the mail like spam, and the reputation craters on day one.
This guide exists because IP warming is widely done badly, and PowerMTA's per-VMTA throttling makes it well-suited to enforcing a warmup ramp if the operator configures it correctly. The common failures are predictable: sending too much too soon, sending to the whole list instead of the engaged segment, skipping authentication, ignoring the bounce and complaint thresholds that should pause a warmup, and not re-warming a dormant IP. The structure of this guide: whether a dedicated IP is even worth warming, the prerequisites before the first email, the warmup timeline, the engagement-recency segmentation that is the single most important warmup rule, the day-by-day volume ramp, configuring PowerMTA VMTA throttling to enforce the ramp, per-ISP considerations, the thresholds that pause a warmup, the 30-day reputation decay that forces re-warming, and the diagnostic workflow when a warmup stalls.
Do you even need a dedicated IP
The first question before warming an IP is whether the operation should be on a dedicated IP at all.
The practitioner guidance for 2026 is direct: if the operation sends fewer than roughly 50,000 to 100,000 emails per month, or sends inconsistent volume, it probably does not need a dedicated IP. Shared IPs from reputable ESPs carry pooled reputation that a small or inconsistent sender cannot build alone. A dedicated IP needs consistent sustained volume to build and maintain reputation; an operation that cannot sustain that volume creates a problem it did not need to have.
| Situation | Recommendation |
|---|---|
| Under 50K/month, inconsistent volume | Stay on shared IP, no warming needed |
| 50K-100K/month, consistent | Dedicated IP marginal, evaluate carefully |
| 100K+/month, consistent volume | Dedicated IP appropriate, warming required |
| High volume, multiple streams | Multiple dedicated IPs, warm each |
The substantive point: warming an IP is only worthwhile if the operation will sustain enough consistent volume to keep that IP's reputation healthy afterward. An operation that warms an IP and then sends sporadically will keep losing the reputation to the 30-day decay and keep needing to re-warm, which is more trouble than the dedicated IP is worth. Decide whether a dedicated IP fits the operation before investing the 4 to 8 weeks of warming.
Prerequisites before email one
Before the first warmup email is sent, several things must be in place. Skipping them is the most common reason a warmup fails before it starts.
Authentication live. SPF, DKIM, and DMARC must be configured and verified before email one. In 2026 authentication is non-negotiable, not just recommended. A warmup that begins without proper authentication generates negative signals from the first message.
List verified. Bad data is the single biggest warmup killer. The list should be verified to high accuracy before sending begins, with the goal of keeping bounce rate under 2 percent. A warmup that begins with an unverified list hits bounces and reputation damage in week one regardless of how careful the ramp is.
rDNS configured. The dedicated IP must have proper reverse DNS resolving to a hostname that forward-resolves back to the IP. For PowerMTA this is the smtp-source-host EHLO hostname.
Engaged segment identified. The list of contacts engaged in the last 30 days must be identified, because that segment is what receives the early warmup mail.
Monitoring in place. The bounce rate, complaint rate, and reputation monitoring must be ready before the warmup starts, because the warmup is gated on those metrics.
The most common warmup failure is not a scheduling mistake, it is a data quality mistake. An operator provisions a fresh IP, follows a careful ramp, and still sees 40 percent spam placement and a 5 percent bounce rate, because the list was full of stale and invalid addresses. No ramp schedule fixes that. List verification to high accuracy is step zero of warming, before the ramp schedule is even relevant. If bounce rate climbs above roughly 2 percent in week one, that is a data problem, not a schedule problem, and the warmup should pause until the data is fixed.
The 4 to 8 week timeline
IP warming in 2026 takes 4 to 8 weeks. The exact timeline depends on the inputs:
| Situation | Expected timeline |
|---|---|
| Clean list, high engagement, proper auth | About 4 weeks |
| Larger list, mixed engagement | Closer to 8 weeks |
| Recovering from a prior reputation problem | 8 weeks or more |
A clean, well-engaged list with proper authentication can stabilize in about 4 weeks. Larger lists or lists with mixed engagement push closer to 8 weeks before ISPs grant full trust.
The 2026 environment makes the timeline less forgiving than it once was. The Gmail complaint threshold dropped, meaning even small amounts of negative signal during warmup carry more weight than they did a couple of years ago. A warmup plan should allow the full 4 to 8 weeks and not be rushed, because a rushed warmup that triggers throttling or a reputation problem ends up taking longer than a patient one would have.
Engagement-recency segmentation
The single most important rule of IP warming is engagement-recency segmentation: send only to the most engaged subscribers during the early weeks, and expand the segment gradually as reputation builds.
| Warmup phase | Send to |
|---|---|
| Weeks 1-2 | Contacts engaged in the last 30 days only |
| Weeks 3-4 | Expand to contacts engaged in the last 60 days |
| Weeks 5-6 | Expand further, still avoiding 90+ day inactive |
| First 6 weeks | Never send to 90+ day inactive contacts |
This single rule prevents more warmup failures than any tool or service. The reason it matters so much: ISPs evaluate a new IP heavily on the engagement signals the early mail generates. Highly engaged recent subscribers open, click, and reply, producing the positive signals that build reputation. Inactive subscribers do not engage, may have abandoned their accounts, may have become spam traps, and produce the negative signals that destroy a new IP's reputation.
Sending to the most engaged segment first means the ISP's first impression of the new IP is built from the best possible mail. Expanding the segment gradually means the IP earns trust before it is exposed to the riskier, less-engaged portions of the list.
The critical implication: an operator who follows the day-by-day volume ramp perfectly but sends to the whole list from day one will still fail the warmup. Volume pacing without engagement segmentation does not produce the positive signals the warmup depends on. The segmentation is not optional; it is the core of the warmup.
The volume ramp schedule
The volume ramp gradually increases daily sending volume. A representative conservative schedule:
| Week | Daily volume per IP | Notes |
|---|---|---|
| 1 | 50-100 | Most engaged contacts only, hold and observe |
| 2 | 100-250 | Hold volume 2 days before each increase |
| 3 | 250-500 | Slow increases, roughly 1.5x |
| 4 | 500-1,000 | Monitor bounces closely |
| 5-6 | 1,000-2,500 | Increase at roughly 1.25x |
| 7-8 | 2,500-5,000+ | Approaching full volume |
The exact numbers vary, but the shape is consistent: start very low (50-100 per day), increase by a modest multiple (early increases around 20 percent daily or 1.5x weekly, later increases more gradual), and reach full volume over 4 to 8 weeks.
Two important pacing points. First, send daily. Dropping to a few sends per week means inbox providers take longer to assess reputation and the warmup extends. Consistent daily sending is part of the signal the ISP evaluates. Second, do not split ISPs across days. Each ISP should receive a comparable amount of warmup mail each day; warming Gmail on Monday and Yahoo on Tuesday means each ISP sees inconsistent sending, which works against the warmup. Spread the daily volume across all destination ISPs each day.
Configuring VMTA throttling for warmup
PowerMTA enforces the warmup ramp through VMTA-level throttling. The pattern: a dedicated VMTA for the warming IP, with domain block throttling set to the current week's volume, adjusted as the warmup progresses.
The warming VMTA:
<virtual-mta warmup-vmta>
smtp-source-host 203.0.113.80 warmup.example.com
domain-key wk,example.com,/etc/pmta/keys/warmup.pem
</virtual-mta>Week 1 throttling, very conservative:
<domain gmail.com>
<virtual-mta warmup-vmta>
max-msg-rate 10/h
max-conn-rate 2/m
max-smtp-out 2
</virtual-mta>
</domain>The per-VMTA domain block lets the warmup throttling apply specifically to the warming IP while other VMTAs in the deployment send at their normal rates. As the warmup progresses, the operator raises the max-msg-rate weekly to match the ramp schedule, applying each change with pmta reload.
Week 4 throttling, mid-warmup:
<domain gmail.com>
<virtual-mta warmup-vmta>
max-msg-rate 60/h
max-conn-rate 5/m
max-smtp-out 3
</virtual-mta>
</domain>The throttling enforces the ramp at the PowerMTA level, so even if the application accidentally queues more than the warmup-week volume, PowerMTA paces the actual delivery to the warmup rate. This is more reliable than depending on the application to send at the right pace.
The operator schedules the weekly throttle increases as a calendar task, raising the rates each week, and verifies with pmta show settings that each change took effect. When the warmup completes, the warming VMTA's throttling is set to the normal warm-IP rates and the IP joins the regular VMTA pool.
Per-ISP warmup considerations
The major ISPs have somewhat different warmup behavior, and the warmup should account for the differences.
Gmail. Gmail evaluates engagement heavily, so the engagement-recency segmentation matters most for Gmail. Gmail's complaint threshold is strict in 2026, so the Gmail portion of the warmup is the least forgiving. Watch Gmail Postmaster Tools closely during the warmup for the reputation trend.
Yahoo. Yahoo is sensitive to volume increases and throttles aggressively with TSS04 codes. The Yahoo warmup should be conservative, and the operator should expect to see TSS04 deferrals if the ramp is too aggressive; TSS04 during warmup is the signal to slow down. Note that the Yahoo family now includes Comcast and AT&T addresses after the 2025 infrastructure consolidation.
Microsoft. Outlook and Hotmail evaluate reputation through SNDS, so enroll the warming IP in SNDS at the start of the warmup to watch the reputation data build. Microsoft can be slower to extend trust, so the Microsoft portion of the warmup may take the full timeline.
The per-ISP point reinforces the rule about not splitting ISPs across days: each ISP needs to see consistent daily sending to evaluate the IP, so the daily warmup volume should be distributed across Gmail, Yahoo, Microsoft, and the other destinations each day rather than concentrated on one ISP per day.
Thresholds that pause a warmup
A warmup is gated on metrics. When the metrics cross certain thresholds, the warmup should pause rather than continue ramping.
| Metric | Pause threshold | Why |
|---|---|---|
| Bounce rate | Above ~2% | Data quality problem, fix list first |
| Complaint rate | Above 0.1% | Gmail 2026 threshold, negative signal |
| Spam placement | Significant spam folder rate | Reputation not building, ramp too fast |
| ISP throttling codes | TSS04, S3140 appearing | The ISP is signalling slow down |
The pause logic: if the bounce rate climbs above roughly 2 percent, that is a data quality problem, and the warmup pauses until the list is fixed. If the complaint rate exceeds 0.1 percent (the strict Gmail 2026 threshold), the warmup pauses because the negative signal is damaging the reputation the warmup is trying to build. If ISP throttling codes appear, the ramp is moving too fast and should hold or step back.
When a warmup pauses, the operator does not just wait; the operator holds volume at the current level (or reduces it), fixes the underlying problem (clean the list, investigate the complaints, address authentication), and resumes the ramp only when the metrics are back in the healthy range. A warmup that pushes through bad metrics does not build reputation, it destroys it.
The 30-day reputation decay
Most ISP reputation systems retain reputation data for only about 30 days. This decay has an important operational consequence: an IP that stops sending for roughly 30 or more days loses its reputation and effectively becomes a fresh IP.
The implications:
- An IP idle for over 30 days needs to be re-warmed before resuming full volume. Resuming full volume on a dormant IP produces the same reputation problem as a brand-new IP.
- A re-warm can sometimes be faster than an initial warmup if the IP and domain retain residual signals, but it should still be a deliberate ramp, not an immediate return to full volume.
- An operation that sends inconsistently, with gaps over 30 days, will keep losing reputation to the decay and keep needing to re-warm. This is a reason such an operation is better off on a shared IP.
The decay is also why the warmup must be followed by consistent sustained sending. A warmup builds reputation; consistent volume maintains it. An operator who completes a careful 8-week warmup and then sends sporadically watches the reputation decay away, wasting the warmup investment.
When a warmup stalls
Sometimes a warmup does not progress as expected: the reputation is not building, spam placement stays high, or throttling persists. The diagnostic procedure:
Step 1: check the data quality. Is the bounce rate elevated? An elevated bounce rate means the list still has bad addresses, and the warmup cannot succeed until the list is clean. This is the most common cause of a stalled warmup.
Step 2: check the engagement segmentation. Is the warmup actually sending only to the engaged segment? A warmup that has crept into less-engaged contacts loses the positive signal it depends on. Verify the segment.
Step 3: check authentication. Confirm SPF, DKIM, DMARC, and rDNS are all correct. An authentication problem undermines the warmup regardless of ramp discipline.
Step 4: check the ramp speed. Is the ramp too aggressive for the list and the ISPs? If throttling codes are appearing, slow the ramp, hold volume longer at each step.
Step 5: check the complaint rate. Is the complaint rate above 0.1 percent? Complaints during warmup are especially damaging. If complaints are elevated, the engaged segment may not be as engaged as assumed, or the content may be triggering complaints.
Step 6: check per-ISP reputation. Use Gmail Postmaster Tools and Microsoft SNDS to see which specific ISP is the problem. The stall may be concentrated at one ISP, which narrows the investigation.
Step 7: hold and stabilize. When a warmup stalls, the response is usually to hold volume at the current level (not increase, not necessarily decrease) while fixing the identified cause, then resume the ramp once metrics are healthy. Pushing the ramp forward through a stall makes the problem worse.
An operator we worked with was on their third attempt to warm a new dedicated IP. Each attempt followed a textbook ramp schedule, and each attempt stalled around week three with spam placement climbing and Gmail reputation refusing to build. They were convinced the ramp schedule was wrong and kept adjusting the daily volume numbers. The actual problem had nothing to do with the schedule. Their list had not been verified, and roughly 8 percent of the addresses were invalid or stale. Every warmup attempt hit a bounce rate well above 2 percent in week one, which was a clear data-quality signal they had been treating as a scheduling issue. The fix was step zero of warming: verify the list. They ran the full list through verification, removed the invalid addresses, and the verified list bounced at under 1 percent. The next warmup attempt, with the same ramp schedule they had used before, succeeded cleanly and the IP stabilized in about five weeks. The lesson is the one the warmup prerequisites emphasize: a warmup is only as good as the data behind it. Bounce rate above 2 percent in week one is a data problem, and no amount of ramp-schedule tuning fixes a data problem. Verify the list before the warmup, and a careful ramp does its job; skip verification, and the best ramp schedule in the world still fails.
IP warming in PowerMTA is a disciplined process: decide whether a dedicated IP fits the operation at all, get the prerequisites right before email one, follow the 4 to 8 week ramp, and above all apply engagement-recency segmentation, the single most important rule. PowerMTA's per-VMTA throttling enforces the ramp reliably when configured correctly. The metrics gate the warmup: bounce rate above 2 percent or complaint rate above 0.1 percent means pause and fix, not push through. The 30-day reputation decay means a warmed IP must be kept consistently active, and a dormant IP must be re-warmed. Operators who treat warming as a patient, data-driven, segmentation-first process build dedicated IPs that deliver reliably; operators who rush the ramp, skip the segmentation, or warm an unverified list burn the IP before it ever earns the trust the warmup was meant to build.