Cold email deliverability in 2026 — what actually changed

Between February 2024 and September 2026 the requirements for sending email barely moved. What moved was the consequence of not meeting them, and once, the specification itself. Four dated events account for almost everything that is genuinely different: Google and Yahoo's requirements taking effect on 1 February 2024, Microsoft switching to outright rejection on 5 May 2025, Gmail ramping enforcement from November 2025, and the IETF publishing DMARC as a Proposed Standard in May 2026. Everything else you will read about 2026 deliverability is inference.

The four dated changes, and which of them can reach you

Before the detail, the shape. Two of these apply only above a volume threshold, one applies to everyone, and one is a specification change whose practical effect depends on what your record says.

• 1 February 2024 — Google and Yahoo sender requirements take effect. A baseline for every sender; a stricter set above roughly 5,000 messages a day to personal accounts.
• 5 May 2025 — Microsoft begins rejecting non-compliant mail above 5,000 messages a day to Outlook.com, Hotmail.com and Live.com, rather than routing it to Junk as originally announced.
• November 2025 — Gmail begins ramping enforcement on non-compliant traffic, described by Google as including temporary and permanent rejections.
• May 2026 — RFC 9989, RFC 9990 and RFC 9991 are published, obsoleting RFC 7489 and RFC 9091 and moving DMARC from Informational to Proposed Standard.

A cold outreach programme sending a few hundred messages a day is inside the first event's baseline, outside the volume triggers of the second, exposed to the third, and affected by the fourth only through its own DMARC record.

February 2024: the floor that never moved back

Google's Email sender guidelines split senders into two sets, and the split is where most summaries go wrong.

Every sender, at any volume, must authenticate with SPF or DKIM, publish valid forward and reverse DNS for the sending IP, connect over TLS, format messages to RFC 5322, avoid impersonating Gmail in the From header, and keep the spam rate reported in Postmaster Tools below 0.30%. DMARC is not required at this level.

Bulk senders must do all of that plus authenticate with SPF and DKIM, publish a DMARC record on the sending domain — a policy of p=none satisfies the requirement — align the domain in the visible From header with either the SPF domain or the DKIM domain, and support one-click unsubscribe on marketing and subscribed messages, with a clearly visible unsubscribe link in the body.

The threshold is stated precisely in Google's own FAQ: a bulk sender is one sending close to 5,000 messages or more to personal Gmail accounts within a 24-hour period, and messages from the same primary domain count together toward that figure. Two details in that sentence do real work. "Personal Gmail accounts" excludes Workspace recipients, so a purely B2B programme reaches the threshold far more slowly than its total send volume suggests. And "the same primary domain" means splitting across mailboxes does not split the count.

The detail almost nobody quotes is what happens afterwards. Google's FAQ states that bulk sender status does not have an expiration date and that senders classified as bulk are permanently classified as such. One busy launch day is a permanent change of category. If you are anywhere near the threshold, meeting the bulk requirements before you cross it is cheaper than discovering the classification retroactively.

Yahoo published its own requirements alongside Google's, with the same shape: SPF or DKIM as a minimum, both plus a valid DMARC policy for bulk senders, a spam rate below 0.3%, one-click unsubscribe, and unsubscribes honoured within two days. Enforcement was rolled out gradually through the first half of 2024.

May 2025: Microsoft chose rejection over the Junk folder

Microsoft announced requirements for high-volume senders to its consumer domains — Outlook.com, Hotmail.com and Live.com — on 2 April 2025, for domains sending more than 5,000 messages a day. The original announcement said non-compliant mail would first be routed to Junk, with rejection to follow at an unannounced later date.

That plan changed. An update dated 29 April 2025 stated the decision had been revised to reject from the same 5 May 2025 start. The bounce is 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. It is a permanent 5xx, so nothing retries it, and the message never reaches Junk either.

Two consequences follow that are worth stating separately.

The first is that a rejection counts as a bounce inside your own sending system. A reputation problem at Microsoft therefore becomes a bounce-rate problem in your dashboard, which can trip an automatic pause that was designed for list quality. Diagnosing that correctly means reading the rejection string rather than the aggregate percentage.

The second is that 5.7.515 is routinely confused with a completely different Microsoft refusal. 550 5.7.509: Access denied, sending domain [domain] does not pass DMARC verification and has a DMARC policy of reject is Exchange Online enforcing a policy you published, at any volume, against a message that failed alignment. The first is Microsoft's volume rule and the fix is authentication coverage; the second is your own policy working as designed and the fix is alignment. What each provider rewards, and why Outlook fails differently from Gmail works through the asymmetry in full.

November 2025: Gmail moved from filtering toward rejecting

Google's sender guidelines FAQ states that from November 2025 Gmail began intensifying enforcement, and that messages failing to meet the sender requirements would experience disruptions including temporary and permanent rejections.

That is a change in kind rather than degree. A message filtered into spam is invisible to your sending system: it was accepted, it counted as delivered, and the only evidence is silence. A message rejected produces a status code, a reason string, and a row in your bounce log. From an operator's point of view the second is strictly better information, and strictly worse news.

It also changes what a rising bounce rate means. Before, a bounce was overwhelmingly a list-quality signal — an address that does not exist. Now a bounce can equally be an authentication signal from a receiver that used to file you quietly. The two demand opposite responses: one says clean the list, the other says fix DNS and stop sending until you have. Classifying by status code rather than counting failures is no longer optional.

May 2026: DMARC became a Proposed Standard, and two tags changed

The IETF published RFC 9989 in May 2026, alongside RFC 9990 for aggregate reporting and RFC 9991 for failure reporting. Together they obsolete RFC 7489 and RFC 9091, and promote DMARC from Informational to Proposed Standard for the first time.

Three changes have practical consequences for a sender.

pct= is removed. RFC 7489 let a domain apply its policy to a sampled percentage of mail, which is how staged rollouts from none to quarantine to reject were conventionally done. RFC 9989 removes the tag from the specification. Existing records carrying it are not broken and receivers that have not moved will keep honouring it — but a rollout plan built on percentage sampling is now standing on a mechanism the specification no longer contains. The replacement is the ordinary one: publish p=none with reporting, read the reports until you can account for every legitimate sender, then move the policy in one step.

np= is added. It sets a separate policy for non-existent subdomains of the organisational domain. If you have parked lookalike domains or subdomains that will never send, this is the tag that says so explicitly rather than relying on inheritance.

The Public Suffix List is gone. Determining a domain's organisational domain used to depend on the Public Suffix List; RFC 9989 replaces it with a DNS tree walk capped at eight queries. For a plain second-level domain nothing changes. For domains under multi-label public suffixes, or delegated namespaces, the answer can differ from what the list gave — and alignment is computed against that answer, so it can change whether a message aligns. The mechanics, and how to read what the reports now tell you, are in DMARC without the acronym soup.

Checking tools have to catch up too, and being honest about lag is more useful than pretending otherwise. Autocloz's record classifier still parses pct and still defaults it to 100 when absent, which is correct behaviour for the receivers that have not moved and is a legacy of RFC 7489 rather than a reading of the current specification.

What the four changes have in common

Read them together and a single direction emerges. Every change made the *consequence* of failing authentication more visible and more terminal, and none of them made the authentication requirements themselves harder.

SPF, DKIM and DMARC in February 2026 mean exactly what they meant in February 2024. What changed is that the penalty moved from a quiet filter to a loud refusal, from a deferral you could retry into a permanent 5xx, and from a policy nobody could cite to a Standards Track RFC.

This is good news for anyone who did the work, and it is a specific kind of bad news for anyone who did not: the failure is no longer gradual. There is no longer a comfortable middle state where mail mostly gets through while a record is quietly wrong.

Autocloz's free plan covers 5 users and 10 mailboxes with SPF, DKIM and DMARC monitoring, a background re-check of stale domains, and the warmup ramp included — start free if you would rather find a drifted record from a monitor than from a rejection.

What the move from deferral to rejection does inside your own system

The shift from soft refusals to permanent ones changes your data, not just your placement, and it is worth understanding before you react to a number.

A 4xx deferral is a temporary condition. Your sending system holds the message and retries on a schedule. Nothing is recorded as a failure, the recipient stays in the campaign, and if the condition clears the message eventually arrives. A reputation dip expressed as deferrals therefore shows up as slowness — sends queueing, throughput falling — rather than as errors.

A 5xx rejection is permanent. Your sending system records a bounce, the recipient is usually suppressed, and the row enters whatever bounce ratio your automation watches. So the same underlying reputation problem that used to look like a slow afternoon now looks like a list-quality incident, and an automatic pause built for bad imports can fire on an authentication failure.

Two practical consequences. First, split your bounce reporting by status class before you act on it: a wave of 5.7.x refusals and a wave of 5.1.1 mailbox-does-not-exist failures are the same percentage and opposite problems. Second, look at the split per mailbox and per domain rather than in aggregate — an authentication failure hits every mailbox on the affected domain at once, while a bad import hits whichever mailbox happened to send it, and per-mailbox and per-sequence funnel reporting is what makes that distinction visible without exporting anything.

Three things reported as 2026 changes that are not

Each of these circulates widely enough to plan around. None is accurate.

"Gmail now requires DMARC from every sender." It does not. Google's baseline for senders below the bulk threshold is SPF or DKIM, with no DMARC requirement at all. DMARC and alignment sit in the bulk-sender set. Publishing DMARC anyway is a good idea for the reporting alone, but it is a choice rather than a rule at small volume.

"Microsoft's rule applies to business mailboxes." It does not. The high-volume requirement covers Microsoft's consumer domains — Outlook.com, Hotmail.com and Live.com. Mail to a company running Microsoft 365 on its own domain is governed by Exchange Online's ordinary filtering and by whatever DMARC policy the *sending* domain published, which is the 5.7.509 path rather than the 5.7.515 one.

"The 5,000-a-day threshold counts everything you send." It does not. Google's definition counts messages to personal Gmail accounts within a 24-hour period, aggregated across the same primary domain. For a B2B programme whose list is mostly corporate addresses, total volume can sit far above 5,000 while Gmail-personal volume sits far below it.

What did not change, and still decides most outcomes

Three things people expected to change did not, and their absence is as informative as the changes.

No provider published a content requirement. There is still no official list of forbidden words, no rule about HTML versus plain text, no requirement about link count. What Google publishes about content is that messages must be formatted per RFC 5322 and must not impersonate Gmail. Everything else circulating on this topic is folklore or inference from a filter's open-source scoring rules.

No provider published a bounce-rate threshold. Google publishes a spam-complaint threshold. Yahoo publishes a spam-complaint threshold. Neither publishes a bounce ceiling, and the 2% and 2.5% figures that appear on every checklist are sending-platform conventions rather than requirements. Keep bounces low because a hard bounce means you mailed an address that does not exist, not because a specific published number is being enforced.

Placement is still unobservable from the sending side. A 250 reply at the end of an SMTP transaction means the receiving server took responsibility for the message. Which folder a human sees it in is decided afterwards, by a separate system, and nothing in the conversation reports it back. Every measurement of placement is either a proxy or a probe.

And the biggest non-change: complaint rate is still the number with the most weight and the least room, and it is still overwhelmingly a function of who you contacted rather than how you configured anything.

What a small cold sender should actually do differently now

Concretely, in order, for a programme sending a few hundred a day.

Publish DMARC even though the baseline does not require it. Not because your volume triggers the requirement, but because the reports are the only evidence you get about which of your senders fail alignment, and because Microsoft's 5.7.509 refusal is the receiver enforcing whatever you published.

Classify bounces by status code rather than counting them. A rising bounce rate in 2026 has two structurally different causes and the responses are opposite.

Assume you will cross 5,000 once. The classification is permanent, so meeting the bulk requirements while you are small costs a DNS record and an unsubscribe header, and meeting them afterwards costs a recovery.

Check the SPF lookup count on a schedule, not on setup. It is the one authentication failure that arrives without you touching anything, because the count includes the includes your vendors publish. The record generator produces a correct record for a given provider set; the point is to re-count it later.

Stop planning DMARC rollouts around pct. Use monitoring and a single policy change instead.

The rest of the operational floor, item by item with the command that proves each one, is in the deliverability checklist and its four unverifiable items.

What none of this changed, and what Autocloz does not do

None of these rules make a message wanted. They govern whether it is permitted to be considered, and the honest framing is that clearing them removes reasons to be refused rather than adding reasons to be read.

None of them is a placement mechanism either. A domain can satisfy every published requirement from Google, Yahoo and Microsoft and still be filtered on complaint history, and no requirement in any of these documents changes that.

Autocloz monitors authentication on connected sending domains and re-checks stale monitors on a background sweep; it injects the RFC 8058 one-click headers on SMTP sends, though not on the API sending modes of Zoho Mail, ZeptoMail or SendCoreX, whose APIs accept structured JSON with no custom-header field. Its in-house verifier never returns a definitive deliverable verdict on its own — the SMTP probe was removed in July 2026, so an address that clears every check is reported as risky rather than confirmed, which is honest and is also why "delete everything not marked deliverable" would empty a clean list. Its placement seed tests classify a probe as inbox, spam or missing, run when an operator asks rather than on a schedule, and observe monitored mailboxes rather than your recipients.

It cannot see inside Gmail's, Microsoft's or Yahoo's classifiers, and no product can. If you are weighing a general-purpose CRM that carries this monitoring against a dedicated cold-email platform, the side-by-side with Smartlead sets out where the two genuinely differ.