Authentication is the entry ticket, not the whole game
Before a receiver evaluates reputation, it checks identity. SPF authorizes which IP addresses may send for your domain, DKIM cryptographically signs the message so tampering is detectable, and DMARC tests whether the domain that passed SPF or DKIM aligns with the visible From address. A message can get an "SPF pass" and still fail DMARC because the passing domain was the bounce Return-Path, not the From.
For cold email the practical requirement is simple: publish one valid SPF record, sign with DKIM using a 2048-bit key, and publish a DMARC record — starting at p=none while you read reports. The 2026 DMARC specification (RFC 9989) removed the pct tag, replaced the public-suffix lookup with a DNS tree walk, and changed how staged rollouts work, so guidance written before 2026 is now partly wrong.
Warmup builds a recent sending pattern, it does not buy trust
A new domain and a new mailbox have no sending history. Warmup is a controlled way to establish a recent, gradual pattern so that receivers are not asked to absorb a sudden behavioral jump. It does not make a domain "trusted" after a fixed number of days, and a warmed mailbox will still land in spam if authentication breaks, the list is stale, or volume changes abruptly.
The useful mental model is observability. A five-message batch that exposes a broken DKIM selector is more valuable than a fifty-message batch that hides the same defect inside a campaign. Warm the domain and each mailbox as separate things, count both against a domain-level total, and gate every increase on evidence from the previous batch rather than on a calendar.
Volume is a rate of change, not a magic daily number
Receivers do not publish a universal safe cold-email ceiling, so any statement like "40 per day is safe" is false precision. What a sender controls is the size of each change. Moving from 12 to 18 sends preserves a very different pattern from moving from 12 to 120, and the same caution applies after weekends, outages, or quiet periods.
Track planned sends and actual sends per mailbox and per domain in one row per day, next to hard bounces, deferrals, complaints and real replies. When the queue sends materially more than planned, fix the scheduler before drawing any conclusion about reputation. Increase only when the previous step produced normal authentication, low hard-bounce pressure, no complaint signal and plausible human replies.
List hygiene decides how many of your sends are wasted
Verification is several different checks — syntax, domain, MX, mailbox probe and suppression history — and they can legitimately disagree. A catch-all domain accepts everything at the SMTP layer, so "valid" there means "not proven invalid," not "deliverable." A 4xx result during verification should keep the address unknown, not invent a hard bounce, and DNS edge cases such as Null MX, NXDOMAIN and SERVFAIL are three different answers a verifier should never collapse into one.
Operationally, the rules that matter most are: suppress a hard bounce across every mailbox immediately, deduplicate leads before they are split across sending accounts, and give role addresses and distribution lists their own outbound rule. Re-verify an old list before reusing it, because deliverability of a two-year-old list is unrelated to its state when it was collected.
Reply and unsubscribe handling is a reputation system, not a nicety
The fastest way to generate complaints is to keep following up with someone who already replied, or who asked to stop. Reply detection has to run before the next queue cycle, has to survive a prospect replying from a different alias, and has to be idempotent so a retried job does not cancel the wrong sequence or fire a duplicate. One-click unsubscribe headers must be covered by the DKIM signature (RFC 8058), and the endpoint behind them must be idempotent so duplicate POSTs do not error or resurrect an opt-out.
This is also where IMAP correctness matters. Reply detectors read mailboxes over IMAP, and IMAP has sharp edges — UID versus sequence number, UIDVALIDITY resets, folder-name differences across providers — that turn a small bug into missed replies and continued follow-ups.
Recovery is early detection plus changing one variable at a time
Reputation damage rarely announces itself. The early signals are a rising share of messages in spam, a small but persistent increase in deferrals from one receiver, or an authentication result that quietly changed after a DNS edit. Google Postmaster Tools often shows no data for a low-volume sender, so you have to measure from bounce classes, reply rates and provider diagnostic codes instead.
When something breaks, the recovery discipline is to isolate one cause — recipient data, DNS, provider policy, or the queue — and change only that. Decide in advance whether a given signal means pause entirely or just reduce volume, and resume from the last level that behaved normally rather than the highest planned step.
Common questions
What is the single biggest cause of cold email going to spam?
There is no single cause, but the most common one for small senders is an abrupt change the receiver did not expect: a volume jump, a new authentication failure after a DNS edit, or a stale list producing a burst of hard bounces. Deliverability is a rate-of-change problem more than a threshold problem.
Do I need SPF, DKIM and DMARC for cold email, or is one enough?
You need all three. SPF and DKIM establish identity in different ways, and DMARC tests whether the domain that passed one of them aligns with the visible From address. Gmail and Yahoo bulk-sender requirements expect DMARC to be present, and a missing or misaligned record is a common reason mail is filtered even when SPF shows a pass.
How long does it take to warm up a new sending domain?
There is no fixed number of days that makes a domain ready. Warmup is finished when the mailbox and domain have a recent, gradual sending pattern and each increase has been gated on normal authentication, low bounces and real replies. Treating a calendar date as the finish line is how senders rationalize bad signals.
How many cold emails can I safely send per day from one mailbox?
Receivers do not publish a universal safe number, so any specific figure is an example, not a guarantee. The controllable variable is the size of each increase and the total volume across all mailboxes on the domain. Track planned versus actual sends and increase only after a clean previous batch.
Should a hard bounce suppress the address everywhere or just in one campaign?
Everywhere. A permanent failure is a property of the address, not of the campaign that discovered it. Suppress it globally across every sending mailbox immediately, because continuing to send to a known-bad address from another mailbox spreads the reputation cost.
Why do my follow-ups keep sending after someone replies?
Usually because reply detection runs on a schedule that lags the send queue, or because it only matches the exact From address and misses replies from an alias or a forwarded thread. Reply detection should cancel pending follow-ups before the next queue cycle and match on thread evidence, not address equality alone.
Google Postmaster Tools shows no data for my domain. Is something wrong?
Not necessarily. Postmaster Tools needs a sustained daily volume before it displays reputation and spam-rate data, and most small cold-email senders never reach that threshold. You can still measure deliverability from bounce classes, deferral codes, reply rates and seed-inbox checks.