Email domain warm up: how to warm a new domain or IP address

Domain or IP: what you are warming#

Google’s summary of the method is one line: “Start with a low sending volume to engaged users, and slowly increase the volume over time.”^[1] Everyday one-to-one mail from your own inbox needs none of this; warm-up is about volume from a new domain or a new IP address.

Picture a shop that moves its newsletter to a fresh subdomain and sends to all 40,000 subscribers on the first morning. By lunchtime Gmail is delaying most of it. It answers with deferrals, temporary “try again later” refusals, and the rest of the batch waits to be retried. Nothing in the message was wrong. The domain had no history, and the first thing Gmail saw was a spike.

M3AAWG (the Messaging, Malware and Mobile Anti-Abuse Working Group), whose Sender Best Common Practices this guide leans on, explains why: a new domain’s reputation “usually starts as unknown, which makes it similar to bad in that it does not yet have any sending history.”^[2]

An IP address is the numeric address of the server your mail leaves from. Most sending services put many customers on a shared pool of addresses that the service keeps in use; a dedicated IP carries only your mail. Providers keep a reputation for both: “Gmail tracks volume, feedback, and limits per domain and IP address.”^[1]

A new subdomain such as news.example.com needs its own warm-up, even under a parent domain with years of good history. M3AAWG advises against counting on the parent’s record: “When sending from a new subdomain, to be safe, domain warming is recommended even if the organizational level domain already has an established reputation.”^[2] Whether marketing needs a subdomain at your volume is in the subdomain guide. A dedicated IP is not better by default. M3AAWG says “Consistency of volume, whether high or low, plays an integral part in the determination of IP reputation”,^[2] and a small or bursty sender alone on an address gives providers too little to judge. One record belongs to the address rather than the domain: the PTR record, which Google and Yahoo expect for every sending IP.^[1][5] On a shared pool your provider sets it, not you.

How long does a warm-up take?#

Among the mailbox providers, only Microsoft publishes a figure: “A new IP can expect to be fully ramped within a couple of weeks or sooner depending on volume, list accuracy and as long as their junk email complaint rates are kept at a minimum.”^[3] Google and Yahoo publish none, so you set the pace per provider by how each one answers you. At Microsoft that answer can be a refusal rather than a delay: its error list includes 550 rejections “related to content with spam-like characteristics or IP/domain reputation.”^[3]

Google gives no duration, but it names what sets the pace:

1. How much you send. “The more email that you send, the more slowly you should increase sending volume.”
2. How often you send. “You can increase the sending volume more quickly when you send daily instead of weekly.”
3. How big each jump is. “Immediately doubling previously sent volumes suddenly could result in rate limiting or reputation drops.”^[1]

From here on, anything not quoted or cited is our own practice rather than a provider’s rule: the durations, the step size, the engagement windows and the stop rule. Applying Google’s three rules, a list of a few thousand that you can mail daily often finishes in about two weeks; mailed weekly, each issue is one step, so it takes longer.

Before the first send#

Postmaster Tools may stay empty at first: “Data might be missing if the total number of messages for a given day is too low.”^[6] How the authentication records work is in DKIM, SPF and DMARC explained.

Dedicated IP only. On a shared pool the address-level work is your sending provider’s, so skip this. If the sending IPs are yours, join two Microsoft programmes: Smart Network Data Services, “available to anyone who can prove they own an IP range”, which reports each address’s complaint rate,^[7] and the Junk Email Reporting Program, to which Microsoft asks you to add every new IP.^[3]

Who to send to first#

The first sends go to the people most likely to want the mail, because their reactions are the evidence. Split your consented list by things a person has to do:

• Warmest: clicked, replied or bought in the last 30 days, or signed up in that time.
• Warm: did one of those in the last 90 days.
• The rest: did one of those in the last 12 months.

Leave out anyone silent for longer than a year; sunsetting inactive subscribers explains why old addresses bounce and turn into spam traps. If the warmest group is smaller than your first step, send to all of it and widen the window (60 days, then 90) until the step is full. A store can build these groups from its customer export, filtered by last order date. Readers who open but never click land in the last group or outside it; once the ramp is done they get your normal mail again, and the sunset guide decides who to drop.

Do not use opens to pick them. Apple’s Mail Privacy Protection downloads remote content, tracking pixels included, “in the background by default” and “regardless of whether you engage with the email”,^[8] so Apple Mail users register opens they never made. Why opens can’t tell you who is inactive has the detail.

Example schedules, from 300 contacts to 50,000 a day#

These schedules put engaged recipients first and make each step about one and a half times the one before. Move up only after a clean step, as defined in the next section.

A few thousand contacts#

Take a list of 4,000. Mailing daily, send each step’s volume on two days in a row; the same people get both days’ mail, as they would anyway. Mailing weekly, each step is one issue.

Mailing weekly, that is seven issues, and the people outside each step miss that issue. To get there sooner without leaving anyone out for long, split each issue into two or three segments (by sign-up date, say) and schedule each as its own send on a different day, each one a step.

A few hundred contacts#

At 300 contacts the whole list is low volume, so there is little to ramp. Start with the 30-day group, keep a steady rhythm (“It’s preferable to send campaigns on a regular basis until the domain is sufficiently warmed up”^[2]) and watch your own numbers, because each complaint weighs more: one in a send of 300 is a third of a percent.

Working up to 50,000 a day#

Two steps a week, each held for two to four days. A large list that mails weekly needs the same steps split into separate sends across the week, or it takes twelve issues.

How to send each step#

Spread each day’s mail out. M3AAWG: “Do not send your daily batch all at once.”^[2] If you make significant changes to your sending setup or your headers mid-way, Google asks you to “increase the modified segment of traffic separately.”^[1] Receipts and password resets cannot wait for a ramp: let them flow at their natural rate and ramp only the marketing. A marketing subdomain keeps the two apart in your data; transactional vs marketing email draws the line between them.

What to watch, and when to slow down#

Judge each step against the one before, provider by provider. You do not need code for that: filter the step’s delivery report by recipient address (@gmail.com, @outlook.com and @hotmail.com, @yahoo.com), which covers most of a consumer list. A step was not clean if any of these happened:

• the hard-bounce rate, not the count, at least doubled from the step before (with fewer than five bounces, wait for the next step before judging);
• one provider was still deferring mail the next day;
• the spam rate passed 0.1% at any provider; below 1,000 messages one complaint is already over that, so there take two complaints in a step as the stop. Google asks senders to “Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher”,^[1] and Yahoo says “Keep your spam rate below 0.3%”.^[5] How each is measured is in the spam complaint rate guide.

Complaint figures come from a different place at each provider: Gmail’s only from Postmaster Tools, which may be blank at low volume; Yahoo’s from its Complaint Feedback Loop (“Use the CFL to monitor your complaint rate”);^[5] Microsoft’s from the Junk Email Reporting Program.^[3] A sending service collects the feedback loops for you; until Postmaster Tools fills in, watch the complaints it reports from Yahoo and Microsoft recipients, and hold Gmail if its unsubscribe rate is double the others’. A step that is not clean costs the days you hold it plus a repeat: two to four days in the 4,000 example, four to eight in the 50,000 one.

When a provider defers you#

Google’s instruction: “If messages start bouncing or start being deferred, reduce the sending volume until the SMTP error rate decreases. Then, increase slowly again.” Its rate limit has a code of its own, 4.7.28. After one, Google asks you to:^[1]

1. stop sending for at least 10 minutes;
2. resume from a single connection;
3. add connections back one at a time.

Those steps are for whoever runs the sending servers. Through a sending service you never hold the connections, so they are the service’s job. Yours is the volume, as in the table above, while the other providers stay on schedule.

Yahoo’s temporary refusals carry codes beginning TS; it names complaints and an IP’s poor reputation as causes and asks for a Sender Support Request if the same one persists.^[4] M3AAWG adds that you “may need to slow down sending to some or all domains if you see deferral spikes”,^[2] so one slow provider can get its own pace while the others carry on. A deferral is retried; a bounce is final (see hard bounce vs soft bounce).

Spam reports and clicks#

M3AAWG reads engagement both ways: a drop “may indicate your mail is going to the junk folder”, and large spikes “may indicate security appliances giving your mail extra scrutiny.”^[2] Watch clicks, not opens, and per provider: a problem at one is hidden in a combined number. Leave out clicks a company’s link scanner made, or a step to business addresses looks better than it was; how to tell a scanner’s click from a reader’s shows the signs.

A seed test, a send to a set of test inboxes that reports where each filed it, catches a broken signature before the first step. During the ramp it says less: those inboxes have never heard from you, unlike your engaged subscribers.

If you send through Rasket#

Rasket’s pricing page lists managed shared IPs on every plan and says “Shared pools are kept in good standing”,^[10] so there is no IP for you to warm and no reverse DNS for you to set up. Rasket does not publish how its shared addresses are grouped. What it does publish are the brakes on its own customers, the part of keeping a pool clean that you can see. On a paid plan, a new account can send 100 emails an hour and 500 a day for its first 24 hours, then 1,000 a day, doubling with each day sent without bounce or spam problems, until it is a week old.^[13] An account whose mail bounces or is reported as spam too often has its sending limited.^[11]

What is new is your domain, and Rasket does not ramp a new domain for you. Those limits are on your account, not a warm-up schedule for your domain, but they shape a launch. They count every email the account sends, receipts included, so a brand-new account reaches at most 500 people on day one however warm they are. Open the account and verify the domain at least a week before launch, and start the ramp then.

To run the schedule, send each step as a Campaign to a segment. A segment filters on your contacts’ fields and properties, not on past clicks,^[14] so the engagement groups come from your own data. Rasket’s import docs describe adding a true-or-false column from a spreadsheet, such as “bought in the last 30 days”, to your contacts,^[12] and a segment can filter on it. Re-import the column before each step so it stays current.

Rasket’s metrics break results down by sending domain, campaign or email, not by the recipient’s provider. To check one provider after a step, search the step’s emails by recipient domain: the list-emails search matches recipient addresses, and each email carries its last event, such as delivery_delayed or bounced.^[15] Its pricing page offers a dedicated IP from the Scale plan up, recommended from 5,000 emails a day, that warms up on its own schedule while your mail keeps flowing.^[10] A new domain on it still needs the ramp above.

A warm-up is the wrong fix when the list is the problem. If the first step, sent to your warmest group, bounces or draws complaints, a slower schedule will not repair it. Google’s advice when errors continue at low volume is to “review individual messages to identify problems.”^[1] Clean the list first, then work through why emails go to spam before you restart the ramp.

For developers: deferrals per provider from events#

Through an API you never see the SMTP replies. Rasket’s events docs list an email.delivery_delayed event for each deferral, carrying the receiver’s status code and text for each delayed recipient.^[9] Group them by the recipient domain’s mail servers (its MX record), not the domain itself: a company on Google Workspace or Microsoft 365 has its own domain but those providers’ servers. This handler caches one lookup per domain and prints a line per delayed recipient:

// Count deferrals per receiving provider (Node 18+, ES module).
import { resolveMx } from "node:dns/promises";

const PROVIDERS = [
  [".google.com", "Gmail / Google Workspace"],
  [".googlemail.com", "Gmail / Google Workspace"],
  [".olc.protection.outlook.com", "Outlook.com"],
  [".mail.protection.outlook.com", "Microsoft 365"],
  [".yahoodns.net", "Yahoo"],
];
const mxCache = new Map(); // recipient domain -> provider
const deferrals = new Map(); // provider -> count

async function providerFor(domain) {
  if (!mxCache.has(domain)) {
    const mx = await resolveMx(domain).catch(() => []);
    mx.sort((a, b) => a.priority - b.priority);
    const host = (mx[0]?.exchange ?? "").toLowerCase();
    const known = PROVIDERS.find(([suffix]) => `.${host}`.endsWith(suffix));
    mxCache.set(domain, known ? known[1] : host || "no MX");
  }
  return mxCache.get(domain);
}

export async function onEvent(event) {
  if (event.type !== "email.delivery_delayed") return;
  for (const r of event.data.delay.delayedRecipients) {
    const domain = r.emailAddress.split("@")[1].toLowerCase();
    const provider = await providerFor(domain);
    deferrals.set(provider, (deferrals.get(provider) ?? 0) + 1);
    console.log(provider, r.status, r.diagnosticCode);
  }
}