You've just been handed a fresh Salesforce Marketing Cloud tenant, or a client is finally moving off a shared IP onto a dedicated one. The temptation is obvious: push the monthly newsletter to the whole database and get on with it. That single send is the fastest way to destroy a sending reputation you haven't built yet. Mailbox providers judge an unknown IP on its first few days of activity, and a decision made in week one can drag on your inbox placement for six months. This guide walks through a practical 30-day IP warming plan for SFMC, including the SQL, the automation, and the metrics that actually tell you whether it's working.

Why IP warming decides your next six months

An IP address with no history is not neutral to Gmail, Microsoft, or Yahoo. It is suspicious by default. Spam filters build a behavioural profile from volume, sending consistency, complaint rate, and above all engagement. A sudden burst of 400,000 messages from an IP that was silent yesterday looks, statistically, exactly like a spam campaign.

Two reputations run in parallel: the IP and the sending domain. Warming addresses the first, but the domain is heating up at the same time. If you're changing IP and authenticated domain simultaneously, assume you're starting from zero on both axes and stretch the ramp accordingly.

When warming is genuinely required

• A new SFMC tenant with a dedicated IP
• Moving from a shared IP to a dedicated one
• A new sending domain via Sender Authentication Package
• Resuming sends after more than 30 days of inactivity
• Any sustained volume increase above 50% of your normal run rate

Get the foundations right before day one

No volume ramp compensates for incomplete authentication. Before your first send, confirm three things in the Business Unit.

First, the Sender Authentication Package must be live and propagated: SPF published, DKIM signing on the sending domain, and a DMARC record at minimum on p=none with a monitored rua address. Second, the Sender Profile and Delivery Profile attached to the warming sends must point at the right IP. In a multi-IP account, one wrong Delivery Profile routes your warming traffic to the wrong address and quietly invalidates the entire plan. Third, Reply Mail Management needs to be configured so bounces are processed rather than discarded.

; Content-side guard rail: stop a send if the warming
; phase has not been declared for this business unit
%%[
  SET @bu = AttributeValue("memberid")
  SET @phase = Lookup("Warmup_Control","Phase","BUID",@bu)
  IF EMPTY(@phase) THEN
    RaiseError("No warming phase defined for this BU", true)
  ENDIF
]%%

Build the audience spine: your most engaged subscribers first

The core principle of warming is straightforward: early sends must generate the best possible signals. Opens, clicks, replies, address-book adds. So you start with your most recently active subscribers and widen gradually into colder segments.

In SFMC, that hierarchy comes out of the Data Views. The query below buckets subscribers into five engagement tiers, warmest to coldest:

SELECT
    s.SubscriberKey,
    s.EmailAddress,
    MAX(o.EventDate) AS LastOpen,
    CASE
        WHEN MAX(o.EventDate) >= DATEADD(day, -30,  GETDATE()) THEN 1
        WHEN MAX(o.EventDate) >= DATEADD(day, -60,  GETDATE()) THEN 2
        WHEN MAX(o.EventDate) >= DATEADD(day, -90,  GETDATE()) THEN 3
        WHEN MAX(o.EventDate) >= DATEADD(day, -180, GETDATE()) THEN 4
        ELSE 5
    END AS WarmupTier
FROM _Subscribers s
INNER JOIN _Open o
    ON o.SubscriberKey = s.SubscriberKey
WHERE s.Status = 'Active'
GROUP BY s.SubscriberKey, s.EmailAddress

Then suppress, without exception, every address that has produced a hard bounce, a complaint, or an unsubscribe. An unclean list during warming generates a high bounce rate on a fragile IP, and that is precisely the scenario that triggers the longest-lasting blocks.

The 30-day ramp

Here's a reference ramp for a target list of roughly 500,000 subscribers. Scale the numbers to your own database. The rule that matters is this: never more than double daily volume from one sending day to the next.

Days	Daily volume	Tiers included	Cadence
1-3	2,000	Tier 1	1 send / day
4-7	5,000-10,000	Tier 1	1 send / day
8-12	20,000-40,000	Tiers 1-2	1 send / day
13-18	60,000-100,000	Tiers 1-3	1-2 sends / day
19-24	150,000-250,000	Tiers 1-3	2 sends / day
25-30	300,000 to target	Tiers 1-4	Normal cadence

Tier 5 — subscribers inactive for more than six months — should never appear in a warming plan. Handle them once the IP has stabilised, in a dedicated re-engagement campaign with a hard volume cap.

IP warming is not a calendar you execute mechanically. It is a feedback loop. If complaint rate passes 0.1% or bounce rate passes 2% at any single mailbox provider, you do not advance to the next step — you repeat the previous one until the numbers recover.

Automate the daily selection

Running 30 days of warming by hand invites mistakes. The sturdiest pattern is a control Data Extension, Warmup_Control, holding the current day, the permitted volume, and the active tiers, with a Query Activity populating the send Data Extension every morning.

SELECT TOP 40000
    t.SubscriberKey,
    t.EmailAddress,
    t.WarmupTier
FROM Warmup_Audience t
INNER JOIN Warmup_Control c
    ON c.TierMax >= t.WarmupTier
WHERE t.SubscriberKey NOT IN (
        SELECT SubscriberKey FROM Warmup_Sent_Log
      )
ORDER BY t.WarmupTier ASC, t.LastOpen DESC

A daily Automation then chains: update Warmup_Control, run the selection query, send, write back to Warmup_Sent_Log. That guarantees no subscriber is over-mailed during the ramp and that volume stays capped even if someone launches an unrelated campaign in parallel.

Watch the right numbers, provider by provider

A headline delivery rate of 96% can conceal a complete block at one major provider. During warming, every metric has to be read split by recipient domain.

SELECT
    RIGHT(s.EmailAddress, LEN(s.EmailAddress) - CHARINDEX('@', s.EmailAddress)) AS Domain,
    COUNT(DISTINCT j.SubscriberKey) AS Sent,
    COUNT(DISTINCT b.SubscriberKey) AS Bounced,
    COUNT(DISTINCT o.SubscriberKey) AS Opened
FROM _Sent j
LEFT JOIN _Bounce b ON b.JobID = j.JobID AND b.SubscriberKey = j.SubscriberKey
LEFT JOIN _Open   o ON o.JobID = j.JobID AND o.SubscriberKey = j.SubscriberKey
INNER JOIN _Subscribers s ON s.SubscriberKey = j.SubscriberKey
WHERE j.EventDate >= DATEADD(day, -1, GETDATE())
GROUP BY RIGHT(s.EmailAddress, LEN(s.EmailAddress) - CHARINDEX('@', s.EmailAddress))

Pair this with Google Postmaster Tools and Microsoft SNDS, which expose data SFMC simply cannot see: IP and domain reputation, user-reported spam rate, DMARC alignment. Both are free, and both should be configured before day one rather than after the first incident.

The mistakes that cost the most

Three failures show up in almost every warming we audit. The first is the opportunistic volume jump: a promotion lands in week two and doubles the plan overnight. The second is inconsistency — sending for three days, pausing for five, and giving back much of the reputation you earned. The third is generic content: during warming every message has to maximise engagement, so lead with high-value transactional messages and genuinely personalised content rather than a catch-all newsletter.

If you're planning a tenant migration, an IP change, or a broader SFMC deliverability project, our team can audit your setup and build the ramp that fits your list: get in touch.

Key takeaways

Never more than double. A factor of two between consecutive sending days is the sensible ceiling; beyond that, filters react.

Start with your warmest subscribers. The first 30 days exist to manufacture engagement signals, not to cover the database.

Authenticate before you warm. Working SPF, DKIM, and DMARC are a prerequisite, not a later optimisation.

Monitor per provider, not on averages. A flattering aggregate can hide a total block at Gmail or Outlook.

Automate the ramp. A control Data Extension plus a daily Automation removes human error and unplanned parallel sends.