Bulk Sender Requirements: Gmail, Yahoo, Microsoft, Apple

In early 2024 Gmail and Yahoo jointly raised the bar for anyone sending them bulk mail. Microsoft followed in 2025 for Outlook.com, and Apple maintains its own (less prescriptive) guidance for iCloud Mail. The rules rhyme, but they are not identical, and the differences are exactly where senders get caught: a threshold that exists at Gmail but not Yahoo, a spam-rate ceiling Microsoft never publishes, a one-click unsubscribe that is mandatory in two places and merely “recommended” in a third.

This page is the comparison hub. Every value below is quoted or paraphrased directly from the provider’s own published guidance, with the source linked at the foot of the page. Where a provider is silent on something, this page says so rather than filling the gap with an industry rumor.

The 60-second version

• Authenticate or do not deliver. All four want SPF and DKIM. Gmail, Yahoo, and Microsoft require both SPF and DKIM for bulk/high-volume senders, plus a published DMARC policy (minimum p=none) that is aligned with the From: domain.
• Two providers publish a volume threshold: 5,000 messages/day (Gmail and Microsoft). Yahoo and Apple deliberately do not publish a number.
• One-click unsubscribe (RFC 8058) is a hard requirement at Gmail and Yahoo for bulk marketing mail. Microsoft and Apple ask for a working unsubscribe but do not mandate the RFC 8058 mechanism in their published guidance.
• Only Gmail and Yahoo publish a spam-complaint ceiling. Gmail: stay under 0.10%, never reach 0.30%. Yahoo: keep it under 0.3%. Microsoft and Apple publish no number.
• Apple is the odd one out: no volume threshold, no spam-rate number, no feedback loop, and no allow list - just a list of hard requirements whose failure means rejection.

Side-by-side: the requirements

The table below is the core of this page. “Not stated” means the provider’s published guidance does not address it - not that the practice is safe to ignore.

Requirement	Gmail	Yahoo / AOL	Microsoft Outlook.com	Apple iCloud
Effective date	Feb 1, 2024	Feb 2024 (gradual); unsubscribe Jun 2024	May 5, 2025	Page updated Feb 25, 2025 (no enforcement date)
Volume threshold for the enhanced rules	5,000 messages/day	Not specified	5,000 emails/day	Not specified
SPF	All senders: SPF or DKIM. Bulk: both required	All: SPF or DKIM. Bulk: both	High-volume: must pass	Required
DKIM	All senders: SPF or DKIM. Bulk: both, min 1024-bit (2048 recommended)	All: SPF or DKIM. Bulk: both, min 1024-bit (2048 recommended)	High-volume: must pass	Required
DMARC	Bulk: published, min p=none	Bulk: published, min p=none, must pass	High-volume: min p=none	Must publish a policy (no minimum p= stated)
DMARC alignment	From: must align with SPF or DKIM domain	From: must align with SPF or DKIM domain	From: must match SPF and/or DKIM domain	Honors a published policy (no alignment rule stated)
One-click unsubscribe (RFC 8058)	Required for bulk (marketing + subscribed)	Required for bulk marketing (RFC 8058 preferred, mailto acceptable)	Recommended, not a hard requirement	Unsubscribe link required; RFC 8058 not stated
Unsubscribe honor window	Not stated on this page	Within 2 days	Not stated	”Immediately” (no SLA stated)
Spam-complaint rate	Below 0.10% target; never reach 0.30%	Below 0.3%	Not stated	Not stated
Valid PTR / rDNS	Required (all senders)	Strongly recommended	Not stated	Required
TLS for transmission	Required (added Dec 2023)	Not stated	Not stated	Not stated (RFC 5321 implied)
Feedback / postmaster tooling	Google Postmaster Tools	Complaint Feedback Loop via Sender Hub (DKIM-based)	Sender support portal (SNDS/JMRP not referenced in this guidance)	None offered
Allow list / safe-sender bypass	Not available	Not available	Safe-sender list not honored for enforcement	Not offered
Message format	RFC 5322	RFC 5321 / RFC 5322	Standard compliance expected	RFC 5321 / RFC 5322

Why these rules exist

None of this is arbitrary. Each rule maps to a specific abuse pattern the providers spent a decade absorbing:

• SPF + DKIM + aligned DMARC make the visible From: domain accountable. Without alignment, a spammer can pass SPF on their own throwaway domain while spoofing your brand in the From: header. DMARC alignment is what ties the authenticated identity back to the domain the recipient actually sees.
• The 5,000/day threshold (Gmail and Microsoft) is a triage line, not a safe harbor. Both providers say the rules below the line are still best practice; the threshold simply marks where enforcement bites hardest. Crossing it briefly can still trip the bulk classification.
• One-click unsubscribe exists because “click here, then log in, then confirm” funnels were used to keep unwilling recipients on lists. RFC 8058 lets the mail client unsubscribe with a single action and no round-trip to the sender’s site, which is why Gmail and Yahoo made it mandatory.
• The spam-complaint ceiling is the single most direct reputation signal a provider has: it is the recipients themselves marking your mail as junk. Gmail’s two numbers are a gradient - 0.10% is the “you are fine” line, 0.30% is the “you are now causing harm” line you must never touch.
• Valid PTR/rDNS is table stakes for any legitimate mail server. Generic or missing reverse DNS is one of the oldest and cheapest spam signals.

The fault lines (where the providers diverge)

This is the part a single “2024 requirements” summary usually flattens:

1. Thresholds are not universal. Gmail and Microsoft both publish 5,000/day. Yahoo explicitly refuses to publish a number: it classifies a “bulk” sender by volume but “will not specify a volume threshold.” Apple publishes no number either. Designing your program only around 5,000/day means you can be a “bulk sender” at Yahoo while still under Gmail’s line.
2. One-click unsubscribe is mandatory in only two places. Gmail and Yahoo require RFC 8058 for bulk marketing. Microsoft’s guidance lists a functional unsubscribe as a recommendation, not a hard enforcement item. Apple requires an unsubscribe link but does not name RFC 8058. Implement RFC 8058 everywhere anyway - it satisfies the strict providers and harms nothing at the lenient ones.
3. Spam-rate numbers exist at only two providers. Gmail (0.10% / 0.30%) and Yahoo (0.3%) publish ceilings. Microsoft’s high-volume guidance and Apple’s page publish none. The absence of a number is not permission; both still act on reputation. It just means you cannot point to a published line.
4. Yahoo measures complaints differently. Yahoo states its spam rate is “calculated in our system based on mail delivered to the inbox.” If you compute your own rate against total sent, your number and Yahoo’s will not match.
5. TLS and PTR are not stated everywhere. Gmail explicitly requires TLS (since December 2023) and PTR. Apple requires reverse DNS. Yahoo strongly recommends meaningful, non-generic PTR. Microsoft’s high-volume guidance states neither. Again: “not stated” is not “not checked.”

Common mistakes this table prevents

• Treating 5,000/day as a hard on/off switch. It is the enforcement focus, and the providers say the same rules are best practice below it. Yahoo and Apple do not even publish a number.
• Publishing p=none and stopping. p=none is the floor that lets you through the gate; it does nothing to stop spoofing. Microsoft explicitly advises moving none → quarantine → reject once your legitimate sources are aligned.
• Putting an unsubscribe link in the body but no List-Unsubscribe header. Gmail and Yahoo require the header (RFC 8058 one-click). A body link alone does not satisfy them for bulk mail.
• Assuming an allow list will save you. Microsoft says the safe-sender list is not honored for the new enforcement, and Apple offers no allow list at all. There is no list you can buy your way onto.
• Computing your complaint rate against total volume and trusting it. Yahoo (and Postmaster-style measurement generally) is inbox-delivered-based; your internal denominator will differ.

Effective dates, in order

Dec 2023    Gmail adds TLS as a transmission requirement
Feb 1, 2024 Gmail bulk-sender requirements take effect (5,000/day)
Feb 2024    Yahoo requirements begin gradual rollout through H1 2024
Jun 2024    Yahoo begins enforcing the List-Unsubscribe (one-click) policy
Apr 2, 2025 Microsoft publishes the Outlook.com high-volume sender post
Apr 30,2025 Microsoft updates the post (the "April 29 update")
May 5, 2025 Microsoft enforcement begins for high-volume senders (5,000+/day)

Apple’s page carries no enforcement date; the version retrieved here was last updated by Apple on February 25, 2025.

A note on Microsoft’s enforcement state

Microsoft’s high-volume post was edited in layers and is internally contradictory about the May 5, 2025 action. One paragraph (the April 29 update) says non-compliant mail will be rejected with 550; 5.7.515 Access denied, sending domain [SendingDomain] does not meet the required authentication level. A second paragraph says Outlook will route non-compliant high-volume mail to Junk first, with rejection to follow on a date “to be announced.” The last-stated action for May 5 is routing to Junk, with a hard-reject date still unannounced as of this page’s last check. Treat both as published-but-ambiguous and authenticate fully so the distinction never matters to you. The dedicated Microsoft page covers this in detail.

Beyond the big four: more mailbox providers

Gmail, Yahoo, Microsoft, and Apple set the tone, but they are not the whole inbox. Several other providers publish their own postmaster requirements, and they matter a lot for European and regional audiences. Each has a dedicated page here:

• Orange / Wanadoo (France) - mandatory SPF + DKIM + DMARC (all must pass), strict per-connection limits, a published error-code table, and feedback loops via SignalSpam. Complaint trigger currently 0.6%, moving toward 0.3%.
• GMX & WEB.DE (Germany, United Internet) - DKIM with valid alignment is mandatory; SPF alone is not sufficient. Double opt-in for bulk, M3AAWG/CSA alignment, CSA membership recommended.
• Comcast / Xfinity (US) - detailed legacy postmaster rules (rDNS, SenderScore-keyed rate limits, BL/RL codes, FBL), now migrating comcast.net mailboxes to Yahoo Mail through 2026, so Yahoo’s rules increasingly apply.
• Fastmail (privacy-focused) - score-based filtering that rarely hard-rejects, strong FCrDNS/HELO expectations, no published bulk thresholds.
• Proton Mail (encrypted, Switzerland) - in-house ML filtering, aggressive outbound abuse control, custom-domain SPF/DKIM/DMARC guidance, limited sender tooling by design.

The through-line is the same everywhere: authenticate, keep reverse DNS and HELO correct, get consent, honor unsubscribes, and keep complaints low. Meet the strict bar once and you clear nearly all of them.

What Egressif does

We operate the parts of this table that are infrastructure, on owned sending infrastructure rather than shared pools. SPF and DKIM are published and aligned on your domain, DMARC is published and watched, and one-click unsubscribe (RFC 8058) is implemented on every bulk stream - which clears the strict bar at Gmail and Yahoo and harms nothing at Microsoft or Apple. We keep valid, meaningful reverse DNS on the sending IPs and require TLS in transit. We monitor complaint signals where the providers expose them (Google Postmaster Tools, Yahoo’s Complaint Feedback Loop) so a rising spam rate surfaces as something we act on before it crosses Gmail’s 0.30% line, not after. What we do not do is promise inbox placement: these rules are the entry requirements, and reputation, content, and recipient engagement still decide where the mail lands.