Gmail and Yahoo Bulk Sender Requirements in 2026. The Complete Checklist

Who counts as a bulk sender?

Google draws the line at about 5,000 messages to personal Gmail accounts in a single day, counted per sending domain — not per IP, not per recipient. Your transactional receipts and your Tuesday newsletter draw from the same budget. Yahoo frames it identically. Once you cross that threshold, even on one busy day, Gmail and Yahoo expect you to stay compliant from then on.

The honest advice: do all of this even if you send 500 a day. Authentication is free, and the requirements below are just "good email hygiene" written down. The only line a small sender can reasonably skip is the bulk-specific one-click unsubscribe header — and even that is trivial to add.

Authenticate everything: SPF, DKIM, and DMARC

The core of the bulk sender rules is authentication. You need all three records published and passing. Here is what each looks like in DNS:

; SPF — authorizes the servers allowed to send for you
example.com.            TXT   "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

; DKIM — the public key your provider signs with (selector "google" here)
google._domainkey.example.com.  TXT   "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0B..."

; DMARC — the policy that ties From alignment together
_dmarc.example.com.     TXT   "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

SPF must not exceed the 10-lookup limit or it returns PermError and effectively fails. DKIM must sign with a key of at least 1024 bits (2048 is the modern default); see our DKIM guide for selector and rotation strategy. DMARC only needs p=none to satisfy the requirement, but none is the floor — the DMARC ramp to quarantine and reject is where you actually stop spoofing.

Get DMARC alignment right

This is the step most senders trip over. Passing SPF or DKIM is not enough — the domain that authenticated has to align with the domain in the visible From: header. SPF aligns against the Return-Path (envelope sender); DKIM aligns against the d= tag in the signature.

The classic failure: you send from news@example.com, but your ESP sets the Return-Path to bounces@esp-vendor.net and signs DKIM with d=esp-vendor.net. Both checks "pass," yet neither aligns with example.com, so DMARC fails and Gmail treats the mail as unauthenticated. The fix is to configure a custom return-path/bounce subdomain and a branded DKIM signing domain at your provider, so at least one aligns with your From.

One-click unsubscribe

Promotional and marketing mail must carry both headers below, and you must honor the unsubscribe within two days:

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

The List-Unsubscribe-Post header (RFC 8058) is what makes it one-click: Gmail sends a single POST to your HTTPS URL when the user clicks the built-in unsubscribe link. No login screen, no confirmation page, no preference center. Transactional mail — receipts, password resets, shipping notices — is exempt, but the moment a stream mixes a promo banner into a receipt, treat the whole stream as promotional.

Keep spam complaints under 0.3%

The one requirement no DNS record can satisfy. Your spam complaint rate, as reported in Google Postmaster Tools, must stay below 0.3% — and you should aim for under 0.1%. A short spike is survivable; living above 0.3% gets your mail throttled or filed straight to spam regardless of perfect authentication.

This is driven by list quality and frequency, not configuration. Mail people who asked for it, make unsubscribe genuinely one click (see above), and prune chronically unengaged recipients. A clean list with boring auth beats a dirty list with perfect auth every time.

Valid PTR records and TLS

Two more requirements that are easy to forget because your provider usually handles them. Every IP you send from needs forward-confirmed reverse DNS: a PTR record whose hostname resolves back to the same IP.

# The PTR should return a real hostname...
dig -x 203.0.113.25 +short      ->  mail.example.com.

# ...and that hostname must resolve back to the same IP (FCrDNS)
dig +short mail.example.com     ->  203.0.113.25

See our reverse DNS guide for setting PTR with your host. You must also transmit over TLS and format messages to RFC 5322 — and never spoof a gmail.com From address, which Gmail now rejects outright. If you use a major ESP on dedicated or shared IPs, PTR and TLS are typically already correct; verify rather than assume.

The full checklist at a glance

• SPF published, under 10 lookups, not +all — maps to our SPF check.
• DKIM signing with an aligned domain, 1024-bit key or larger — DKIM check.
• DMARC at minimum p=none with rua reporting, and dmarc=pass alignment — DMARC analyzer.
• One-click unsubscribe headers on promotional mail, honored within two days.
• Spam rate under 0.3% in Postmaster Tools (target 0.1%).
• Valid PTR / FCrDNS on every sending IP — rDNS check.
• TLS in transit, RFC 5322 formatting, no gmail.com From spoofing.

Staying compliant after launch

Setting these records up once is the easy part. The trap in 2026 is drift: a DKIM key gets rotated and the new selector is never published, an SPF include changes IPs under you, a DMARC record gets clobbered by a registrar migration, or a PTR vanishes when you move IPs. Any one of those quietly breaks alignment, and because enforcement is now hard rejection rather than a temporary error, you find out from bounced revenue rather than a warning.

DomainsDoc watches the whole chain continuously — SPF lookup count, DKIM selector presence, DMARC policy and alignment, blacklist status, and reverse DNS — and alerts you the moment a bulk sender requirement slips, instead of when Gmail starts deferring your mail. Run a free check on your domain to see where you stand, and see pricing for continuous monitoring.