The 2026 sender gates: the deliverability checks to run this week, in order

The mailbox providers changed verbs. Non-compliant bulk mail used to get filtered, which meant it arrived somewhere you did not want it. Now it gets rejected, which means it does not arrive. Enforcement has been fully active across Google, Yahoo and Microsoft since May 2026, with Google and Microsoft issuing permanent 550 rejections, and roughly 30% of bulk senders are still partially non-compliant on at least one requirement. This post is the sequence we run, in order, with what each check proves. It takes about a week of small jobs, and most of them are twenty minutes.

What is actually at stake

Compliant senders average about 89% inbox placement in 2026, while non-compliant senders see 22% to 34% of their email routed to spam, a three to sevenfold penalty. Microsoft moved first and hardest on the rejection side: after announcing restrictions in early April 2025, it decided that from May 5, 2025 non-compliant bulk mail to Outlook.com, hotmail.com and live.com would be rejected entirely rather than junked, with this response:

550; 5.7.515 Access denied, sending domain [SendingDomain]
does not meet the required authentication level.

The threshold that pulls you into these rules is 5,000 or more emails per day per domain, and Microsoft's mirror of it applies at 5,000 or more to its consumer domains. Most account-based programs sit well under that. Run the checks anyway, for two reasons that the threshold hides, both of which we come back to at the end.

Day one: find out what you actually send

Before you touch DNS, answer two questions in writing. How many messages leave each of your domains in a day, at peak, counting every system. And which systems are those. The list is always longer than the marketing team thinks: the CRM, the ESP, the invoicing tool, the helpdesk, the applicant tracking system, the calendar scheduler, the NPS survey, someone's Zapier.

What it proves: whether the bulk rules apply to you, and which domain they apply to. It also produces the inventory that every later step depends on, because you cannot authorise senders you have not enumerated.

Day one: read one message's headers before changing anything

Send yourself a message through your actual sending path and open the raw source. Find the Authentication-Results header. You want three passes, and the third is the one that matters.

What it proves: whether your mail aligns, not merely whether it passes. At least one of SPF or DKIM must align with the From header domain, and misalignment is reported as error 421-4.7.32 with the text "no DMARC alignment". SPF can pass for your ESP's bounce domain while failing to align with the domain in the From field your recipient reads. That is the most common broken state we find, and it looks healthy from every dashboard.

Day two: SPF, one record, and the lookup budget

Publish one SPF record at the domain apex listing only the senders from your day-one inventory. Not two records, not a record containing a service you stopped paying for in 2023.

What it proves: which servers are permitted to put your domain in the envelope sender. It proves nothing about the From address your recipient sees, which is why it is never sufficient on its own. We wrote the mechanics up in detail in SPF, DKIM and DMARC explained, including the ten-lookup cap that quietly breaks large records.

Day two: DKIM signed with your own domain

Have your sending platform generate a key pair and publish the selector. The setting you are looking for is usually called a branded or authenticated sending domain. The result you want is a signature whose d= value is your domain, not your vendor's.

What it proves: that the message was not altered in transit and that it came from something holding your key. Combined with alignment, it is the half of DMARC that survives forwarding better than SPF does.

Day three: DMARC, starting at none

Publish a DMARC record with a policy of p=none and a real rua= address. The published minimum is a DMARC record at p=none, and all three of SPF, DKIM and DMARC are now required of bulk senders.

What it proves: nothing yet, and that is the point. It turns on reporting. Within a day you start receiving aggregate reports naming every system sending as you, which is how you find the four services that were not on your day-one inventory. Note that DMARC itself got firmer ground under it this year: DMARCbis was published as RFC 9989, 9990 and 9991 in May 2026, elevating DMARC to a Proposed Standard.

Day four: one-click unsubscribe that actually unsubscribes

Add the RFC 8058 header pair and make the endpoint accept an anonymous POST. One-click unsubscribe is required by Google, Yahoo and Apple and recommended by Microsoft, and requests must be processed within two days.

What it proves: that a recipient who wants out can get out without a login screen or a preference centre with nine checkboxes. This is the cheapest complaint-rate insurance available, because the alternative to an easy unsubscribe is the spam button, and the spam button is the metric with the hard ceiling.

Test it the way a recipient would. Send yourself a message, use the provider's own unsubscribe control, watch for the POST in your logs, then confirm that the address is gone from the next send.

Day four: PTR, forward-confirmed, and TLS

Valid PTR records on your sending IPs and forward-confirmed reverse DNS plus TLS for transmission are usually your platform's job. Verify them anyway, particularly if anything sends from your own infrastructure.

What it proves: that the connecting machine is who it says it is at the network layer, before any of the content checks run. Unauthenticated mail gets 421-4.7.26 as a deferral or 550-5.7.26 as a permanent rejection, and those are refusals at connection time, not spam-folder placements you can measure later.

Day five: read the complaint numbers, not the open rate

Get into Google Postmaster Tools and Yahoo's Sender Hub. The number to watch is the reported spam rate: Google requires it below 0.10% and says to avoid ever reaching 0.30% or higher.

What it proves: what the receiving side thinks of you, which is the only opinion that decides delivery. Everything upstream is a prerequisite for being judged at all.

Week two onward: move the policy

Once aggregate reports show your legitimate mail authenticating cleanly, move DMARC to quarantine, then to reject. This is the only step that has to wait, because it is the only one that can break something. Give it two weeks of clean reports.

Why a 150-account program should care about a 5,000-a-day rule

Two reasons, and neither is about the threshold.

The first is that rejection is domain-wide. The gates are evaluated against your organisational domain, so the ESP blasting a newsletter and the sales rep writing to eleven people share a reputation. A program that sends 600 messages a month can be perfectly disciplined and still get refused because a different department is not.

The second is arithmetic. A 0.10% spam rate is one complaint per thousand messages. If your program sends six hundred messages in a month, you do not have a single complaint of headroom inside that ratio. Providers compute the rate over a rolling window rather than a calendar month, so one bad week is not the whole picture, but the direction is clear: small, high-intent programs have less room for a careless send than a large list does, not more. Precision is not just an editorial preference here. It is the deliverability strategy.

One more limit worth knowing if your team sends from its own mailboxes: Microsoft's External Recipient Rate limit caps Exchange Online at 2,000 external recipients in 24 hours, a sub-limit inside the older 10,000 recipient rate limit, applied to new tenants from January 2025 and rolled out to existing ones through the second half of that year. Plenty of room for account-based work. No room at all for the sequencer somebody installed without telling you.

If you want a second pair of eyes on your own setup before the next send, tell us what you are trying to fix.