Cold Email Deliverability in 2026. The Rules Changed.

Why Deliverability Fails

When deliverability breaks it usually fails for one of a small number of concrete reasons. The vague advice about warming up your domain or cleaning your list is not wrong, but it does not tell you what the filter is actually reacting to.

Authentication is missing or misconfigured. Gmail and Outlook now reject or route to spam any email that does not pass at minimum one of SPF or DKIM, with DMARC alignment. A domain with no DMARC record is not protected. An SPF record that resolves to more than 10 DNS lookups (the RFC 7208 hard limit) returns a PermerError, which most providers treat identically to a fail. DKIM keys using 1024-bit RSA are considered weak and scored lower than 2048-bit.

Sender reputation is damaged. Reputation is tracked at the domain level and the IP level separately. A bounce rate above 2 percent signals that the sender is using invalid data. A complaint rate above 0.1 percent signals that recipients are actively marking mail as unwanted. Both degrade placement on a rolling basis, meaning a campaign sent last week affects the score applied to your campaign today.

Shared infrastructure carries neighbor risk. When you send through a managed platform's shared pool, the IPs you use are also used by every other sender on that platform. A neighbor who sends to a scraped list overnight raises the complaint rate for the entire IP block. You absorb that degradation even if your own list and content are clean, and you have no way to audit or fix it.

Warmup was skipped or done wrong. A domain that jumps from zero to 5,000 sends per day looks like a compromised account to pattern-matching filters. Providers weight recent sending history heavily, and domains with no established pattern get flagged on volume alone before a single content signal is evaluated.

Content triggers filters. Subject lines with urgency phrases, bodies that use excessive punctuation or all-caps, poor text-to-HTML ratio, and missing unsubscribe mechanisms all lower content scores. Enterprise spam filters running on Microsoft 365 use heuristics that are more aggressive than consumer Gmail filters and will catch patterns that pass a basic spam checker.

Authentication Setup: SPF, DKIM, DMARC

Authentication is the baseline. Everything else builds on it.

SPF is a TXT record at the apex of your sending domain listing services authorized to send on your behalf. The record has a hard limit of 10 DNS lookups. Include statements each count as one lookup, and some resolve to further includes that add additional lookups. If your record resolves to more than 10, the SPF check returns PermerError and most providers treat it as a fail. For a domain sending only through AWS SES: v=spf1 include:amazonses.com ~all. If you also send through Google Workspace, add include:_spf.google.com in the same record. Two separate SPF TXT records on the same domain will cause both to fail.

DKIM signs outbound messages with a private key. Receiving servers look up the corresponding public key in DNS at selector._domainkey.yourdomain.com and verify the signature. For AWS SES, Easy DKIM generates three CNAME records you add to DNS and SES handles signing and automatic key rotation. The default is 2048-bit RSA, which is the current practical minimum. If you use BYODKIM, use 2048-bit RSA or Ed25519. A DKIM check that shows p= with an empty value is a revoked key and will cause DKIM to fail silently on every send until the key is regenerated and republished.

DMARC ties SPF and DKIM together and requires alignment: the domain in the From header must match or be a subdomain of the domain that passed SPF or DKIM. For cold email, start with p=none while you verify authentication is working, then move to p=quarantine once you have confirmed clean results across multiple campaigns.

Set a reporting address in the rua tag: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Without rua, you receive no aggregate reports and have no visibility into authentication failures or whether anyone is spoofing your domain. Aggregate reports arrive daily from Gmail, Outlook, and Yahoo and show authentication pass rates for all mail claiming to come from your domain.

Infrastructure Choices: Shared vs Owned

Shared infrastructure means the platform routes your mail through IPs and sending pools that other customers also use. Setup is fast: no AWS account, no IAM credentials, no DNS work beyond what the platform requires. For teams that want to start sending quickly, shared infrastructure is the lowest-friction path.

The tradeoff is reputation pooling. Your sending IP's complaint rate and bounce rate are aggregates across everyone on that pool. The platform can implement abuse controls to limit how badly a bad actor damages shared reputation, but they cannot eliminate the risk. When you fix your list hygiene, your reputation improves at the aggregate pace of the entire pool rather than reflecting only your own sending behavior.

Owned infrastructure means connecting your own Gmail, Outlook, Zoho, or AWS SES account. Your IP reputation is yours alone. Your domain's bounce and complaint history reflects only your own sending. If you fix your list hygiene, your reputation improves on your own schedule.

For AWS SES specifically: SES bills at roughly $0.10 per 1,000 emails with no monthly minimum. A team sending 500,000 emails per month pays $50 in SES fees. At that volume, owned SES infrastructure costs less than most bundled-platform pricing and carries no neighbor risk. The upfront setup takes a few hours. The ongoing maintenance is minimal once it is configured.

Warmup: What It Does and What Skipping It Costs

Warmup establishes a sending history that tells mailbox providers the domain is legitimate. Providers weight recent sending history when scoring new mail. A domain registered three weeks ago looks identical to a freshly registered spam domain unless it has accumulated positive sending signals.

Warmup generates those signals: sent mail with high open rates, replies, and emails moved from spam to inbox. Peer-to-peer warmup networks exchange emails between participating inboxes calibrated to produce these engagement signals at scale. A domain typically supports 30 to 50 cold sends per day after two weeks of clean warmup. Reaching 100 to 200 per day safely takes another one to two weeks beyond that.

What skipping costs: a domain that starts cold at volume will see spam placement rates of 30 to 60 percent at Gmail and Outlook on early campaigns. In severe cases, Gmail will defer or block delivery entirely. Recovering a reputation damaged by a cold start typically takes four to six weeks of clean, low-volume sending — longer than the warmup would have taken in the first place.

Background warmup — a low-volume warmup cadence running alongside active campaigns — is worth maintaining indefinitely. It accumulates positive engagement history during gaps between campaigns so you do not lose standing during a two-week pause in outreach.

List Hygiene: Bounce Thresholds, Complaint Rates, Suppression

Bounce rate. Hard bounces mean the address does not exist or permanently rejects mail. AWS SES's warning threshold is 5 percent; sustained rates above that trigger account review. Gmail and Outlook do not publish thresholds, but measurable deliverability degradation starts around 2 percent in practice. The fix is verification: run every address through an email verification service before importing. Most services catch role addresses (info@, support@, admin@), disposable addresses, and addresses that return permanent failures. Soft bounces are less damaging but contacts that soft bounce three consecutive times should be removed.

Complaint rate. A complaint is recorded when a recipient clicks "Report spam." AWS SES monitors this against a 0.1 percent threshold; exceeding it for sustained periods triggers account review. Complaint rate reflects whether recipients find your email relevant. The only real fix is targeting: sending to people who are plausible prospects for your specific offer, not broad volume scrapes.

Suppression. Any contact that has unsubscribed, complained, or hard bounced must be suppressed permanently across all future sends. AWS SES maintains an account-level suppression list you can query via API. A contact suppressed in one campaign should not reappear in a different campaign because someone re-imported the list without the previous suppression applied. That scenario is one of the more common causes of complaint rate spikes in otherwise well-managed accounts.

Pre-Send Checklist

Before any campaign launches, these checks should pass.

Authentication. SPF record resolves and passes for your sending domain. DKIM selector resolves and shows a non-empty p= value. DMARC record exists with an alignment policy set. Run these against your actual sending domain — if you send from go.yourdomain.com, check that subdomain, not the apex.

Blacklist status. Sending domain and IP ranges not listed on Spamhaus ZEN, Barracuda BRBL, SURBL, or URIBL. A single listing on Spamhaus ZEN can produce immediate spam placement at providers that query it before accepting mail. Check this within 24 hours of sending, not once at setup and never again.

Content. Subject line does not contain urgency claims, financial offer language, or excessive punctuation. Body has a healthy text-to-HTML ratio — plain text or minimal HTML is best for cold outreach. Any links resolve to clean domains with no redirect chains through flagged services.

Suppression applied. Unsubscribes and hard bounces from previous campaigns are removed. Contacts who replied asking to be removed are excluded even if no formal unsubscribe link was clicked.

Volume within bounds. Daily send count for each account stays within the warmup limit for that account's age and history. A domain that finished warmup two weeks ago should not be asked to send 500 emails today because the list is large. Volume outside established bounds triggers spam placement regardless of authentication and content quality.