Bulk Sender Requirements 2026: Google, Yahoo and Microsoft

Who counts as a bulk sender in 2026?

Google publishes a hard number. You are a bulk sender if you send more than 5,000 messages per day to personal Gmail accounts within any rolling 24-hour period (Google Workspace Admin Help). Google also notes that once you cross 5,000 even once, you are permanently classed as a bulk sender, so there is no “quiet month” that resets the clock.

Microsoft uses the same 5,000-per-day threshold for what it calls high-volume senders to consumer mailboxes (as reported across deliverability sources), where the consumer mailboxes in scope are Outlook.com, Hotmail.com and Live.com.

Yahoo is the exception worth flagging: its Sender Hub best-practices page frames the rules around “bulk senders” without publishing a numeric daily threshold. Industry consensus aligns Yahoo with Google's 5,000-per-day figure in practice, but Yahoo does not state that number officially, so treat it as guidance rather than a hard line. The practical takeaway for an IT team: assume the rules apply the moment a campaign or transactional flow looks like “bulk”, because the authentication controls below are good hygiene at any volume.

What do Google and Yahoo require from bulk senders?

Google and Yahoo announced near-identical requirements that took effect in February 2024, and their lists overlap almost exactly. Both move email authentication from “recommended” to “mandatory for bulk”. The table below maps each requirement to the control that satisfies it.

The single most important shift is that DMARC is now mandatory, not optional, for bulk senders. If you have never published a DMARC record, start with our guide to what DMARC is and how it works, then read how SPF, DKIM and DMARC fit together so the alignment requirement makes sense before you publish anything.

What does Microsoft require from high-volume senders?

Microsoft was a year behind Google and Yahoo. It published Strengthening Email Ecosystem: Outlook's New Requirements for High-Volume Senders on its Defender for Office 365 tech community blog on 30 April 2025, with enforcement beginning 5 May 2025. The core requirements mirror Google and Yahoo: passing SPF, passing DKIM, and a DMARC policy of at least p=none that aligns with SPF or DKIM (Microsoft prefers both to align).

Where Microsoft differs is the unsubscribe wording. It expects a functional, clearly visible unsubscribe link, but it does not explicitly mandate the RFC 8058 one-click header the way Google and Yahoo do. In practice, if you have already implemented one-click unsubscribe to satisfy Google and Yahoo, you comfortably exceed Microsoft's bar, so build to the stricter standard once and you are done across all three (requirement detail per Validity).

One scoping note worth getting right for procurement and client communications: the consumer mailboxes in scope are Outlook.com, Hotmail.com and Live.com. These are consumer addresses, not the Microsoft 365 tenants your business clients use. Mail flowing between corporate Microsoft 365 tenants is governed by tenant policy, not this consumer programme, though the same authentication hygiene applies. If you run a Microsoft 365 estate, our DMARC for Office 365 guide covers the SPF, DKIM and DMARC setup specific to that platform.

What changed in late 2025 and 2026?

The requirements have not loosened; enforcement has hardened. Two developments matter for anyone reviewing their setup in 2026.

Gmail moved to permanent rejections. When the rules first landed in February 2024, Google ramped enforcement gradually: temporary errors on a small percentage of non-compliant traffic, then rejection of a growing proportion through April 2024, with the one-click unsubscribe deadline extended to 1 June 2024. Over the course of the ramp, Gmail moved from temporary deferrals (which use SMTP code 421) to permanent rejections that return 550-5.7.26 with the message “Unauthenticated mail rejected (permanent)”. A permanent rejection means the message is gone, not retried, so a misconfigured domain now loses mail outright rather than buying time on a deferral queue.

Microsoft is escalating from junk routing toward rejection. Microsoft initially announced that non-compliant high-volume mail would be routed to the Junk folder, then amended its stance toward rejecting non-compliant mail outright. Rejected mail returns SMTP error 550 5.7.515 Access denied, citing that the sending domain does not meet the required authentication level. By 2026, multiple deliverability sources report that non-compliant high-volume mail to consumer Outlook mailboxes is being rejected. The exact date Microsoft flipped from junk to reject is reported inconsistently, so the safe summary is: enforcement has been live since 5 May 2025 and is escalating from junk routing toward rejection.

The net effect across all three providers in 2026 is that “mostly authenticated” is no longer a soft failure. A domain that drifts out of compliance can have legitimate customer-facing mail bounced permanently, which is exactly the kind of incident an MSP wants to catch before the client's sales team does.

It is worth knowing how to read the bounce codes, because they tell you which control failed. A 550-5.7.26 from Gmail means the message was unauthenticated, so SPF and DKIM are the place to look. A 550 5.7.515 from Microsoft says the sending domain did not meet the required authentication level, again pointing at the SPF, DKIM and DMARC trio. Neither code is about content or spam scoring; both are about the domain failing the authentication gate, which means the fix is in DNS, not in the message body. If you only see these intermittently, the usual cause is one sending service in the mix that is not covered by SPF or not signing with DKIM, so the mail it sends fails while everything else passes.

What DNS records satisfy SPF, DKIM and DMARC for a bulk sender?

The authentication trio is the part most likely to fail an audit, so here is a concrete, minimal example for a sending domain. Replace the include mechanisms and selectors with the ones your email service provider gives you.

; SPF: authorise every legitimate sending service, then -all
example.com.              IN  TXT  "v=spf1 include:_spf.google.com include:sendgrid.net -all"

; DKIM: the public key your ESP publishes under a named selector
s1._domainkey.example.com. IN  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQ..."

; DMARC: at least p=none, with a reporting address you actually read
_dmarc.example.com.       IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=s; aspf=s;"

A few things to get right so the bulk-sender checks pass cleanly:

• SPF must end in -all and stay under 10 DNS lookups. Every include: counts against the RFC 7208 limit of ten. Exceed it and SPF returns a permanent error, which breaks alignment. If you are over the limit, see how to fix “too many DNS lookups” or flatten the record with the SPF flattener.
• DKIM must be signed by every sending service. One missing selector and a slice of your mail goes out unsigned, which fails the bulk-sender DKIM requirement for that slice. Provider setup steps differ, so follow our set up DKIM by provider guide.
• Alignment, not just a pass, is what matters. SPF or DKIM passing on the envelope is not enough; the domain in the From: header must match. The adkim and aspf tags control strict versus relaxed matching.

If you are building these from scratch, our walkthrough for creating SPF, DKIM and DMARC records and the DMARC record generator produce the exact strings to paste into DNS.

How does one-click unsubscribe actually work?

The behaviour is defined in RFC 8058, “Signaling One-Click Functionality for List Email Headers” (Proposed Standard, March 2017). Your marketing mail needs two headers working together:

List-Unsubscribe: <https://example.com/unsub?id=abc123>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

When a recipient clicks the unsubscribe affordance the mailbox provider renders, the provider performs an HTTPS POST to the List-Unsubscribe URI carrying the single key/value pair List-Unsubscribe=One-Click as the body. RFC 8058 requires that the message carries a valid DKIM signature covering both of these headers, and that the POST endpoint accepts the request without cookies or additional authentication. The user never lands on a “click here to confirm” page; the single POST is the unsubscribe.

Two operational gotchas catch teams out. First, the endpoint must handle a POST, not a GET, so a plain link to an unsubscribe web page does not satisfy the requirement on its own. Second, because RFC 8058 ties the headers to DKIM, your one-click setup depends on DKIM being correct, which is another reason the authentication trio comes first. And remember the operative deadline: once a recipient unsubscribes, you have two days to stop sending to them.

How do I keep my spam complaint rate under the limit?

Google's threshold is the clearest published number across the requirements: keep your spam rate, as reported in Google Postmaster Tools, below 0.3%, and avoid ever reaching 0.3% or higher. Google additionally recommends keeping it below 0.1%. Yahoo states the same 0.3% ceiling. Treat 0.1% as the target you manage to and 0.3% as the cliff you must never approach.

That rate is the proportion of delivered messages a recipient marks as spam, so it is driven by list hygiene and relevance, not by your DNS. The practical levers are: only mail people who opted in, make the unsubscribe so easy that nobody reaches for the spam button instead, segment so you are not sending irrelevant campaigns, and warm up new sending IPs gradually. A clean, well-aligned authentication setup is necessary but not sufficient; you can be perfectly authenticated and still get throttled if the complaint rate climbs.

Do bulk sender rules mean I should jump straight to p=reject?

No. The bulk-sender programmes only require a published DMARC record of at least p=none with passing alignment. Compliance does not demand p=reject. That said, leaving an active sending domain at p=none forever means you meet the letter of the rules while still allowing anyone to spoof your domain, so the right move is to progress to enforcement, just not recklessly.

The correct progression is report-driven. Start at p=none, read the parsed DMARC aggregate reports until you can see every legitimate sender authenticating and aligning, then advance none → quarantine → reject only when the data is clean. ShieldMarc's readiness indicator tells you when a domain is safe to advance based on the actual report data, rather than on a calendar. Our guide to moving from p=none to p=reject walks through the full sequence.

One tag is worth understanding so you can recognise bad advice when you see it. DMARC has a pct= tag, and RFC 7489 defines it with a quirk: setting pct=50 on a quarantine policy means 50% of failing mail is quarantined and the remaining 50% gets the next-lower policy (none), not that 50% is unaffected. It does not split traffic cleanly the way people assume. ShieldMarc does not recommend ramping the pct= tag as a rollout strategy. It creates an ambiguous, half-enforced state that is hard to reason about and slow to debug. Advancing the full policy only when the reports are clean is clearer and safer.

How do MSPs keep this true across dozens of client domains?

The hard part of bulk-sender compliance is not configuring one domain; it is keeping it true across an estate. A client adds a new email tool that sends unsigned, an SPF record quietly tips over the 10-lookup limit, a DKIM key gets rotated and the DNS record is not updated, or someone publishes a DMARC record without a reporting address so nobody sees the failures. Any of these can put a domain back into the rejection path, and in 2026 that means lost mail rather than a warning.

For a quick point-in-time check on any single domain, run a free DMARC Checker scan or a full Security Grade, which reports the SPF, DKIM and DMARC state plus alignment and policy in one pass, with no account required. That is enough to confirm a domain meets the bulk-sender authentication bar today.

For an estate, continuous monitoring is what stops a compliant domain silently drifting non-compliant. ShieldMarc is built and priced for UK MSPs and multi-domain IT teams: it parses the DMARC aggregate reports for every domain, surfaces unauthorised senders, and tracks the readiness signal so you know which domains are safe to advance toward enforcement and which still have a sender that would break if you did. If your single domain just needs a free long-term monitor, an honest answer is that EasyDMARC's free plan or dmarcian's free Personal plan fit that slot better; ShieldMarc's free Starter tier is a one-domain evaluator, and the first paid plan covers 25 domains, which is the honest signal of who the product is built for.

A practical workflow for an MSP onboarding a client into bulk-sender compliance looks like this. First, run a Security Grade on the client's sending domain to capture the starting state and fix any obvious gaps, an SPF record without -all, a missing DKIM selector, no DMARC record at all. Second, publish DMARC at p=none with a reporting address so the aggregate reports start flowing, which immediately satisfies the bulk-sender minimum. Third, watch the parsed reports for a couple of weeks to confirm every legitimate sender the client actually uses (their email platform, their marketing tool, their helpdesk, their invoicing system) is authenticating and aligning. Fourth, advance the policy toward enforcement once the data is clean. Doing this domain by domain across a portfolio is exactly what the per-domain reporting and readiness signal are for, and it is why brand domain grouping on the MSP plan matters: a client who owns the same brand on several TLDs does not consume several slots.

What does ShieldMarc cost for managing bulk-sender compliance?

Pricing is published in GBP across every tier:

See the full breakdown on the pricing page. ShieldMarc is UK owned, EU hosted by default, with UK hosting available on request, which matters for public sector procurement. NHS trusts and other public sector bodies are a distinct, supported persona, with the product purpose-built for the post Mail Check transition.