Gmail Bulk Sender Requirements 2025-2026: Enforcement and Compliance Guide

In February 2024, Google and Yahoo simultaneously announced bulk sender requirements that transformed email authentication from a best practice recommendation into a delivery-gating requirement. By November 2025, Google had explicitly escalated enforcement with a warning that non-compliant senders would face "temporary and permanent rejections" — and delivery data confirms that enforcement has become materially stricter than the initial rollout period. Microsoft joined with its own equivalent requirements effective May 5, 2025. Apple (iCloud) followed with authentication requirements in late 2024. The four major consumer ISPs — Google, Microsoft, Apple, and Yahoo, collectively known as MAGY — now maintain substantively equivalent sender requirement sets that cover the majority of global email addresses. This guide documents what the requirements are, how enforcement actually works in 2026, and how to confirm compliance.

The MAGY Requirements: What Four ISPs Now Require

The MAGY sender requirements — named for Microsoft, Apple, Google, and Yahoo — are substantively similar across all four providers and cover three main areas: authentication, unsubscribe functionality, and complaint rate management. While each provider's documentation varies in specifics, the practical requirements for any sender who wants to reach all four providers are:

Authentication Requirements: SPF, DKIM, DMARC

Authentication compliance is the non-negotiable foundation of MAGY requirements. The specific authentication standard required:

DKIM signing with your own domain (not shared ESP domain): The DKIM signature must have d= set to the From: header domain or its organisational parent. Using an ESP's shared signing domain (d=sendgrid.net, d=mailchimp.com, d=klaviyo.com) does NOT satisfy this requirement for most providers — Google specifically requires "at least one of the From: domain or its parent domain (the top two levels of the From: domain) is covered by the DKIM signature." Configure custom DKIM signing from the ESP's settings (Sendgrid: Sender Authentication; Mailchimp: Domain Authentication; Klaviyo: Sending Domains).

DKIM key size: Google requires DKIM keys of at least 1024-bit (2048-bit recommended). 1024-bit keys that were previously acceptable may no longer meet the stricter enforcement standards applied in 2025-2026. Audit all DKIM keys and rotate any 1024-bit keys to 2048-bit as priority.

DMARC record publication: The DMARC record must be published at _dmarc.yourdomain.com. The minimum compliant DMARC record for Google's requirements: v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. The rua= address must be functional — Google and Yahoo send aggregate reports to this address. A non-functional rua= address technically complies with the publishing requirement but misses the monitoring benefit. Note: p=none satisfies the MAGY minimum requirement but does not provide brand protection. Advancing to p=quarantine or p=reject provides anti-spoofing protection that is increasingly expected by enterprise recipients.

PTR/FCrDNS — often overlooked: Google added SMTP rejection reporting to DMARC aggregate reports in mid-2025, and the data revealed that a significant fraction of email rejection events are caused by missing or misconfigured PTR records — not by DKIM or DMARC issues. For any dedicated IP or self-managed MTA, verify that: (1) every sending IP has a PTR record set by the hosting provider; (2) the PTR record resolves to a valid hostname; (3) the hostname in the PTR record resolves back to the same IP (FCrDNS/forward-confirmed reverse DNS). This is the most commonly missed authentication requirement among senders who otherwise have DKIM, SPF, and DMARC correctly configured.

One-Click Unsubscribe: RFC 8058 Implementation

The one-click unsubscribe requirement is one of the most frequently non-compliant elements in otherwise well-configured sending programmes. Many senders include a visible unsubscribe link in the email footer — which satisfies the CAN-SPAM requirement — but do not include the machine-readable List-Unsubscribe and List-Unsubscribe-Post headers that Gmail specifically checks for when displaying the "Unsubscribe" option in the Gmail interface and evaluating compliance.

The required headers for one-click unsubscribe compliance:

# Both headers must be present
List-Unsubscribe: <https://your.domain.com/unsubscribe?email=recipient%40domain.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

# The URL must accept a POST request (not just GET)
# When Gmail's interface triggers one-click unsubscribe, it sends:
# POST https://your.domain.com/unsubscribe?email=recipient%40domain.com
# With body: List-Unsubscribe=One-Click

The unsubscribe endpoint must process the POST request and remove the recipient from the active mailing list within 2 business days. The endpoint must be accessible without authentication — Gmail's POST request comes from Google's servers and cannot authenticate as the recipient. Testing the one-click unsubscribe implementation: use Google's Email Sender Guidelines compliance checker (Google provides a tool to test individual messages against all sender requirements) or send a test email to a Gmail address and verify whether the Gmail interface displays the one-click unsubscribe option.

Spam Rate Threshold: The 0.10% Rule

Google's published spam rate threshold is 0.10% as measured in Google Postmaster Tools. Senders whose daily spam rate exceeds 0.10% are non-compliant with the Google bulk sender requirements, regardless of their authentication configuration. The practical enforcement mechanism: spam rate above 0.10% → Gmail domain reputation declines → increased spam folder filtering → reduced inbox placement. This is not a binary on/off — it is a progressive degradation that accelerates as the spam rate rises above the threshold.

Google recommends keeping the spam rate below 0.05% for sustained optimal inbox placement — the 0.10% threshold is the maximum, not the target. Postmaster Tools reports spam rate as a daily value — spikes on specific campaign days are visible in the daily chart even if the 30-day rolling average is below threshold. Google's filtering applies based on the trend, not just point-in-time values — a consistent 0.04% spam rate with one spike to 0.12% is treated differently than a sustained 0.09% with no spikes.

How Enforcement Works in 2025-2026

Google's enforcement approach has evolved from the initial "soft" implementation in February 2024 to the more aggressive enforcement announced in November 2025. The November 2025 Google update explicitly stated that non-compliant senders will experience "temporary and permanent rejections" — meaning 4xx deferred responses (temporary rejection, message stays in queue) and 5xx rejected responses (permanent rejection, message lost).

The enforcement mechanics: Google evaluates each incoming SMTP connection and delivery attempt against compliance criteria. Violations at the SMTP level (missing authentication, invalid PTR records) trigger connection-level rejection or deferral before the message content is evaluated. Violations at the content level (spam rate above threshold) trigger filtering that routes messages to spam regardless of other compliance factors. The two enforcement channels operate independently — a sender can be compliant at the SMTP authentication level and still face aggressive spam folder placement due to spam rate violations.

The practical experience of non-compliance enforcement: senders who are non-compliant on authentication (missing DKIM, no DMARC record) began seeing 4xx deferred responses in November 2025. Messages that were previously accepted with warnings are now being deferred or rejected outright. Senders with high spam rates (above 0.10%) see progressively more aggressive spam folder placement that does not improve until the spam rate is brought below threshold and the reputation recovers — typically 4-8 weeks of below-threshold sending.

Microsoft's May 2025 Enforcement

Microsoft announced its bulk sender requirements in April 2025, with enforcement beginning May 5, 2025. Microsoft's initial enforcement approach: route non-compliant traffic to the Junk (spam) folder rather than outright rejecting it — a more gradual enforcement than Google's approach. Microsoft's stated requirement set mirrors Google's: SPF authentication, DKIM signing with the sender's own domain, DMARC record published, valid FCrDNS/PTR for sending IPs, and one-click unsubscribe for bulk senders.

The Microsoft-specific compliance consideration: FCrDNS (Forward-Confirmed reverse DNS) has historically been enforced more strictly by Microsoft than by Google. Google may accept some messages from IPs with imperfect PTR configuration; Microsoft more consistently rejects or flags connections from IPs where PTR does not resolve correctly. This is why the Google DMARC rejection data revealed PTR issues as a primary cause of Microsoft-bound delivery failures — senders who pass Google's authentication evaluation may still fail Microsoft's stricter PTR enforcement.

SNDS (Smart Network Data Services) remains the Microsoft-specific reputation monitoring tool. Register all sending IPs in SNDS and review IP status (Green/Yellow/Red) after the Microsoft enforcement implementation to confirm compliance is being recognised as such. Yellow or Red SNDS status after the May 2025 enforcement date indicates a specific IP-level issue that requires investigation beyond the standard compliance requirements.

Compliance Audit Checklist

Non-Compliance Consequences and Recovery

Non-compliance consequences scale with the severity and duration of non-compliance. The enforcement spectrum: (1) Minor non-compliance (missing List-Unsubscribe-Post header but List-Unsubscribe present) — may not trigger rejection but reduces compliance score that affects inbox placement at the margin. (2) Authentication non-compliance (missing DMARC record, using ESP shared DKIM domain) — may trigger 4xx deferred or 5xx rejected responses at Gmail November 2025 enforcement, depending on whether the non-compliance is in Google's enforcement scope for the sender's sending pattern. (3) Spam rate above 0.10% — progressive spam folder filtering that degrades inbox placement directly proportional to how far above threshold the spam rate is and how long it stays elevated.

Recovery from authentication non-compliance is immediate once the configuration is corrected — authentication failures that caused rejection stop as soon as the correct authentication is configured and propagated. Recovery from spam rate-driven domain reputation decline takes 4-8 weeks of sustained below-threshold sending to restore the reputation tier to its previous level. During recovery, senders typically reduce send volume, clean lists, and implement engagement-based segmentation to keep the spam rate below threshold consistently while the reputation rebuilds. The MAGY requirements are not arbitrary compliance exercises — they codify the sending practices that produce reliable inbox placement for all commercial email programmes that implement them correctly.

MAGY compliance is now the entry fee for commercial email. The requirements — correct authentication, one-click unsubscribe, spam rate management — are not burdensome for programmes that have been following email best practices for years. They are only burdensome for programmes that were relying on permissive enforcement to avoid implementing what should have been done in 2020. Audit the checklist; fix what is missing; maintain compliance through the monitoring discipline documented throughout this guide; and MAGY compliance becomes the invisible infrastructure that makes reliable inbox placement possible across all four major ISP environments.