Cold email deliverability: the complete guide for 2026

Cold email deliverability is decided by the same systems that judge every other message — authentication, sender reputation, volume behaviour, and content — but cold senders operate with the thinnest margins, because they mail people who never asked to hear from them. The senders who stay out of the spam folder do four things consistently: they run outreach on a separate domain so a bad campaign cannot burn their brand, they authenticate completely (including reverse DNS), they keep complaints far below Gmail's 0.3% spam-rate ceiling, and they ramp volume gradually instead of blasting. This guide covers each of those, the SMTP error codes that tell you something broke, and what to do when a domain is past saving.

Put cold outreach on its own domain

Cold email generates spam complaints by construction. If that traffic runs on your primary domain, a single bad campaign takes password resets, invoices, and your sales team's replies down with it. The architecture question comes first, and there are only three options:

Option	Example	Risk isolation	Verdict for cold email
Primary (apex) domain	acme.com	None — one complaint spike hits everything	Never
Subdomain	mail.acme.com	Partial — a compartment, not a firewall	Not enough
Separate registered domain	getacme.com	Real — an org-level blocklisting doesn't touch acme.com	The standard

The subdomain option deserves the extra sentence, because it is the most misunderstood. A subdomain inherits some of the parent's standing on the way down, but damage flows back up too: several blocklists list at the organizational-domain level, and poor sending from a subdomain can drag the root's compliance standing with it. A subdomain is fine for separating a newsletter from transactional mail. It is not sufficient protection for traffic designed to generate complaints.

A separate domain is not itself a red flag — no mailbox provider publishes a rule against it. What gets penalised is the correlated bundle that usually comes with a cheap one: registered days ago, no website, no MX record, a bargain-bin TLD, sending to strangers from day one. Any one of those is survivable; the stack of them is the signal. So do the opposite: buy a .com, put up a real one-page site that links to your primary brand, publish an MX so bounces and replies have somewhere to land, and let it age before sending.

One honest caution on the "buy 20 domains and rotate" pattern: spreading a 0.5% complaint rate across 30 domains produces 30 domains with a 0.5% complaint rate, not a clean one. Domain farms buy time, not permission, and the cluster pattern — same registrar, same day, same DNS template, shared tracking domain — is machine-visible. One to three well-configured domains with real websites is the defensible version.

Tracking-domain hygiene

When click tracking is on, your ESP rewrites every link through its shared domain — and corporate security gateways block generic ESP tracking domains wholesale, because phishers launder URLs through exactly those hostnames. Mail from your domain whose every link points at someone else's is also a phishing-shaped mismatch. If you track clicks at all, delegate a CNAME like link.yourdomain.com to the ESP and verify it serves valid HTTPS. Better still for cold email: fewer links, written out in plain text, pointing only at your own domain.

Authenticate everything — including the PTR record

SPF, DKIM, and DMARC are table stakes: publish SPF for the envelope domain, sign with DKIM whose d= aligns with your From domain, and publish a DMARC record. Since 5 May 2025, Microsoft requires SPF, DKIM, and DMARC together from anyone sending 5,000+ messages a day to its consumer domains.

But the biggest authentication failure of 2025–26 was none of those. Google began surfacing SMTP rejection data inside DMARC aggregate reports around July–August 2025, and when Al Iverson and Scott Ziegler analysed that data, the largest single driver of rejections turned out to be infrastructure — sending IPs with broken or missing PTR records. By their account, Gmail rejected tens of millions of messages for this reason within weeks, once enforcement of the 550 5.7.25 rejection tightened in December 2025.

The requirement itself is old — Gmail's sender guidelines have long demanded "valid forward and reverse DNS records" — but nothing in your SPF/DKIM/DMARC setup surfaces a broken PTR, so a domain can pass every checklist and still be hard-rejected. Three things must agree: the sending IP's PTR resolves to a hostname, that hostname's A record resolves back to the same IP, and the server's HELO banner matches. If you send through a reputable ESP's shared pool, this is handled — verify once and move on. If you run a dedicated IP or your own server, it is the first thing to check and the most likely thing to be silently broken. Our PTR record guide walks through the checks.

The 0.3% spam-rate math at cold volumes

Gmail's published limit is a spam rate below 0.3%, with the explicit advice to stay under 0.1% (sender guidelines). Run that arithmetic at cold volumes and the margin becomes vivid: 0.3% is three complaints per 1,000 delivered messages. A sender delivering 1,000 cold emails a day to Gmail-hosted inboxes is four "report spam" clicks away from the hard ceiling on any given day — and the recipients most likely to click are exactly the ones cold lists select for: strangers with no relationship to you.

Two practical consequences. First, list quality is a deliverability control, not a sales metric — every stale or scraped address raises the complaint and bounce denominator working against you. Second, complaints cluster: recovery playbooks consistently find that when one segment complains heavily, the rest of that segment will too, so suppress segments, not individual complainers. And once you exceed 5,000 messages a day to Gmail, you formally become a bulk sender, with one-click unsubscribe and the full requirements set attached.

Content: why identical sends trip filters

Spam filtering has three documented layers of duplicate detection, and cold campaigns walk into all of them. Exact-duplicate hashing catches byte-identical sends. Fuzzy hashes defeat naive mail-merge: Nilsimsa, proposed in 2001, digests the distribution of three-character sequences in a message, and TLSH, its modern successor, is documented explicitly for spam clustering — swapping a first name, company, and date barely moves a trigram distribution, so merge-field "personalization" is not variation. The third layer counts recipients: DCC reports back how many mailboxes have received mail with the same checksum, while Razor and Pyzor cross-reference reported-spam signatures.

The arithmetic makes the point concrete. In SpamAssassin's published scores, DCC_CHECK adds 1.1 points, the Razor rules up to roughly 2.4, and PYZOR_CHECK roughly 2.0 — a message flagged by all three collects about five points against a default spam threshold of 5.0. Bulk detection alone can cross the line before a single word of your copy is evaluated. The honest caveat: Gmail and Microsoft run their own undocumented clustering, not SpamAssassin — but these open-source systems are the documented analogues, and the mechanism is the same.

The defence is genuine variation: message variants that differ in sentence structure, vocabulary, length, and subject grammar — not one skeleton with rotating tokens. That is expensive to do well, which is precisely why filters find the shortcut versions so easy to cluster.

Volume discipline: age, warm up, then ramp

The timeline most cold senders skip is the one that matters most. Spamhaus's Zero Reputation Domain list automatically lists every newly registered domain for its first 24 hours, with no manual delisting — mail from a day-old domain is rejected outright by anyone using the feed. Beyond that hard floor, Al Iverson recommends ageing a new domain at least 30 days before warming it for commercial traffic, because Gmail and Yahoo treat brand-new domains with wait-and-see suspicion. Age first, then warm the domain up over a period of weeks, then campaign — the whole runway is measured in months, not days.

Once warm, the rate is the asset. Google asks senders to "send email at a consistent rate" and avoid bursts, and its own operational guidance is one message per second steadily rather than sixty at once. The only growth figure any provider publishes is Google's 25–100% per day ramp from the same document. The most common self-inflicted failure is the warmup cliff: a domain warmed to 50 messages a day that suddenly sends 5,000 has jumped 100× in one step, every provider's volume-anomaly detection fires at once, and the burst becomes the most recent — and most heavily weighted — entry in the domain's history. Warmup establishes a rate; it is not a permission slip for any volume.

For steady state, the practitioner convention is 2–3 mailboxes per domain and 30–50 cold emails per mailbox per day. Treat that as a convention, not a rule — no mailbox provider publishes safe numbers — and jitter your send times rather than firing everything at 9:00 sharp.

Monitoring, and the SMTP codes that matter

Your ESP's dashboard buckets bounces into labels like "Blocked" that destroy the diagnostic detail. Get the raw SMTP string — in Resend, SendGrid, Mailgun, and Postmark it lives on the bounce webhook payload or event detail. As of August 2026 your DMARC aggregate reports also carry Gmail's SMTP rejection data (added mid-2025), which makes them a first-class diagnostic rather than an authentication audit. Beyond that: watch your spam rate in Google Postmaster Tools, enrol in Microsoft SNDS/JMRP if you control your IP, join Yahoo's feedback loop, and keep seed accounts at each major provider — "delivered" only means the receiving server said 250, and seed tests are the only way to see mail that was accepted and then junked or silently dropped.

These are the codes cold senders actually hit, from the Google, Microsoft, and Yahoo references:

Code	Provider	What it means	What to do
550 5.7.25	Gmail	Missing or mismatched PTR record	Fix reverse DNS / FCrDNS, including IPv6
550 5.7.26	Gmail	Fails SPF and DKIM authentication	Fix authentication and alignment
421 4.7.28	Gmail	Unusual rate of email detected	Pause 15 min, hold below trigger volume 24h, ramp 25–100%/day
550 5.1.1	Gmail / Microsoft	Recipient doesn't exist	A list problem — verify before sending
451 4.7.650	Microsoft	IP-reputation rate limit	Slow down and register for SNDS/JMRP; retrying harder deepens it
550 5.7.515	Microsoft	Fails the 5,000/day authentication bar	Publish and align SPF + DKIM + DMARC
550 5.7.511	Microsoft	Sending IP banned	Delist via Microsoft's portal
421 4.7.0 [TSS04]	Yahoo	Volume or complaint deferral	Reduce volume, cut unengaged segments
554 delivery error: dd	Yahoo	Account doesn't exist	List problem, not reputation
550 5.7.1	Various	Policy/reputation catch-all	Read the full string; diagnose IP vs domain

Two rules of thumb. A 4xx code means "not now" — your ESP retries for 24–72 hours, and sustained deferrals are worse than they look because the queue silently fills; a 5xx means "never," and retrying it is itself a spam signal. And the same Yahoo campaign producing mostly dd errors has a list problem, while one producing mostly [TSS04] has a reputation problem — same campaign, opposite remediations.

When a domain burns: recovery or replacement

"Burned" is practitioner vocabulary, not a technical state any provider defines: mail from the domain is filtered or rejected regardless of content, and normal sending no longer repairs it. Nothing supports the idea of a permanent ban — reputation is computed over a rolling window, so bad history decays rather than clears — but rehabilitation can be uneconomic.

First, confirm the problem is actually domain-level: send the same mail from a clean IP or a different ESP. If the failures follow the domain, check the Spamhaus domain blocklist — and if listed, fix the cause before requesting removal, which is always free ("there is never any charge or fee"; anyone charging for Spamhaus delisting is a scam). If the failures stop on a new IP, the domain is fine and you have an IP or ESP problem instead.

Recovery, condensed from Google's own deferral protocol and practitioner playbooks: stop the campaign entirely, audit authentication, PTR, list source, and link domains, then resume at a fraction of prior volume to your most-engaged recipients only, growing 25–100% per day while complaints stay low. Practitioner-reported timelines run from about two weeks for a quickly-caught spike to two or three months for combined complaint-and-bounce damage — no provider publishes recovery curves, so treat every such figure as reported experience, not fact. Sending nothing at all does not heal a domain; small volumes of well-received mail do.

Abandon the domain when the damage is proven domain-level, it sits on a domain blocklist, rejections persist despite corrected sending, and — critically — the domain has no brand value. For a disposable outreach domain, a fresh .com plus 30 days of ageing and a few weeks of warmup usually beats months of suppressed volume with an uncertain outcome. Two traps on the way out: a subdomain of the damaged domain is a poor escape hatch, because it inherits the parent's history and the penalty of being an unknown sender; and the replacement domain starts under the new-domain scrutiny described above, so the runway clock restarts in full.

The ESP terms-of-service problem

Here is the part most cold-email guides omit: many ESPs — particularly transactional and API-first providers — prohibit cold outreach in their acceptable-use policies outright. Resend explicitly does, and enforcement at transactional-focused providers is fast and aggressive. If your account is suspended for cold outreach, appeal is usually futile, because the use case itself, not the individual incident, is the violation. Cold email can be perfectly lawful and still breach your ESP's contract — legality and terms of service are separate questions, and the AUP is the stricter test.

The practical rule: before any of the deliverability work above, pick sending infrastructure whose terms actually permit cold outreach, and read the AUP rather than assuming. That applies to tooling too — WarmEnvelopes warms domains by building real, logged sending history, but warming a domain does not and cannot make a cold campaign compliant with an ESP's acceptable-use policy. That is a contract question, and it needs settling before the first send, not after the suspension email.