A brand-new domain doesn't start neutral with Gmail and Microsoft 365. It starts with an implicit reputation deficit, and no amount of clever copy fixes that on day one. Mailbox providers evaluate domain trust at the network level before content ever enters the picture, which means the warming process is infrastructure work, not a copywriting problem.
Why a new domain is treated as a risk by default
Domain registration data is public and indexed. Automated security systems at major mailbox providers flag recently registered domains and apply extra scrutiny regardless of what you send from them. That's a mechanism, not a specific published number: Google and Microsoft's 2024-2025 enforcement tightening means an un-aged, unauthenticated domain will trigger throttling or Junk routing on the basis of infrastructure signals alone, independent of message quality (Google email sender guidelines).
The practical implication is that warming isn't optional polish before you start cold outreach. It's the mechanism by which a domain earns enough trust to be evaluated on content and engagement at all, rather than being defaulted to Spam.
Get authentication right before you send a single message
SPF, DKIM, and a DMARC record should exist before any warmup traffic goes out, not after. This matters more than it might seem: Google and Yahoo's bulk sender rules, in effect since February 1, 2024, require full SPF, DKIM, and a published DMARC record once a domain crosses roughly 5,000 messages a day to personal accounts, and that bulk sender classification is permanent once triggered. A domain that starts small but has real growth plans should authenticate fully from day one rather than treating it as a threshold to hit later. Retrofitting authentication onto a domain that's already sending is a much rockier process than starting clean.
RFC 8058 one-click unsubscribe headers are also now a hard requirement for bulk senders at both Google and Microsoft, so it's worth building that into your sending platform configuration during setup rather than bolting it on under pressure later.
A realistic ramp timeline
There's no single official ramp schedule published by Google or Microsoft. What exists is convergent guidance across independent deliverability vendors that lines up closely enough to be a reasonable baseline: age a new domain at least two weeks before sending anything, start around 5 to 10 emails a day in week one, and build toward mature production volume of roughly 25 to 40 emails per inbox per day by week four to six (Warmy.io, Leadhaste, Mailforge). Treat the specific day counts as directional. No two of these guides publish identical numbers, and none of them is a controlled study, but the shape of the curve, low and slow at the start, gradual and consistent increases, is consistent across all of them.
What matters more than any specific number is the shape of the curve itself. Sudden jumps in volume look like an attack pattern to automated filters even if every recipient on the list is legitimate. A domain that sends steadily and predictably earns trust faster than one that spikes and plateaus, even at a lower total volume.
What Google Postmaster Tools actually tells you
Google Postmaster Tools reports domain reputation in qualitative bands: High, Medium, Low, and Bad, not a numeric inbox placement percentage. The Bad band correlates with default spam routing. Any specific placement-percentage range you see mapped to these bands in vendor content ("High reputation equals X% inbox placement") is that vendor's own estimate, not something Google publishes, so treat those numbers skeptically wherever you encounter them.
What you can act on directly from Postmaster Tools: your authenticated traffic percentage (how much of your mail is passing SPF/DKIM/DMARC cleanly), your spam rate trend, and the qualitative reputation band itself. A domain sitting in Medium with a stable or improving trend is in reasonable shape. A domain that drops to Low or Bad needs an immediate pause on cold volume, not a content tweak.
Don't leave the domain parked, and don't just 301-redirect it either
Security filters and enterprise gateways increasingly check whether a sending domain has real web infrastructure behind it, not just DNS records. A domain that's parked with a registrar's default page or bare-bones forwarding reads as suspicious to both automated filters and to a prospect who types the domain into a browser out of curiosity. At minimum, that means a real landing page with a valid SSL certificate on the secondary domain, not a naked 301 redirect through shared registrar infrastructure.
Keeping cold volume separate from your primary domain
None of this changes the core architectural principle that applies across all deliverability work: cold outreach shouldn't run through the same domain that handles transactional mail, billing, or client communications. If a warming domain takes a reputation hit while it's finding its footing, that risk needs to be contained to the outreach infrastructure, not bleed into the systems your business actually depends on.
What "warmup gone wrong" tends to look like
The verified mechanics point to two recurring failure patterns worth watching for, independent of any specific case: sending cold volume before authentication and aging are complete, and ramping volume in spikes rather than a steady curve. Both trigger the same automated pattern-detection systems, and both are avoidable with a deliberate, patient rollout rather than an aggressive one aimed at hitting pipeline targets fast. If your reputation band or spam complaint rate moves the wrong direction mid-ramp, the right move is to pause cold sending immediately and let engagement-only traffic rebuild trust before resuming, rather than pushing through and hoping it self-corrects.
Warming a domain properly buys you the right to be judged on your actual message quality instead of getting filtered out on infrastructure signals alone. Once you're through that gate, running every draft through a quality check before it goes out is what keeps the reputation you just built intact.