Yahoo and Gmail's February 2024 Bulk Sender Requirements: A Compliance Checklist

The complete compliance checklist for Yahoo and Gmail's February 2024 bulk sender requirements. Authentication, unsubscribe, complaint rates—what you actually need.

What Actually Changed (And Why Now)

In October 2023, Google and Yahoo announced coordinated sender requirements taking effect February 1, 2024. The framing in industry press was "new rules," but that is misleading. Almost nothing in these requirements is new. SPF dates back to 2006. DKIM to 2011. DMARC to 2015. RFC 8058 (one-click unsubscribe) was published in 2018.

What changed is enforcement. For roughly a decade, mailbox providers treated authentication as a recommendation. Senders without DMARC could still reach the inbox if their reputation was clean. That era is over.

The trigger was AI-generated phishing. Throughout 2023, both Google and Yahoo saw measurable spikes in spoofed mail that bypassed legacy filtering because senders including legitimate ones had not enforced DMARC. The new requirements are the cheapest way to raise the floor: force every bulk sender to authenticate properly, give recipients a working unsubscribe, and punish senders whose mail users actively reject.

If you are reading this in January 2024, you have roughly two weeks. Most of these fixes are achievable in that window. A few are not, and I will flag those explicitly.

Who This Applies To

The requirements apply to any sender delivering more than 5,000 messages per day to Gmail or Yahoo addresses. That threshold is per-provider, not aggregate. If you send 4,000/day to Gmail and 4,000/day to Yahoo, you are below the threshold for both but only just.

Three things to know about that 5,000 number:

1. It is a rolling daily count, not a calendar threshold. A campaign blast that pushes you to 50,000 messages on a single Tuesday triggers the requirements, even if your monthly average is lower.
2. Subdomains count toward the parent domain. If marketing.yourbrand.com and transactional.yourbrand.com each send 3,000/day, the parent yourbrand.com is treated as a 6,000/day sender.
3. Once you cross the threshold, you are a bulk sender for filtering purposes going forward. Dropping below 5,000/day after the fact does not undo your classification immediately.

If you are below the threshold, the requirements technically do not apply. But filtering algorithms increasingly use them as quality signals regardless. Implement them anyway. The cost is negligible. The risk of not doing so is not.

The Three Requirements, Ranked by Difficulty

I have implemented these for dozens of senders. The order below reflects how long each fix actually takes in production. Start at the top.

1. Spam Complaint Rate Below 0.3% (Real Target: 0.1%)

This is the requirement that cannot be fixed in a sprint. If your current complaint rate is 0.5%, you cannot solve that with a checklist. You solve it by removing the segments of your list that are complaining.

What "complaint rate" means here:

Google calculates complaint rate as the percentage of your delivered Gmail messages marked as spam by recipients, measured over a rolling window in Google Postmaster Tools. Yahoo uses a similar calculation visible through their Complaint Feedback Loop.

The published threshold is 0.3%. The threshold that matters in practice is 0.1%. Here is why: at 0.3%, you are already being throttled. By the time Postmaster Tools shows you in the red zone, your inbox placement has been degrading for days. The senders who reliably reach the inbox keep their complaint rate at or below 0.1% as a steady state.

How to get there:

• Suppress unengaged subscribers aggressively. Anyone who has not opened or clicked in 90 days is dead weight. Anyone past 180 days is a complaint risk. Sunset them.
• Stop importing purchased or scraped lists. This is the single biggest driver of complaint rate problems I see in customer escalations. Even if the list "consented" technically, the recipients did not consent to you.
• Audit your re-engagement campaigns. "We miss you!" sent to people who unsubscribed in spirit five months ago is a complaint magnet. If a re-engagement series has a complaint rate above 0.5%, kill it.
• Separate transactional and marketing streams onto different subdomains. Complaints on marketing should not contaminate transactional reputation. (See: Sending from Subdomains.)

This is the requirement that will take you weeks, not days. Start now.

2. RFC 8058 One-Click Unsubscribe

This is medium difficulty. Most ESPs have it built in. The trap is that "supporting it" and "implementing it correctly" are different things.

What RFC 8058 actually requires:

Two headers must be present on every bulk message:

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

When a recipient clicks the unsubscribe link in Gmail's UI, Gmail sends a POST request to that URL with the body List-Unsubscribe=One-Click. Your endpoint must:

1. Process the unsubscribe without requiring authentication, login, or a confirmation page.
2. Respond within a few seconds.
3. Honor the unsubscribe within 2 days (Yahoo/Gmail spec; in practice, do it immediately).

The five mistakes I see most often:

1. Endpoint requires a session cookie. Gmail's POST has none. The unsubscribe silently fails.
2. Endpoint redirects to a confirmation page. RFC 8058 explicitly forbids this. The POST must complete the unsubscribe, full stop.
3. mailto: address bounces. The header has two values. Both must work. If your unsubscribe@ address is unmonitored, it counts as broken.
4. Honoring delay exceeds 2 days. I have seen ESPs queue unsubscribes for batch processing every 72 hours. That is non-compliant.
5. The link in the email body is treated as primary, the header as optional. Gmail uses the header. If your header URL points to a different endpoint than the body link, and that endpoint is broken, you fail compliance even if the body link works.

Test your implementation by sending yourself a campaign to a Gmail address, viewing the message source, copying the List-Unsubscribe URL, and curling it with -X POST -d "List-Unsubscribe=One-Click". The response should be 200 OK. The address should be unsubscribed within seconds. If either fails, you have work to do.

3. Authentication: SPF + DKIM + DMARC with Alignment

This is the easiest of the three to fix technically, but the most likely to break things if done wrong.

The minimum requirement:

• Valid SPF record covering all your sending IPs
• Valid DKIM signature on every outgoing message
• Published DMARC record with at least p=none
• Alignment between the From-domain and at least one of SPF or DKIM

That last point is what most senders miss. DMARC does not just check that SPF and DKIM pass. It checks that they pass for the domain in your visible From address.

What alignment failure looks like:

You send from newsletter@yourbrand.com. Your ESP sends through mail.espprovider.com. SPF passes but for espprovider.com, not yourbrand.com. DKIM is signed with the ESP's domain key. The result: SPF passes, DKIM passes, DMARC fails. The message is treated as unauthenticated.

How to fix it:

1. For SPF alignment: Configure your ESP to use a custom Return-Path on your domain (e.g., bounce.yourbrand.com). This brings the SPF check in line with your visible From-domain.
2. For DKIM alignment: Have your ESP sign with a selector under your domain (s1._domainkey.yourbrand.com). Most enterprise ESP plans support this; lower-tier plans may not.
3. For DMARC: Publish a record at _dmarc.yourbrand.com:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourbrand.com; pct=100

p=none is sufficient to satisfy Yahoo and Gmail's requirement. Do not jump to p=quarantine or p=reject without monitoring first. I have watched senders take down their own production mail by going straight to enforcement on a domain that had untracked legitimate sources (HR systems, support tools, third-party invoicing platforms). The aggregate reports from rua= will surface those sources within 7-14 days. Then you can move to enforcement safely.

For a deeper walkthrough, see Understanding DMARC Policies: From p=none to p=reject Without Breaking Things.

A Compliance Checklist You Can Actually Use

Print this. Work through it. Each item is binary either you have it or you do not.

If every box is checked, you are compliant. If any box is unchecked on February 1, you are not and your mail will start failing.

What Happens If You Are Not Ready

Failure is not all-or-nothing. The enforcement model is graduated:

• Bulk mail without authentication: Outright rejected at SMTP. You will see hard bounces.
• Authentication present but no DMARC: Routed to spam.
• DMARC present but alignment fails intermittently: Inconsistent placement. Some users see it in inbox, others in spam.
• Authentication clean but complaint rate above 0.3%: Throttled. Your sending capacity drops, often without any error message you just deliver less.
• Unsubscribe not RFC 8058 compliant: No immediate filtering impact, but Gmail removes the unsubscribe button from its UI for your messages, which raises complaint rate, which leads to throttling.

The senders who get hurt worst are not the ones who are completely non-compliant. They are the ones who are 90% compliant and assume they are fine. A misaligned DKIM signature on a domain with otherwise clean authentication produces inconsistent behavior that is harder to diagnose than total failure.

If you are working through this checklist and hitting a wall on any specific item, the related deep-dives in this series cover each in detail: DMARC Policies, DKIM Key Rotation, Subdomain Strategy, Postmaster Tools and SNDS, and Engagement-Based List Hygiene.

The deadline is not flexible. The fixes are.