What Is Email Warmup, and Does It Still Work in 2026?

Every cold email tool sells warmup. Almost none of them explain what reputation is actually made of, which means almost none of them can explain what warmup does or doesn't move. As of 29 September 2026, every page ranking for "email warmup" is published by a company that sells it. That is not a footnote; it is the reason this page exists.

This is the mechanism, the parts that are load-bearing, the parts that have quietly stopped working, and three things Google publishes about its own system that will change how you set this up.

The one-paragraph version

A brand-new sending domain has no history. Mailbox providers have never seen mail from it, so they have no basis for trust, and cold outbound looks, statistically, a great deal like the thing they are paid to block. Warmup is the practice of sending a small, slowly increasing volume of mail that gets opened and replied to, so the provider accumulates a positive record for your domain before you send anything that matters.

Low volume, rising slowly, with engagement. Everything else is implementation detail. Google's own sender guidelines say exactly this much and no more: "Start with a low sending volume to engaged users, and slowly increase the volume over time." No timeline, no increments. The 4-week and 6-week ramps you read everywhere are vendor convention, not provider guidance.

What reputation is actually made of

This is the part that gets skipped, and it's the part that tells you what to spend effort on. Google exposes its own scoring inputs through Postmaster Tools, and the dashboard list is the answer to "what am I being judged on":

Now read the four reputation levels Google publishes, because the wording is unusually direct:

• High: "very low spam rates, rarely marked spam"
• Medium: "legitimate email with occasional spam"
• Low: "significant spam history, likely marked spam"
• Bad: "high spam volume, almost always marked spam"

Every one of those definitions is phrased in terms of spam marks. Not opens. Not replies. Not warmup. The thing the reputation ladder is built on is how often humans press the spam button, and warmup pools cannot produce a spam mark or prevent one.

That is the single most useful fact in this post: warmup is an indirect input to a system whose primary input is complaint rate. It is not useless (a slow ramp genuinely avoids the volume spike that reads as a burner domain) but it sits well below list quality and authentication in what actually moves.

Two things Google publishes that almost nobody accounts for

1. Your spam-rate dashboard is partly blind for B2B

Google states the spam rate figure covers "only DKIM-authenticated messages to personal Gmail accounts."

If you are doing B2B outbound to @company.com addresses (which is most cold email) a large share of your volume goes to Google Workspace mailboxes, not personal Gmail. Those recipients' spam marks do not appear in your spam-rate dashboard. Your Postmaster spam rate can read near-zero while B2B recipients complain at a rate that is genuinely hurting you.

What to do about it: treat Postmaster spam rate as a floor, not a measurement. Watch domain reputation and delivery errors alongside it, and watch your own reply-to-complaint ratio in the sequencer. Do not conclude "0.00% spam rate, we're fine."

2. Bulk sender status is permanent, and subdomains count

From Google's sender guidelines FAQ: the 5,000-messages-per-day threshold is calculated across "all messages sent from the same primary domain": subdomains roll up to the primary domain. And once you cross it: "Bulk sender status doesn't have an expiration date" and "changes in email sending practices will not affect permanent bulk sender status once it's assigned."

Three consequences:

• mail.yourcompany.com and send.yourcompany.com and yourcompany.com are one bucket. Splitting sends across subdomains does not split the count.
• One busy day is forever. Cross 5,000 once (a product launch, a migration, a misconfigured loop) and the full bulk-sender requirement set applies to that domain permanently.
• Separate root domains are the only real separation, which is the actual technical reason cold email runs on distinct registered domains rather than subdomains of the company domain. The usual explanation ("protect your main domain's reputation") is true but incomplete; this is the mechanical half.

3. Spam rate is calculated daily

Not averaged over a month. Daily. Google's guidance is to stay under 0.10% and never let it reach 0.30%, and since June 2024, bulk senders above 0.30% are ineligible for mitigation, meaning you cannot appeal your way out.

At 0.10% you are allowed one spam complaint per 1,000 sends. Run that arithmetic against a 50-mailbox setup sending 30/day and you get 1,500 daily sends and a budget of roughly one and a half complaints per day. Cold email has very little headroom, and the headroom is measured every day.

The part that is not optional: authentication

Before reputation matters at all, three DNS records have to be right. These are a gate, not a curve.

Google, since 1 February 2024: for all senders: SPF or DKIM, valid forward and reverse DNS (PTR), TLS in transit, RFC 5322-conformant message format, spam rate under 0.3%. For senders above 5,000/day to Gmail: SPF and DKIM and DMARC, with the From: header's organizational domain aligned to either the SPF or the DKIM organizational domain, plus one-click unsubscribe on marketing and subscribed mail. Google adds that it "recommends all senders fully align DMARC to both SPF and DKIM" and that "it's likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement": a fairly clear signal about where this goes.

Microsoft, since 5 May 2025: per Microsoft's own announcement, domains sending 5,000+ messages to Microsoft consumer mailboxes must pass SPF and DKIM and publish DMARC at p=none or stronger, aligned to at least one. Non-compliant mail goes to Junk, and failures are rejected at the SMTP layer:

Read that carefully. Rejected, not spam-foldered. That is the defining change of the 2024–2026 enforcement wave: the failure mode moved from "nobody saw it" to "the server refused the handoff." Your sequencer will surface this as a hard bounce, which will look like a bad-list problem, which will send you to re-verify your list, while the actual cause is a DNS record. Learn to recognise the code.

No amount of warmup affects any of this. The copy-paste records are in the manual warmup guide.

Does warmup still work? Honestly: partly

Here is where the vendor pages get evasive, so let me split it into what's solid, what's degrading, and what was never the point.

What still works, and costs nothing

Gradual volume increase. A domain that goes from zero to 500 sends on day one looks exactly like a domain purchased to burn. This is the piece Google actually endorses in writing, it requires no tool, and it is most of the value.

Real engagement. Genuine replies from genuine conversations are indistinguishable from what warmup pools try to simulate, because they are what warmup pools try to simulate. If you have a handful of mailboxes, you can produce the real thing.

What is degrading: the pool

A warmup network is, structurally, a large set of mailboxes exchanging short similar messages with each other on a schedule, at volumes and intervals set by one piece of software. Multiple deliverability vendors now report that Google and Microsoft discount or ignore engagement attributed to coordinated pools, meaning the sends consume your daily budget while contributing nothing.

[unverified: this is vendor-reported and not documented by any mailbox provider] Neither Google nor Microsoft publishes anything about warmup-pool detection, and neither is likely to. Every specific mechanism you will read described (pattern matching on reply timing, thread shape, message length, network graph analysis) comes from a party that sells warmup or sells an alternative to it. Treat the direction as credible and any specific mechanism as unverified.

The same vendor reporting pushes the realistic ramp to roughly 5–6 weeks rather than the 3–4 weeks most warmup products advertise. Also a claim. But it errs usefully: assume longer.

What was always more important

Look back at the reputation table. Complaint rate is measured and self-reported by recipients. Bounce rate is measured. Authentication is binary and verifiable. Warmup engagement is inferred, by a system that is explicitly trying to detect inauthenticity.

A verified list sent from an authenticated domain at sane volume will outperform a thoroughly warmed domain sending to a scraped list. Every time. The measured inputs win over the inferred ones.

How would you even know if it's working?

Worth stating plainly, because no warmup product answers this honestly: you cannot measure warmup directly. Nobody outside the mailbox providers can.

What you can watch is the provider's own verdict (domain reputation in Postmaster moving Low → Medium → High over weeks, authentication holding at 100%, delivery errors trending to zero) plus your own hand-built seed list and, eventually, the reply rate on real sends.

What you should not treat as evidence is the warmup tool's own dashboard. A pool reporting "95% inbox placement" is reporting on mail delivered to mailboxes that were paid to receive it and are configured not to complain. The pool is not your audience. The full set of checks, and how much each is worth, is here.

So do you need a warmup tool?

The checklist that actually precedes a first real send

• SPF, DKIM and DMARC published and passing: verified by reading Authentication-Results in a received header, not by a tool's green checkmark.
• Reverse DNS / PTR resolves for the sending host.
• Postmaster Tools added and verified on the sending domain, with the B2B blindness above understood.
• One-click unsubscribe (RFC 8058) in the headers, and a process that honours requests within 48 hours, which is Google's stated expectation.
• List verified, with catch-alls handled deliberately rather than accidentally.
• A daily volume plan that keeps each root domain under 5,000/day, deliberately, to avoid permanent bulk-sender status you didn't intend.
• dig output read for all four records: SPF (exactly one v=spf1), DKIM, DMARC, PTR. Your registrar's UI reports what it saved; dig reports what the world sees.
• Written abort thresholds: decided before you start, because in week three you will want to negotiate with them.

If 1–7 are done, warmup is an optimisation worth doing. If they aren't, warmup is theatre.

What this page does not know