Bulk sender rules: Google, Yahoo and Microsoft

Three mailbox providers now publish enforceable sender requirements, and they disagree in ways that matter. Google publishes a threshold — close to 5,000 messages a day to personal Gmail. Yahoo refuses to publish a number at all. Microsoft counts 5,000 messages to its consumer domains from one From: domain. Every requirement below traces to the vendor page that states it.

What changed in 2024 and 2025?

Google and Yahoo moved together. Google’s Email sender guidelines say the requirements apply "Starting February 1, 2024". Yahoo’s Sender Requirements page says "Beginning in February 2024, enforcement of the following sending standards will take effect", rolled out gradually through that half-year. Both set a second date for one-click unsubscribe: Google told senders that already included an unsubscribe link they had "until June 1, 2024 to implement one-click unsubscribe in all commercial, promotional messages", and Yahoo’s FAQ says enforcement of it "will begin in June 2024".

Microsoft followed a year later. The announcement went up on the Microsoft Defender for Office 365 blog on 2 April 2025, covering "Outlook.com - our consumer service, which is supporting hotmail.com live.com and outlook.com consumer domain addresses". It set enforcement for 5 May 2025 and requires SPF, DKIM and DMARC from "domains sending more than 5,000 emails per day".

Which requirement applies to which sender?

This is where most write-ups go wrong: they flatten three policies into one checklist and attach Google’s 5,000 threshold to all of it. Here is what each provider’s own page says.

Who counts as a bulk sender?

Google is the only one of the three that publishes a number, and it is both hedged and narrower than the headline suggests. From the Email sender guidelines FAQ: "A bulk sender is any email sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period." Not 5,000 to everyone — 5,000 to addresses ending @gmail.com or @googlemail.com.

Two details in that FAQ do most of the damage. First, subdomains get no budget of their own: "When we calculate the 5,000-message limit, we count all messages sent from the same primary domain." Google’s worked example is 2,500 a day from a root domain plus 2,500 from a subdomain of it. Second, the status does not decay — "Senders who meet the above criteria at least once are permanently considered bulk senders", and "Changes in email sending practices will not affect permanent bulk sender status once it’s assigned."

Yahoo deliberately declines to give you a number. Its FAQ: "A ‘bulk’ sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold." It also tells you the unit of assessment — "for the purposes of enforcement, a ‘sender’ is viewed at the authenticated domain or From header domain level" — and that spoofed mail claiming your domain counts toward the volume Yahoo looks at. Anyone quoting "Yahoo: 5,000 a day" is quoting Google.

Microsoft states its threshold twice, differently. The blog says "domains sending more than 5,000 emails per day". The support article for the resulting bounce defines a high-volume sender as one where "You send 5,000 or more email messages to Microsoft consumer email services" using "the same domain in the 5322.From address" — no per-day qualifier — then adds "After you reach this threshold, we expect all messages from senders in the domain" to authenticate. Assume crossing the line is a one-way door.

What must a low-volume sender do?

Google’s all-senders list is six items: SPF or DKIM on the sending domain; valid forward and reverse DNS for the sending domain or IP; TLS for transmission; spam rates in Postmaster Tools below 0.3%; RFC 5322 formatting; and no impersonation of Gmail From: headers. Yahoo’s all-senders list is four: SPF or DKIM at a minimum; spam rate below 0.3%; valid forward and reverse DNS for sending IPs; and compliance with RFC 5321 and RFC 5322. Microsoft publishes no requirement below its threshold, only the observation that "all senders benefit from these best practices".

Either SPF or DKIM satisfies the letter of the rule at that tier, but the bulk tier at both providers wants SPF and DKIM together plus DMARC — so anything you set up now is work you will not repeat. Google adds one hard constraint on the key: "Sending to personal Gmail accounts requires a DKIM key of 1024 bits or longer", with 2048 recommended.

The reverse-DNS requirement is the one most often misread. Google spells out that it means forward-confirmed reverse DNS, not merely a PTR: the sending IP needs a PTR resolving to a hostname, and that hostname needs an A or AAAA record resolving back to the same IP. "The sending IP address must match the IP address of the hostname specified in the Pointer (PTR) record." Two commands prove it.

$ dig +short -x 209.85.220.41
mail-sor-f41.google.com.

$ dig +short mail-sor-f41.google.com
209.85.220.41

$ dig +short -x 40.107.236.41
mail-bn8nam11on2041.outbound.protection.outlook.com.

$ dig +short mail-bn8nam11on2041.outbound.protection.outlook.com
40.107.236.41

$ dig +short TXT _dmarc.yahoo.com
"v=DMARC1; p=reject; pct=100; rua=mailto:d@rua.agari.com; ruf=mailto:d@ruf.agari.com;"

The PTR resolves to a hostname; the hostname resolves back to the IP you started with. That round trip is the check. Send through Microsoft 365 or Google Workspace and the sending IP is theirs, so the PTR record and the TLS connection are theirs to get right — which is why the second pair of lookups above round-trips as cleanly as the first. What stays yours is SPF, DKIM, DMARC, alignment, unsubscribe handling and complaint rate.

What is the spam complaint rate measured against?

Two numbers, and they are not the same number. Google’s requirement is "below 0.3%". Google’s recommendation, on the same page, is stricter: "Keep spam rates reported in Postmaster Tools below 0.10% and avoid ever reaching a spam rate of 0.30% or higher." The FAQ makes the consequence explicit: "Beginning June 2024, bulk senders with a user-reported spam rate greater than 0.3% will be ineligible for mitigation", and eligibility returns only "when their spam rates remain below 0.3% for 7 consecutive days".

The denominator is the part people get wrong. Google defines the rate as "the percent of your messages that are delivered to engaged recipient’s Inbox and then marked as spam by the recipient", and says Postmaster Tools "displays the spam rate of DKIM-authenticated messages". The denominator is inbox-delivered, DKIM-signed mail — not mail you sent. Google flags the perverse consequence: "If Gmail automatically sends a significant number of your messages to spam, the rate shown in the dashboard might seem low, because recipients get fewer of your messages in their Inbox." A falling spam rate can mean your mail stopped arriving.

Yahoo measures the same way: "Spam rate is calculated in our system based on mail delivered to the inbox." It exposes complaints through its Complaint Feedback Loop, which keys off your DKIM signature: "Once you sign your emails with DKIM, our CFL program can help you track and manage your spam complaint rates." Microsoft publishes no threshold, only that it "reserves the right to take negative action … against non-compliant senders".

The arithmetic is unforgiving at small scale. 0.30% is three complaints per thousand inbox-delivered messages. A sender doing 40 messages a day has no statistical cushion: even if every message reached an inbox, one complaint in a week is about 0.36% of that week’s volume — already over the line. The thresholds were written for senders whose volume smooths the noise, and low-volume senders are judged by domain and IP reputation signals that Postmaster Tools may not even populate for them.

What does one-click unsubscribe actually require?

RFC 8058 is the specification. It requires two header fields on the message: a List-Unsubscribe field that "MUST contain one HTTPS URI", and a List-Unsubscribe-Post field containing the single key/value pair List-Unsubscribe=One-Click. The mail client performs an HTTPS POST to that URI with the pair as the body. Two further requirements are easy to miss, and both are MUSTs: the message "MUST have a valid DomainKeys Identified Mail (DKIM) signature that covers at least the List-Unsubscribe and List-Unsubscribe-Post headers", and the sender "MUST NOT return an HTTPS redirect" from that URI, because browsers have historically turned redirected POSTs into GETs. Nothing in RFC 8058 sets a deadline for processing the request — that comes from the providers.

Google accepts no substitutes. From its FAQ: "Including a mailto link in the body of your messages doesn’t meet our one-click unsubscribe requirement", and if the header is missing it will not look in the body for one instead. A visible body link is separately required, but it does not stand in for the headers. Only marketing and promotional mail is covered: "Transactional messages are excluded from this requirement", with password resets and reservation confirmations given as examples.

Yahoo is looser on mechanism and stricter on timing. It requires a "functioning list-unsubscribe header, which supports one-click unsubscribe for marketing and subscribed messages", where "The Post (RFC 8058) method is highly recommended" but "The mail-to: method is acceptable". Then: "Honor unsubscribes within 2 days" — "If the unsubscribe is not honored in 2 days, then it would not meet the requirement." So mailto: passes at Yahoo and fails at Google. Implement RFC 8058 and both are satisfied.

Google’s two-day rule is worded as advice — "we recommend that you fulfill unsubscribe requests within 48 hours" — but its enforcement table lists "Unsubscribe requests aren’t honored within 48 hours" as a sender requirement issue with the consequence "Delivery support or mitigations unavailable". Advice with a penalty attached is a requirement. Microsoft asks only for "Functional Unsubscribe Links" under recommendations, not under the three enforced authentication requirements.

US law sets its own clock, separately from provider policy. The FTC’s CAN-SPAM compliance guide says an opt-out mechanism "must be able to process opt-out requests for at least 30 days after you send your message", that "You must honor a recipient’s opt-out request within 10 business days", and that messages must carry "your valid physical postal address". The guide currently puts the maximum civil penalty at $53,088 per offending email, adjusted for inflation.

Do these rules apply to B2B mail?

Mostly not, as written. Google states it directly: "The Email sender guidelines don’t apply to messages sent to Google Workspace accounts. Sender requirements and Google enforcement apply only when sending email to personal Gmail accounts." Microsoft’s rules are scoped to its consumer services — Outlook.com, Hotmail, Live.com, MSN — and neither Microsoft page extends them to Exchange Online tenants. A campaign aimed only at corporate mailboxes may never touch either policy.

That is a scoping fact, not a licence. Mail sent from a Google Workspace account to a personal Gmail address is still covered: "All senders, including Google Workspace users, must meet the requirements … when sending messages to personal Gmail accounts." B2B lists are rarely as clean as they look. And Exchange Online Protection and Workspace filtering evaluate authentication and complaint history whether or not a published threshold names them.

Which error code maps to which broken rule?

Both Google and Microsoft return machine-readable reasons. A 4.x.x is temporary and usually means rate limiting; a 5.x.x is a rejection.

550 5.7.515 Access denied, sending domain <domain> does not meet the required authentication level. The sender’s domain in the 5322.From address doesn’t meet the authentication requirements defined for the sender.

Microsoft, Fix NDR error 550 5.7.515 in Outlook.com

What does this mean if you send 40 emails a day?

You are below every published bulk threshold, so none of the bulk-tier obligations bind you as written. That is accurate and nearly useless, because what does bind you at 40 a day is invisible: domain reputation, complaint history, engagement. Postmaster Tools may show you nothing at that volume — Google says the dashboards "might not include all data on days when your outgoing email volume is low".

So meet the bulk requirements anyway. SPF and DKIM both passing, DMARC at p=none with an rua address, a From: domain aligned with one of them, RFC 8058 headers on anything promotional, a visible unsubscribe link, a physical postal address, and removal within two days. None of it costs anything at low volume, and all of it is required the first day you cross a threshold — which, per Google, you can only do once.

Decknative sends through the customer’s own connected Microsoft 365 or Gmail mailbox rather than a shared ESP, so the sending IP, its PTR record and the TLS connection belong to Microsoft or Google. That is a statement about where the SMTP conversation happens, not a claim about deliverability. The domain-level work — SPF, DKIM, DMARC, alignment, unsubscribe plumbing — still sits with whoever administers the domain.

One caution about the thresholds. Yahoo says its requirements "are subject to change", Microsoft says the date for its next enforcement stage is "to be announced", and Google’s FAQ now warns that "Starting November 2025, Gmail is ramping up its enforcement on non-compliant traffic", with "temporary and permanent rejections". Check the vendor pages below rather than trusting any summary, this one included.