Build an email warmup timeline for the domain you actually send from
Domain age, authentication, mailbox provider, and target volume all change how long warmup should take. Answer the questions below and get a week-by-week sending schedule, plus an A to F score of your live SPF, DKIM, and DMARC records. Not a generic "wait four weeks" rule.
Fill in the form and your personalized warm-up schedule will appear here, including any warnings specific to your setup.
Where these numbers actually come from
The base timelines are not arbitrary. They are built from three sources: Google and Microsoft's published bulk sender requirements, the sending caps that mailbox providers apply before flagging an account, and benchmarks used across the cold email industry for what a safe daily increase looks like.
- Domain age sets the base timeline. A domain under 30 days old starts with zero sending reputation, so it gets 8 weeks. A domain over a year old with prior sending history can be ready in 1 to 2 weeks.
- Missing SPF or DKIM each add a week. Without these, mailbox providers cannot verify the mail actually came from you, which is treated the same as an unauthenticated sender regardless of how slowly you ramp volume.
- DMARC set to none adds a week because you have no visibility into authentication failures during the exact period you most need it. A quarantine or reject policy already in place removes that penalty, including one inherited from your root domain.
- Sending from a root domain adds a week of caution, since any reputation dip during warm-up now touches every other email your business sends from that domain.
- Mailbox provider changes both the starting daily volume and the ceiling. Google Workspace tends to tolerate a higher starting volume and cap than a custom SMTP setup with no built-in sender reputation tools.
- High-risk verticals like finance, crypto, legal, and recruitment get an extra week and a lower daily cap, because spam filters apply more scrutiny to these categories regardless of sender history.
What this calculator checks instead of asking
Most of what a warmup schedule depends on is not a matter of opinion. It is published in your DNS, and it can be read. Anything below that a calculator asks you to type is an answer it is willing to guess with:
- When the domain was registered. Looked up over RDAP, the registry protocol that replaced WHOIS, rather than asked. Domain age is the single biggest input to the timeline, and "how old is your domain" is a question people answer from memory.
- Whether SPF actually works. Not whether a record exists. We walk the full include chain and count it against the 10 DNS-lookup limit in RFC 7208, because a record can read perfectly and still authenticate nothing. A record ending in
+allgets scored near zero for the same reason. - Whether your DKIM key is live or revoked. An empty
p=tag revokes a key. A checker that only asks whetherp=is present calls a revoked key healthy. - The DMARC policy that actually applies. Including one inherited from your root domain via
sp=, which is the normal setup for a sending subdomain and the case most checkers report as "no DMARC". - Whether you are on a subdomain at all. Derived from the domain you enter, not asked.
Everything it reads is still editable, because a lookup can be wrong or incomplete, and you know things about your setup that DNS does not record. DKIM is the clearest case: selectors cannot be enumerated, so a miss means "not found", never "not there".
The flip side of measuring rather than assuming is that the answer is sometimes "nothing to do here". If you check a domain that has been registered for years, authenticates correctly, and has mail exchangers, this tool says so and points you elsewhere, rather than inventing a six week ramp for a domain that has been sending mail since before the tool existed. We would rather be right than be used.
How the authentication score works
The A to F grade is not a vibe. It is scored directly against the specs that mailbox providers implement, weighted SPF 35, DKIM 30, DMARC 35, and rescaled to 100.
- SPF is walked all the way through its include chain. More than 10 DNS-lookup mechanisms, or more than 2 lookups that return nothing, is a permanent failure under RFC 7208 section 4.6.4 even when the record reads perfectly. A record ending in
+allscores near zero: it authorizes every server on the internet to send as you, which is worse than publishing nothing, because forgeries then pass authentication. - DKIM is checked for revocation, not just presence. An empty
p=tag explicitly revokes a key under RFC 6376 section 3.6.1, so a checker that only asks whetherp=exists will call a revoked key healthy. Key length and thet=ytest-mode flag are scored too. If no selector matches, DKIM is dropped from the score rather than counted as zero, and the result is marked as unverified. - DMARC follows the organizational domain fallback in RFC 7489 section 6.6.3. A subdomain with no record of its own inherits its parent's, where
sp=governs subdomains. We also readpct=, becausep=reject; pct=10only enforces on a tenth of failing mail and is much closer top=nonethan to reject.
We are collecting anonymous, aggregated outcome data from calculator use (inputs and computed plan only, never domain names or personal information) to refine these numbers over time. That data is self-selected, being people who chose to run a warm-up calculator rather than a random sample of senders, and we will say so plainly whenever we publish from it.
Three things to fix before any warm-up plan works
Authentication first
SPF, DKIM, and at least a DMARC record set to none are not optional extras. Warming up an unauthenticated domain builds reputation for a sender mailbox providers cannot verify, and that reputation does not transfer once you fix authentication later.
Use a subdomain
A dedicated sending subdomain isolates cold outreach from the email your company depends on for support, billing, and internal communication. It still inherits some trust from your root domain without putting it at risk, and it inherits your DMARC policy too.
Track replies, not just opens
Open rates are increasingly unreliable due to image blocking and privacy features in mail clients. Replies and manual moves out of spam are what actually build sender reputation during warm-up, which is the specific gap automated warm-up tools are built to fill.
Manual warm-up works. It also does not scale past one mailbox for very long.
Tracking a ramp schedule across multiple mailboxes, catching messages that land in spam, and getting real replies to build engagement signals is manageable in a spreadsheet for a week or two. Past that, it is the exact set of tasks lemwarm automates inside the same account you already use to send sequences.
Start your 14 day free trialBefore you follow the plan
How long should I actually warm up a new domain?
It depends on domain age and authentication, not a flat rule. A brand new domain with no SPF, DKIM, or DMARC needs 8 to 10 weeks. A domain that is a year old with full authentication and some sending history can be ready in 1 to 2 weeks. Use the calculator above for a number based on your specific setup.
What makes the best domain warmup calculator?
Judge one on how much it asks you versus how much it checks. A warmup schedule is only as good as its inputs, and most of those inputs are facts about your domain that are published in DNS: whether SPF, DKIM, and DMARC exist, whether they are valid, and when the domain was registered. A calculator that asks you to self-report those is really a formula with a form in front of it, and it will happily produce a confident schedule from answers you guessed. This one looks them up: it reads your live SPF, DKIM, and DMARC records, walks the full SPF include chain to check it against the 10-lookup limit that silently breaks records, reads DMARC inherited from your root domain, and finds your registration date. The other mark of a good one is that it will tell you when the answer is "you do not need this". Ours says so when a domain already has years of history and working authentication, because a tool that only ever recommends warming up is not measuring anything.
Can I warm up on my main business domain?
You can, but it is not the safer choice. Cold outreach volume behaves differently from transactional or marketing email, and a reputation dip during warm up can affect every other email your company sends. A dedicated subdomain (like send.yourcompany.com) isolates that risk while still inheriting some trust from the root domain.
Does my sending subdomain need its own DMARC record?
Usually not. If send.yourcompany.com has no DMARC record of its own, receivers fall back to the policy published at yourcompany.com, and the sp= tag on that record is what governs subdomains (falling back to p= when sp= is absent). This is defined in RFC 7489 section 6.6.3. Many DNS checkers skip that fallback and report "no DMARC" for a subdomain that is in fact fully covered, so a missing record on the subdomain alone is not evidence of a problem. Our checker reports the inherited policy and tells you where it came from.
The checker says DKIM is not detected. Is my DKIM broken?
Almost certainly not. DKIM has no fixed lookup location: the selector is chosen by whoever configured sending, so any checker can only try a list of common ones. Google Workspace is the clearest example, since its default selector is a rotating date string that cannot be guessed, which means google.com itself returns nothing for every common selector. A miss means we could not confirm DKIM, not that it is missing, and we leave it out of the score rather than grading you down for it.
What actually happens if I skip warm-up and just start sending?
Gmail and Outlook have no history to judge your domain by, so they lean on caution. That usually shows up as low inbox placement, mail routed straight to spam or promotions, and in worse cases a blocked or rate-limited sending domain that takes weeks to recover from, longer than warming up properly would have taken.
Does an automated tool like lemwarm replace what this calculator does?
No, they solve different problems. This calculator tells you how long your warm-up should take and what daily volume to send at each stage. lemwarm is what actually executes that ramp: it sends and receives mail inside a real network of inboxes, marks messages as not spam, and moves replies out of promotions automatically, things that are hard to do manually at any real scale.
Where do the numbers in this calculator come from?
The base timelines follow published Google and Microsoft bulk sender guidance and widely used cold email industry benchmarks for sending caps by mailbox provider. The authentication score follows the relevant specs directly: RFC 7208 for SPF lookup limits, RFC 6376 for DKIM key state, and RFC 7489 for DMARC policy and inheritance. We explain the exact modifiers in the methodology section below the calculator.