Gmail & Yahoo Bulk Sender Requirements (2024+): What You Need to Comply

Background: what changed in 2024

In October 2023 Google and Yahoo jointly announced new requirements for anyone sending large volumes of email to their users. Enforcement began on February 1, 2024, with a graduated rollout: non-compliant bulk mail first hit a temporary error code, then started being rate-limited, then rejected outright. By mid-2024 enforcement was essentially universal at both providers.

The headline rules:

1. Authenticate every message with both SPF and DKIM.
2. Publish a DMARC record (at minimum p=none), and the From domain must align with SPF or DKIM.
3. Provide one-click List-Unsubscribe on marketing messages (RFC 8058 + RFC 2369).
4. Keep spam complaint rate below 0.3% (ideally below 0.1%).
5. Send only over TLS with valid forward and reverse DNS.

Microsoft followed with a similar policy in 2025 for Outlook.com / Hotmail mailboxes, and Apple's iCloud uses comparable thresholds. In practice, "Gmail and Yahoo compliant" has become the de facto baseline for B2C deliverability worldwide.

Who counts as a "bulk sender"

Google defines a bulk sender as a domain (or IP) that sends more than 5,000 messages to personal Gmail addresses in a single day. Yahoo uses a similar threshold. Important details:

• The 5,000 threshold is per day, not per month or per campaign.
• It's measured at the Gmail/Yahoo receiver, not at your MTA. If you send 4,000 to Gmail and 4,000 to Yahoo, you're under threshold at each — but a single 6,000-recipient Gmail blast lights up the rules.
• The threshold is per sending domain. Sending from news.example.com and billing.example.com counts separately at the subdomain level, but Google may still treat both as "example.com" for reputation purposes.
• Personal Gmail (@gmail.com) and Google Workspace accounts both count.

If you cross the threshold once, Google's heuristics increase scrutiny for some time afterwards. Senders who hover near the line are best off complying anyway — the requirements are good practice regardless of volume.

Requirement 1: SPF and DKIM on every message

Every message must carry both SPF and DKIM authentication. Before 2024, providers tolerated SPF-only or DKIM-only setups; that's over.

SPF

• The Return-Path / envelope-sender domain (often called "MAIL FROM") must publish a valid SPF record.
• The record must list the sending IP(s).
• Use a real failure qualifier — ~all or -all. Never +all.
• Stay under the 10-DNS-lookup limit (see our SPF guide).

Example for a domain sending through Google Workspace plus a transactional provider:

example.com. IN TXT "v=spf1 include:_spf.google.com include:spf.postmarkapp.com -all"

DKIM

• Every outgoing message must include at least one valid DKIM-Signature.
• The signing key should be at least 1024 bits. Google recommends 2048. Keys below 1024 bits are rejected outright as weak.
• The signing domain (d=) should be your domain — not the vendor's — so it aligns with the From header for DMARC.

If you use multiple sending platforms, each gets its own DKIM selector under your domain. See our DKIM guide for the deep-dive on selectors and rotation.

Requirement 2: DMARC with alignment

The 2024 rules require a published DMARC record. The minimum acceptable policy is p=none:

_dmarc.example.com. IN TXT "v=DMARC1; p=none; rua=mailto:reports@example.com"

That bare-minimum record satisfies the rule technically, but Gmail explicitly recommends moving to p=quarantine or p=reject as soon as your reports show legitimate mail is passing. Domains stuck on p=none long-term will start being deprioritized in inbox placement.

The critical detail most senders miss: DMARC requires alignment, not just SPF or DKIM passing. A message can pass SPF (the envelope sender's domain has a valid SPF record covering the sending IP) and still fail DMARC if that envelope-sender domain doesn't match the From header.

Example failure:

From: marketing@example.com
Return-Path: bounce@email-provider.com   ← SPF checked against this
DKIM-Signature: d=email-provider.com     ← DKIM signed by this

SPF passes (the provider's IP is in their record), DKIM passes (their key verifies), but nothing aligns with example.com, so DMARC fails. The fix is to ask the provider to sign with d=example.com (DKIM alignment) or to use a custom Return-Path under your domain (SPF alignment). To work toward strong DMARC enforcement, follow the staged rollout in our migration guide.

Requirement 3: One-click List-Unsubscribe

All marketing messages must include two headers that together implement RFC 8058 one-click unsubscribe:

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

The behaviour spec:

1. When a recipient clicks "unsubscribe" in Gmail/Yahoo, the mail client sends an HTTP POST with body List-Unsubscribe=One-Click to the URL.
2. Your endpoint must accept the POST, unsubscribe the user immediately, and return a 2xx response — without requiring login, captcha, or any further confirmation.
3. The unsubscribe must take effect within two days of the click (Gmail's stated requirement, but plan for immediate).

Common implementation mistakes:

• Requiring the user to log in to confirm — not allowed.
• Returning a 302 redirect to a "confirm your unsubscribe" page — not allowed.
• Including only the mailto: form without the HTTPS one — will work, but loses the one-click UX.
• Tokenless URLs (?email=user@example.com) — enables enumeration. Use opaque, signed tokens.

The header is not required on transactional mail (password resets, order confirmations) but it doesn't hurt to include it.

Requirement 4: Complaint rate under 0.3%

Both Google and Yahoo enforce a hard ceiling: keep your user-reported spam rate below 0.3%, measured over a rolling window. Google publishes this in Postmaster Tools. Above 0.3% your mail is throttled; sustained, it's rejected.

The recommended ceiling is much tighter: under 0.1%. That's one spam complaint per 1,000 delivered messages. Healthy senders sit at 0.01–0.05%.

Concretely, for 100,000 Gmail recipients per day:

• ≤ 100 complaints → healthy
• 100–300 complaints → warning territory; expect inbox-placement degradation
• ≥ 300 complaints → you'll hit the hard threshold; throttling begins

What drives complaint rate up:

• Re-engaging cold or purchased lists.
• Missing or hidden unsubscribe.
• Misleading From names ("Customer Support" instead of your brand).
• Frequency — daily marketing emails get reported more than weekly.
• Content that triggers "this isn't what I signed up for" — e.g. subscribing for newsletters and receiving sales pitches.

If you're approaching the threshold, the first response should always be list hygiene: sunset unengaged contacts, double-opt-in new ones, and audit your unsubscribe flow. There's no DNS fix for a complaint problem.

Other requirements: TLS, reverse DNS, message format

The 2024 rules also tighten several long-standing best practices into hard requirements:

• TLS for SMTP delivery. Connections to Gmail/Yahoo MX servers must negotiate TLS. Any modern MTA does this by default; the failure mode is using an ancient SMTP relay.
• Valid forward and reverse DNS. The sending IP must have a PTR record, and the PTR's hostname must resolve back to the same IP. Mismatched or missing PTR is a fast track to rejection.
• RFC 5322 compliant messages. A single From header with a single mailbox, proper Date, Message-ID, etc. Malformed messages are dropped.
• Don't impersonate Gmail/Yahoo in the From. Sending with From: noreply@gmail.com from your own infrastructure has always been a deliverability disaster; the 2024 rules make it an explicit ban.

Transactional vs marketing: what differs

The bulk-sender rules apply to all messages above the 5,000/day threshold, but the List-Unsubscribe requirement is specifically for marketing/promotional messages. Transactional mail (password resets, receipts, shipping notifications) is exempt from the unsubscribe rule.

Practical separation patterns:

1. Separate subdomains. Send transactional from mail.example.com and marketing from news.example.com. Each has its own DKIM key and reputation. A spam complaint on marketing doesn't poison password resets.
2. Separate IP pools. If your volume justifies dedicated IPs, marketing and transactional should be on different ones for the same reputation-isolation reason.
3. Same domain, different headers. If you must mix, at least include List-Unsubscribe on the marketing messages and not the transactional ones, and use clear From names (billing@ vs news@).