How to Warm up an Email Inbox Manually, Without a Tool

Warmup is one of the few things in the outbound stack you can do properly for free. The tools automate labour, not capability, and at one or two mailboxes the manual version produces better signals, because the engagement is genuine rather than pooled. (Why that distinction matters, and what reputation is actually made of.)

This is a 30-day plan with the DNS records written out. It assumes a separate sending domain (never your main company domain) and one mailbox on it.

Part 1: The setup warmup cannot substitute for

None of the ramp helps if these are wrong. Do all of it before day one.

Buy the right domain

A separate root domain, not a subdomain. The usual reason given is "protect your main domain's reputation," which is true. The mechanical reason is better: Google calculates the 5,000/day bulk-sender threshold across "all messages sent from the same primary domain", and subdomains roll up to the primary domain (sender guidelines FAQ). send.yourcompany.com is not separation. A different registered domain is.

Pick something a human would believe: getyourcompany.com, yourcompany.io, try-yourcompany.com. Avoid hyphens-and-numbers salad. Expect $10–15/year at a mainstream registrar.

Cost of the mailbox

Workspace pricing is geo-localised: the Starter tier read at ₹270/user/month on workspace.google.com/pricing on 29 Sep 2026, so check your own region's published figure rather than trusting a US number quoted in a blog. Reseller ranges are reported by infrastructure vendors and affiliates; treat as directional [unverified].

For one mailbox, go direct. Resellers are a scale decision.

The three DNS records, written out

Publish these at your DNS host for the sending domain. Values below assume Google Workspace; adapt the SPF include and DKIM selector for your provider.

SPF: one TXT record at the root (@). Authorises which hosts may send as your domain.

Three things that break SPF and are worth knowing before they break it:

• One SPF record per domain. Exactly one. Two TXT records both starting v=spf1 is a permerror, and a permerror is an authentication failure, not a warning. If you already have an SPF record, merge the includes into it: do not add a second.
• Ten DNS lookups, maximum. Each include:, a, mx, redirect costs a lookup, and each nested include costs more. Exceed ten and you get permerror again. Two or three includes is fine; the stack that dies here is the one where marketing, CRM, invoicing and outbound all added an include over two years.
• ~all (softfail) vs -all (hardfail). Start with ~all. Move to -all once you're certain every legitimate sender is listed, with -all and a missing include, that sender's mail is gone, not junked.

DKIM: generate in the provider's admin console, which gives you a selector and a public key. Publish it, then switch signing on in the console. Order matters: signing with an unpublished key fails every message.

Choose 2048-bit if the console offers a choice. The key is long enough that some DNS hosts require splitting it across strings: the console will tell you.

DMARC: tells receivers what to do when SPF and DKIM disagree with the From: header, and where to send reports.

• p=none: monitor only. This satisfies both Google's and Microsoft's requirements. You do not need quarantine or reject to be compliant, and starting at reject on a domain you haven't observed yet is how people black-hole their own mail.
• rua=: aggregate reports land here daily. Actually read the first week's.
• adkim=r / aspf=r: relaxed alignment: the organizational domain must match, so mail.yourdomain.com aligns with yourdomain.com. Strict (s) requires an exact match. Relaxed is the right default.
• Alignment is the part people miss. Passing SPF is not enough; the domain that passed must align with the domain in the From: header. Google requires alignment with "either the SPF organizational domain or the DKIM organizational domain": one is enough today. Google also says outright that it "recommends all senders fully align DMARC to both" and that both "will eventually be a sender requirement." Align both now.

One-click unsubscribe (RFC 8058): required for marketing and subscribed mail above the bulk threshold, and good practice below it. Two headers, both needed:

The URL must accept an HTTPS POST and unsubscribe without a confirmation page. Google's stated expectation is that you "fulfill unsubscribe requests within 48 hours." Most sequencers do this natively; check yours rather than assume it.

Verify it: read the header, not a dashboard

Send one message to a mailbox you control on a different provider. Open the original/raw source and find Authentication-Results. You want:

Three passes and header.from matching your domain. A checker tool's green tick is a claim; this header is evidence. If dmarc=fail while SPF and DKIM both pass, you have an alignment problem, not an authentication problem: check that the From: domain matches the domain that passed.

Set up Postmaster Tools

Add and verify the sending domain at Google Postmaster Tools. Free, and without it you cannot see your own spam rate.

One caveat to internalise now: Google states the spam rate covers "only DKIM-authenticated messages to personal Gmail accounts." If you're emailing @company.com addresses, much of your volume goes to Workspace mailboxes and those complaints don't appear. A 0.00% spam rate is not proof of anything in B2B. Watch domain reputation (Bad / Low / Medium / High) and delivery errors alongside it.

Part 2: The 30-day ramp

The principle: every send in the first month should have a plausible reason for a human to reply. You are not simulating engagement, you are collecting it.

Days 1–3 · 2–5 sends/day

Who: your own addresses on other providers, colleagues, friends, your accountant, your co-founder.

What: real subject lines, three to five sentences, ending in a question so a reply is natural. Then reply to their replies: a four-message thread is worth far more than four one-off sends.

Also: make the mailbox look used. Signature with a real name and role, profile photo, correct timezone. Send from the web client, not an API. Read and archive mail in it.

Days 4–10 · 5–15 sends/day

Widen the circle beyond people who owe you a favour: newsletters you'll actually read, SaaS trial confirmations, vendor support threads, LinkedIn contacts you genuinely know.

Start including Microsoft/Outlook recipients here. Google and Microsoft judge you independently and enforce differently: a domain in good standing with Gmail can be getting 550 5.7.515 from Outlook for an alignment problem. You want both surfaces exercised while the stakes are two-figure.

Anything of yours that lands in spam: from the recipient account you control, mark Not Spam and move it to the inbox.

Days 11–20 · 15–30 sends/day

Introduce real outbound: to your best-fit segment, not the bottom of the list. Ten individually-written emails a day to your ten most plausible prospects does two jobs at once: builds reputation, and tells you whether the message works before you spend the domain finding out at scale.

Track replies from here, and hold this benchmark in mind: Belkins' 2026 study of 7,530,489 emails reports a 0.45% average reply rate measured against total sends, excluding auto-replies and out-of-office. Against that, 2 replies from 200 well-targeted manual sends is roughly category-average. Zero from 100 means the message or the list is wrong, and scaling will convert a message problem into a domain problem.

Days 21–30 · 30–50 sends/day

Keep ramping. Check Postmaster every few days now: spam rate, domain reputation, authentication pass rate, delivery errors.

Day 30 onward · steady state

Most practitioners settle at 30–50 cold sends per inbox per day and scale by adding inboxes rather than raising per-inbox volume. Higher numbers circulate in vendor content; no provider documents a per-inbox limit [unverified: vendor convention, not published policy], and it is the first thing to cut when placement drops.

Do keep each root domain under 5,000 sends/day on purpose. Crossing it once assigns permanent bulk-sender status: Google states "bulk sender status doesn't have an expiration date" and that later changes in practice "will not affect permanent bulk sender status once it's assigned." There's nothing catastrophic about the bulk requirements (you should meet them anyway) but crossing that line accidentally, forever, on a domain you were casual about, is avoidable.

Part 3: The checks you can run by hand

Setup is verified once. Everything below is ongoing, costs nothing, and needs no vendor. Warmup tools show you a dashboard about their own pool; these checks are about your actual mail.

Check 1 · Do the records resolve? (dig, before every launch)

Your registrar's UI tells you what it saved. dig tells you what the world sees. They disagree more often than you'd think: propagation, a trailing dot, a provider that silently splits a long TXT value.

What you're looking for:

• Two lines starting v=spf1: a permerror, and an authentication failure, not a warning. The single most common self-inflicted deliverability bug.
• Empty DKIM output: you published the record but haven't enabled signing, or you're querying the wrong selector.
• No _dmarc record: you're non-compliant above 5,000/day and losing DMARC reports you can't get retroactively.
• SPF lookup count. The 10-lookup ceiling includes every nested include:. You can count it by hand by dig-ing each include in turn; it's tedious, and it's the check nobody runs until mail starts failing.

Check 2 · Where does it actually land? (a seed list, built by hand)

This is what "placement testing" products sell. The manual version:

• Create accounts across the providers your list actually uses: a personal Gmail, a Google Workspace mailbox on a test domain, an Outlook.com address, a Microsoft 365 mailbox, a Yahoo address, plus a regional provider if your ICP has one.
• Add them to the real sequence as real contacts. Not a separate one-off blast: a blast doesn't travel the same path as a sequenced send, so it doesn't test the same thing.
• Record, per provider: inbox / promotions / junk / not delivered.
• Repeat on the same weekday and time, with the same template family, so the readings are comparable.

The honest limit, which the paid products don't foreground: a seed list tells you where seed mail landed. Placement is decided per recipient domain and per sender reputation, so your seeds are a smoke alarm, not a measurement. A clean seed result with a rising complaint rate is still a problem. Treat a change in seed placement as the signal, never the absolute number.

Check 3 · Blacklists, and the trap that makes this check lie to you

Worth knowing before you run it, because the failure mode is a false all-clear.

Querying Spamhaus's public DNSBL mirrors through a public DNS resolver (Google's 8.8.8.8, Cloudflare's 1.1.1.1) does not work. Spamhaus blocks it: queries via open resolvers return either NXDOMAIN or the error code 127.255.255.254. NXDOMAIN is exactly what "not listed" looks like. So this command:

returns a clean-looking answer whether you are listed or not. People run it, see nothing, and conclude they're fine.

Do this instead:

• Use Spamhaus's own web checker at check.spamhaus.org, which isn't subject to the resolver restriction; or
• Query from a resolver running on your own network rather than a public one.

Two more things about blacklists specifically:

• On Workspace or Microsoft 365 you do not own the sending IP. IP-level listings are your host's problem and largely out of your hands. Domain-level listings are yours, and are the ones to watch.
• A listing is a symptom. Delisting a domain without fixing the targeting that got it listed buys you a few weeks.

Check 4 · Read Postmaster properly (weekly, ~5 minutes)

Not "glance at the spam rate." Read them in this order, because each one changes how you read the next:

• Authentication: should be flat at 100%. Anything else is a DNS problem masquerading as a reputation problem. Fix before reading further.
• Delivery errors: rejections and temporary failures. A step change here usually means list quality or a 550 5.7.515 authentication rejection.
• Spam rate: daily, not averaged. Under 0.10%. But see the caveat below.
• Domain reputation: Bad / Low / Medium / High. Laggy by days, and the provider's actual verdict on you.
• Compliance status: Compliant / Needs work / No data found per requirement.

The caveat that makes step 3 partly useless for B2B: Google states the spam rate covers "only DKIM-authenticated messages to personal Gmail accounts." If you email @company.com addresses, most of your Google volume lands in Workspace mailboxes and those complaints never show here. A 0.00% spam rate is not evidence. Weight domain reputation and delivery errors above spam rate when your list is B2B.

Check 5 · Open a DMARC report (monthly)

The rua= address in your DMARC record receives aggregate XML daily, from every provider that received mail claiming to be your domain. Almost nobody opens them.

Two things to look for:

• Per-source SPF and DKIM pass counts. A source failing one of the two is a misconfiguration you can't see any other way, often a legitimate system (invoicing, CRM, a support desk) you forgot was sending as you.
• Sources you don't recognise. Someone else sending as your domain. This is the only place you find that out.

The raw XML is readable but unpleasant. Any free DMARC report parser will render it; the point is to open one at all, not which viewer you use.

Check 6 · Is the warmup actually working?

The question everyone asks and no tool answers honestly. You cannot measure warmup directly: nobody outside the mailbox providers can. What you can watch, in descending order of reliability:

That last row is the one to internalise. A warmup dashboard reporting excellent placement is reporting on mail sent to mailboxes that were paid to receive it.

Check 7 · Before you buy the domain

Cheap, thirty seconds, and it saves a month: a previously-registered domain can arrive carrying someone else's history.

• Check whether it was registered and used before: a look at the Internet Archive tells you whether a site once lived there, and what kind.
• Check the domain against a blacklist lookup before purchase, not after.
• Be suspicious of a short, clean, brandable domain available at standard price. There is usually a reason.

The routine, condensed

Part 4: Abort criteria

Write these down before day one, because in week three you will want to negotiate with them.

At 0.10% you are allowed roughly one spam complaint per 1,000 sends. That is the actual budget you're managing.

What manual warmup does better than a tool

• The engagement is genuine, so the pool-detection question never arises. (It's an open question, and the only people answering it sell warmup.)
• You learn your reply rate while the stakes are two-figure.
• It costs a domain and a mailbox: roughly $7–8 in month one.
• You finish the month able to read Postmaster Tools and an Authentication-Results header, which most people running warmup tools never learn.

What it does worse

• It's real work: ~20–30 minutes a day for a month.
• It doesn't scale. At ten mailboxes the labour dominates, and that's exactly where a tool earns its price. Though the honest comparison is usually "warmup bundled free with the sender I was buying anyway" rather than "warmup as a separate purchase." The ten-vendor price comparison is here, and the gap is larger than most people expect.

What this page does not know