Google, Yahoo & Microsoft bulk sender requirements (2026)

Since February 2024 for Gmail and Yahoo, and since May 2025 for Microsoft, the big mailbox providers stopped treating their sender rules as best-practice suggestions and began enforcing them at the SMTP layer. If you run your own mail server, this matters more than it does for anyone on a hosted platform — because every guide written for marketers assumes an ESP like Mailchimp or HubSpot is quietly handling authentication, unsubscribe headers and complaint monitoring for them. On a self-hosted PowerMTA or KumoMTA box, no one is. You own every requirement on this page, which is the price of the control and economics that made you self-host in the first place. This guide lays out exactly what the rules are in 2026 and how each one maps to something you configure on your own MTA.

Do the rules apply to you, and are you compliant?

Answer the three questions below. The checker tells you which requirements apply to your setup and which look unmet, with links to fix each. Nothing is sent or stored — it runs entirely in your browser.

Who the rules apply to

The line is volume, measured per provider. Send roughly 5,000 or more messages in a day to Gmail addresses and you are a bulk sender in Google's eyes; the same threshold applies independently at Yahoo and at Microsoft for their users. You do not have to be a "marketer" to cross it — a busy transactional system or a large notification stream counts just as much as a newsletter. Below that volume, a lighter set still applies to everyone: valid authentication on what you do send, a matching PTR, TLS, and a clean complaint record. The bulk threshold simply adds the full requirement set on top.

One nuance trips people up: the unsubscribe requirement is scoped to the kind of mail rather than the volume alone. Promotional and subscription messages must carry one-click unsubscribe; strictly transactional messages are exempt. Everything else — authentication, PTR, TLS, complaint rate — applies to all of your bulk mail regardless of type.

The requirements, provider by provider

The three providers converged on nearly identical rules, with small but real differences in enforcement and unsubscribe scope. This is the 2026 picture for bulk senders.

Requirement	Gmail	Yahoo	Microsoft (Outlook/Hotmail/Live)
Enforcing since	Feb 2024	Feb 2024	May 2025
SPF + DKIM	Required	Required	Required
DMARC (aligned)	Required (p=none ok to start)	Required (p=none ok to start)	Required
One-click unsubscribe (RFC 8058)	Required (marketing)	Required (marketing)	Recommended, not mandated
Honour unsubscribe within	2 days	2 days	2 days
Spam-complaint rate	< 0.30% (aim < 0.10%)	< 0.30%, inbox-only denominator	Low (enforced)
PTR / FCrDNS + TLS	Required	Required	Required
Failure code	550 5.7.26	550 5.7.9	550 5.7.515

Authentication: SPF, DKIM and DMARC

For bulk mail, all three are mandatory, and DMARC has to align — meaning the domain that passes SPF or DKIM matches the visible From domain. This is the requirement a self-hosted operator most directly owns. You publish an SPF record that names your sending IPs, you generate a DKIM key and have your MTA sign with it while publishing the public key in DNS, and you publish a DMARC record for the From domain. PowerMTA signs through its domain-key directive and KumoMTA signs in its Lua policy; either way the keys and records are yours to manage. The authentication guide walks through the records and the signing setup, and the generator tool drafts them.

DMARC deserves a word on policy. Publishing p=none satisfies the letter of the rule and is the right way to begin, because it lets you collect reports without affecting delivery. But none is monitoring, not protection, and the providers expect movement toward p=quarantine and then p=reject as your reports confirm that only your legitimate sources are signing. If an over-eager move to reject starts blocking your own mail, the p=reject troubleshooting guide covers the usual causes — almost always an unsigned stream you forgot about.

Two DKIM details catch self-hosted senders specifically. Use a key of at least 1024 bits, and 2048 where your DNS provider allows the longer TXT record, because some receivers now distrust short keys outright. And rotate the key periodically rather than signing with the same selector for years — a stale key is a standing risk, and rotation is straightforward once you publish the new selector before switching the MTA to it. These are the kind of details an ESP handles silently and a self-hosted operator has to own.

One-click unsubscribe (RFC 8058)

For marketing and subscription mail, Gmail and Yahoo require a machine-readable unsubscribe that works in a single click. A visible link buried in the footer does not satisfy it; the standard is about specific headers a mail client can act on by itself. Two headers work together: List-Unsubscribe advertising a mailto and an HTTPS endpoint, and List-Unsubscribe-Post declaring that a one-click POST is supported.

List-Unsubscribe: <https://example.com/u/abc123>, <mailto:[email protected]?subject=unsub>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

On a self-hosted MTA these are headers you inject into outgoing marketing mail — your campaign application usually adds them, but you confirm they are present and that your endpoint actually processes the POST. The rule also requires honouring the request within two days, so the endpoint has to suppress the recipient promptly, not queue it for a weekly batch. Microsoft recommends a working unsubscribe but has not mandated RFC 8058 specifically; implement it anyway, because it satisfies Google and Yahoo and is what recipients expect. Crucially, a frictionless unsubscribe is your best defence against the metric that actually gets you blocked: the spam-complaint rate.

The spam-complaint rate is the real gate

Authentication gets you in the door; the complaint rate keeps you there. Google asks senders to stay under 0.10% and to never reach 0.30%, and cites about 0.08% as a healthy figure. The number sounds generous until you do the arithmetic at your own volume. Use the calculator below to see how few complaints it takes.

A few hundred complaints across a large send is enough to cross the line, and at low volume a handful does it. Two further details matter for a self-hosted sender. First, Yahoo's calculation is stricter than Google's: Yahoo measures complaints against inbox-delivered mail only, excluding anything that landed in spam, so the same complaints produce a higher rate there — you can be compliant at Google and over the line at Yahoo with identical behaviour. Second, recovery is slow. After you fix whatever drove complaints up, Google keeps your domain ineligible for normal delivery support until the rate stays under 0.30% for several consecutive days, so the cost of a bad campaign is paid over a week, not an hour.

Without an ESP dashboard, you monitor this yourself. Enrol your domain in Google Postmaster Tools to see the spam rate and reputation Google assigns, register for Yahoo's Complaint Feedback Loop, and process the feedback-loop reports the providers send when a user complains. Those FBLs feed straight into suppression on your MTA — the bounce and FBL handling guide covers wiring them up, and what a feedback loop is explains the mechanism. The point is that complaint monitoring is not optional infrastructure you can defer; it is how you see the one number that decides whether your mail is accepted.

PTR, FCrDNS and TLS

Two baseline expectations round out the set, and both are squarely a self-hosted operator's job. Your sending IP needs a PTR record so a reverse lookup returns your sending hostname, and that hostname must resolve forward to the same IP — forward-confirmed reverse DNS. The PTR is set at your hosting provider, not on the server, and missing or mismatched reverse DNS is a quiet cause of spam folder placement that no amount of authentication compensates for. The reverse DNS guide covers it in full. TLS is the other: outbound connections must offer encryption, which any modern MTA does by default, but it is worth confirming your certificate and cipher configuration are current rather than assuming.

What is actually enforced now (2026)

The shift that caught many senders out is that enforcement hardened over 2025. Gmail began gently, returning temporary 4xx errors that merely delayed non-compliant mail and allowed retries; from late 2025 it moved to permanent 5xx rejections, so failing messages bounce with no retry. Microsoft skipped the gradual phase when it joined in May 2025, bouncing non-compliant bulk mail outright. The practical takeaway is that "mostly compliant" no longer degrades gracefully into the spam folder — it bounces. The three codes to recognise in your logs are Google's 550 5.7.26, Yahoo's 550 5.7.9 and Microsoft's 550 5.7.515; a cluster of any of them points at an unmet requirement rather than a transient glitch. When you see them, the rejection diagnosis guide and the broader deliverability fix help trace the cause.

The self-hosted reality: control and responsibility

None of these requirements is harder to meet on your own MTA than on an ESP — in several ways it is easier, because you control the DKIM keys, the IP pools, the headers and the bounce processing directly, with nothing hidden behind a vendor's abstraction. What changes is that the responsibility is entirely yours. An ESP that signs your DKIM and monitors your complaint rate is doing work you now do, so the value of a checklist like this is higher, not lower, when you self-host. The reward is the control and the economics: above roughly 100,000 to 200,000 messages a month, running your own PowerMTA or KumoMTA beats a hosted platform on cost, and you are not at the mercy of a shared-pool reputation you cannot see.

The way to make compliance routine rather than a recurring scramble is to bake it into the build. A correctly configured MTA signs every message, presents TLS, injects the unsubscribe headers on marketing streams, and feeds FBLs into suppression automatically — so the requirements are met by the setup, not by remembering to check. That is the whole idea behind doing the install properly once.

Common compliance gaps on a self-hosted setup

The requirements are simple to state and easy to half-implement. These are the gaps that most often turn a self-hosted sender from "I set up DKIM" into bounced bulk mail.

• SPF that names the wrong IPs. A record copied from an old host, or one that lists a control-panel box rather than the MTA actually sending, fails SPF for every message. Whenever the sending IPs change, the record has to change with them, and the lookup count has to stay within limits — a PermError from too many lookups is treated as a failure.
• DKIM that signs but does not align. A passing DKIM signature on a signing domain that does not match the visible From domain still fails DMARC alignment. Sign with a key whose domain matches the From, or the bulk requirement is unmet even though DKIM "passes".
• DMARC stuck at p=none forever. It meets the minimum but leaves your domain spoofable and signals to receivers that you have not finished. Move through the policy levels as your reports allow.
• An unsubscribe link that is not machine-readable. A footer link alone does not satisfy RFC 8058. Without the List-Unsubscribe-Post header and a working POST endpoint, Gmail will not show its native unsubscribe button, and recipients hit "report spam" instead — driving up the one rate that gets you blocked.
• No feedback-loop enrolment. If you never register for the providers' FBLs, complaints are invisible to you until your reputation has already fallen. Enrol, and wire the reports into suppression.
• Marketing sent from the transactional domain or IP. Mixing streams means a marketing complaint spike drags down the deliverability of password resets and receipts. Separate them by IP pool and ideally by subdomain.
• Assuming TLS and PTR are someone else's job. On a VPS the PTR is set in the provider's control panel, not on the server, and it is frequently left at a generic default that fails forward-confirmed reverse DNS. Check it explicitly.

None of these is hard to fix in isolation; the trouble is that each one fails quietly until enforcement turns a soft filter into a hard bounce. Running the checker at the top against your real configuration is the fastest way to surface which of them apply to you.

The bottom line

The 2026 bulk sender requirements are not complicated, but they are now enforced with rejections rather than gentle filtering. Authenticate with SPF, DKIM and aligned DMARC; add RFC 8058 one-click unsubscribe to marketing mail and honour it within two days; keep valid PTR and TLS; and treat the spam-complaint rate as the gate it is, monitored through Postmaster Tools and feedback loops rather than guessed at. On a self-hosted PowerMTA or KumoMTA every one of these is yours to configure — which is exactly why getting the setup right from the start is worth the effort. Use the checker above to find your gaps, then close them one record and one header at a time.