Gmail and Yahoo's bulk sender rules, in plain English
What Gmail and Yahoo have required of bulk senders since February 2024, what breaks if you miss a rule, and how to check your own setup.
Carrier Crow · · 6 min read
In February 2024, Gmail and Yahoo stopped treating good sending practice as optional. Authentication, an easy way out, a ceiling on complaints: most of it had been advice for years. What changed is enforcement. It was phased in rather than switched on overnight, but the phase-in is long over, and a newsletter that misses the bar now risks being deferred, filtered or rejected.
Here is what the rules ask for, what each one means, and how to check yours.
Who counts as a bulk sender
Google defines a bulk sender as anyone sending close to 5,000 messages or more to personal Gmail accounts in a 24-hour period, counting everything sent from the same primary domain. Google has also said that once you cross that line, you're treated as a bulk sender from then on. One big issue is enough.
Yahoo announced matching requirements at the same time, and Microsoft has since set out similar authentication rules for high-volume senders to Outlook.com, Hotmail and Live addresses. If you're anywhere near 5,000 a day to Gmail, meet the bulk requirements everywhere.
Some rules apply to every sender, however small; others only to bulk senders:
| Requirement | Who it applies to | How to check |
|---|---|---|
| SPF and DKIM | Everyone needs one; bulk senders need both | DNS, and a received message |
A DMARC record, p=none or stricter | Bulk senders | DNS |
| From domain aligned with SPF or DKIM | Bulk senders | The DMARC result on a received message |
| One-click unsubscribe, honoured within two days | Bulk senders, for marketing and subscribed mail | Message headers |
| Spam rate below 0.3% | Everyone | Google Postmaster Tools |
| Forward and reverse DNS for sending IPs | Everyone | A reverse lookup on the IP |
| TLS | Everyone (Google) | Message details in Gmail |
SPF and DKIM: proving the mail is yours
SPF is a DNS record on your domain listing the servers allowed to send mail for it. A receiving server takes the domain from the envelope sender (the hidden return address that bounces go to, not the From line readers see) and checks whether the connecting server is on the list. Two classic mistakes: publishing more than one SPF record, which counts as an error rather than a merge, and chaining so many include: entries that you pass SPF's limit of ten DNS lookups. Either makes SPF fail while the record looks fine at a glance.
DKIM is a cryptographic signature the sending server adds to each message. The matching public key lives in DNS under a selector you or your provider choose, at an address like s1._domainkey.example.com. Because the signature travels inside the message, DKIM survives forwarding in a way SPF doesn't.
Miss both and Gmail has little reason to believe the mail is from you. For a bulk sender, having only one is itself out of compliance.
DMARC, and the alignment trap
DMARC is a TXT record at _dmarc.example.com telling receivers what to do with mail that claims to be from your domain but fails authentication, and where to send reports. The minimum the rules ask for is a monitoring-only policy:
v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com
p=none means "don't act on failures, just tell me about them". It's a starting point: the aggregate reports it produces show every service sending as your domain, which is how you find out when it's safe to move to quarantine or reject.
The part that catches people out is alignment. DMARC passes only if the domain in your visible From address matches the domain that passed SPF, or the domain that signed with DKIM. By default a match at the organisational level is enough, so news.example.com aligns with example.com. The trap: unless you've set up domain authentication, many providers sign with their own DKIM domain and use their own bounce domain. SPF passes, DKIM passes, and DMARC still fails, because neither passing domain is yours. Your provider's domain authentication setup fixes it by making it sign and bounce as you.
One-click unsubscribe
Bulk senders must let people unsubscribe from marketing and subscribed mail (newsletters included) in one click, and must honour the request within two days. Google also wants a clearly visible unsubscribe link in the body of the message; the header doesn't replace it.
"One click" has a specific technical meaning, set out in RFC 8058. Each message carries two headers:
List-Unsubscribe: <https://example.com/unsubscribe/abc123>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
When a reader uses the unsubscribe option Gmail or Yahoo shows beside your name, the mailbox provider sends an HTTPS POST to that address and your system unsubscribes them. No login, no confirmation page. It's a POST rather than a simple visit because security software follows links on its own, and nobody should be unsubscribed by a scanner. The standard also requires both headers to be covered by the message's DKIM signature.
Miss this and, compliance aside, readers who can't find the way out use the one button that's always there: "Report spam". Which brings us to the number that matters most.
Keep spam complaints below 0.3%
Google wants the spam rate shown in its Postmaster Tools kept below 0.3%, and recommends staying under 0.1%. Yahoo uses the same 0.3% line. Google measures the rate against mail that reached the inbox, so 0.3% is three complaints for every thousand messages delivered there. On 20,000 Gmail inbox deliveries, that's 60 people.
Over the line, more of your mail goes to spam, and Google has said senders above it lose eligibility for its mitigation help until the rate comes back down. Postmaster Tools is free: you verify your domain with a DNS record, though it only shows data once you send enough mail to Gmail each day. Yahoo offers a complaint feedback loop through its Sender Hub.
The levers are unglamorous: confirm signups, make leaving easy, stop mailing people who never open.
The plumbing: reverse DNS and TLS
Every IP address you send from needs forward and reverse DNS: a PTR record mapping the IP to a hostname, and that hostname resolving back to the same IP. Send through SendGrid, Mailgun, Postmark or Amazon SES on their shared IPs and the provider handles this. Run your own mail server and it's on you.
Google also requires mail to arrive over TLS. Mainstream providers do this by default. In Gmail, a message's details read "Standard encryption (TLS)"; mail that arrived without it gets a red open padlock.
How to check where you stand
Two checks cover most of it.
First, the DNS: SPF, DMARC, your DKIM key at its selector, and MX. MX isn't on Google's list, but replies and bounces need somewhere to go, and some receiving servers turn away mail whose return-address domain can't receive any. The sender check looks up all four for a domain in one go.
Second, a real message. Send an issue to a Gmail address, open it and choose "Show original". The summary at the top shows SPF, DKIM and DMARC each as PASS or FAIL. DNS tells you the records exist; only a received message tells you they line up. If DMARC says PASS, alignment is working, and the raw headers underneath show whether both unsubscribe headers made it through.
Where Carrier Crow fits
Carrier Crow isn't an email service provider. It connects to the SMTP provider you already use (SendGrid, Mailgun, Postmark, Amazon SES or any SMTP relay), so SPF, DKIM, DMARC and reverse DNS stay with your domain and your provider. The part that lives inside the message, it handles: every campaign carries the one-click List-Unsubscribe headers, whichever provider sends it.
Try it
Put your sending domain into the sender check. It runs the SPF, DKIM, DMARC and MX lookups for you, which beats reading TXT records by hand before the next issue goes out.
Free tool
Bulk sender check
Check a sending domain’s SPF, DKIM, DMARC and MX records against the authentication rules Gmail and Yahoo enforce for bulk senders — with a plain-English fix for anything missing.