Gmail and Yahoo sender requirements: what you actually need to do
To meet Gmail and Yahoo's bulk sender requirements, you need three things: authenticated email (SPF and DKIM, with a published DMARC policy), one-click unsubscribe headers on marketing mail, and a spam-complaint rate below 0.3%. Miss any of them and your delivery rates drop, sometimes without a clear bounce message to tell you why.
Google's official documentation covers every edge case for large enterprises. This post covers what a small SaaS team or indie developer actually needs to do, in order, without the enterprise filler.
Who this applies to
Google's formal definition of a "bulk sender" is anyone sending more than 5,000 messages per day to Gmail addresses. That threshold is lower than most people think. If you run an app with a few thousand users and send weekly email, you're probably there.
Two details about the threshold catch people out. It counts messages to Gmail addresses specifically, not your total send volume, so 5,000 is the count of recipients on @gmail.com and Google Workspace domains, not your whole list. And it's a rolling judgment, not a one-time test: send over 5,000 to Gmail on any single day and Google treats you as a bulk sender from then on. You don't drop back out by sending less the next day.
But the requirements reflect best practice at any volume. Authenticating your email with SPF, DKIM, and DMARC protects your domain from spoofing whether you send 500 messages a day or 500,000. Keeping a low spam-complaint rate is good hygiene no matter who you are. The unsubscribe requirement is sensible regardless of enforcement status. Treat the bulk-sender rules as the floor everyone should clear, not a special regime that only applies once you cross a line.
One distinction that matters: transactional mail (receipts, password resets, alerts triggered by user actions) has different unsubscribe treatment than marketing mail (newsletters, campaigns, promotional sequences). Marketing mail requires one-click unsubscribe. Transactional mail does not, but it still has to be authenticated.
The three pillars
Google and Yahoo organize their rules into three pillars. Everything below maps to one of them:
- Authenticate your mail: SPF and DKIM, plus a published DMARC policy with alignment.
- Make unsubscribing easy: one-click unsubscribe headers on marketing mail, honored within two days.
- Send wanted mail: keep your spam-complaint rate low in Google Postmaster Tools.
The next sections break each pillar into the concrete records and headers you actually have to configure.
Pillar 1: Authenticate with SPF and DKIM (and align DMARC)
Authentication is not "pick one." Bulk senders must set up both SPF and DKIM, and publish a DMARC record on top of them. Below is each piece.
SPF
SPF (Sender Policy Framework) is a DNS TXT record at your root domain that lists the IP addresses and services allowed to send mail on your behalf. A receiving server checks the envelope sender against your SPF record and returns pass, fail, or neutral.
Your record looks something like:
v=spf1 include:_spf.google.com include:spf.mandrillapp.com -all
The include: mechanisms point to SPF records maintained by your ESPs. The -all at the end means everything else fails.
Two things trip people up. First, the 10-DNS-lookup limit: each include: counts as one lookup, and some of those includes have their own includes. Exceed 10 lookups and your SPF record is a permerror, which receivers treat as a fail. Second, if you add a new sending service without adding it to SPF, that service's mail will fail SPF alignment.
Use the SPF, DKIM, and DMARC checker to see your current record and whether it resolves within the lookup limit.
DKIM
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to every message you send. The receiving server fetches your public key from DNS and uses it to verify the signature, proving the message came from your domain and wasn't tampered with in transit.
To enable DKIM, you publish a TXT record at selector._domainkey.yourdomain.com containing your public key. Your ESP generates the keypair and tells you the selector name and public key to publish.
Minimum key length is 1024 bits; 2048-bit keys are recommended. If you have a 2048-bit key, it needs to be split across two strings in DNS. Use the DKIM record generator to format it correctly.
DKIM matters for a reason beyond authentication: it survives forwarding. SPF breaks when someone forwards your email to another address. DKIM doesn't, because it signs the message headers rather than the envelope. For any sending setup with forwarding in the chain, DKIM is the only reliable path to DMARC alignment.
DMARC
DMARC ties SPF and DKIM together. It introduces alignment: your SPF or DKIM results only "count" toward DMARC if the authenticated domain matches your From header domain. And it gives you the rua= address for aggregate reports so you can see what's actually happening.
Google requires a DMARC record to be published with a reporting address. The minimum that satisfies their requirement:
v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.com
p=none satisfies Google's technical requirement: the record must exist and the policy must be at least p=none, with at least one of SPF or DKIM passing in alignment with your From domain. But p=none means Google takes no action on failures, it's monitoring mode only. Your long-term target is p=reject, which actually prevents spoofing. The path there is p=none → p=quarantine → p=reject, moving only when your aggregate reports show sustained high alignment across all your sending sources. The DMARC enforcement roadmap covers each stage of that progression in detail.
The rua= reporting address is non-optional in practice. Without it, you're publishing a policy but flying blind. Reports are how you discover a sending service you forgot to authenticate before you tighten policy and start breaking legitimate mail. See the DMARC monitoring guide for what to actually do with them.
Check your domain against all of these requirements now: Gmail & Yahoo compliance checker →
Pillar 2: One-click unsubscribe
The one-click unsubscribe requirement applies to marketing mail only. It requires two specific email headers:
List-Unsubscribe: <https://yourapp.com/unsubscribe?token=...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click
The List-Unsubscribe-Post header is what makes it RFC 8058 compliant: it tells mail clients this is a real one-click action, not just a mailto link. When a recipient clicks the unsubscribe button rendered by Gmail, the mail client sends a POST request to your URL, and you must process that opt-out within two days. No login wall, no "manage preferences" maze, no confirmation email required to complete it.
The good news: most ESPs add these headers automatically. Mailchimp, Klaviyo, Postmark, SendGrid, and others handle it natively. Verify that your ESP is doing it and that you haven't disabled it in your campaign settings.
The header must be present in the email itself, which means this can't be verified from DNS. It has to be confirmed by checking a sent message. The compliance checker flags this as advisory. Send yourself a real campaign and inspect the raw headers (in Gmail, "Show original") to confirm both List-Unsubscribe and List-Unsubscribe-Post are present and the URL actually resolves.
Pillar 3: Keep your spam-complaint rate low
Google measures your spam-complaint rate through Google Postmaster Tools, the percentage of your delivered mail that recipients mark as spam. Google's published guidance is to stay under 0.3% at all times, and to aim for under 0.1%. The 0.1% figure is the level a healthy sender sits at; 0.3% is the ceiling where Google actively restricts your delivery. Briefly touching 0.3% won't necessarily get you blocked, but sustained complaint rates at or above it will.
This tool can't measure your complaint rate directly; only Google can. Sign up for Google Postmaster Tools (free), verify your domain there, and you get access to your spam rate, domain reputation, IP reputation, and authentication pass rates. Check it regularly, because the rate can spike after a single bad campaign, and it's a lagging signal, so by the time you notice it in your delivery numbers the damage is already done.
Keeping your list clean, only mailing people who opted in, honoring unsubscribes immediately, and sending mail people actually want are the main levers. Authentication helps signal legitimacy but doesn't fix a bad sender reputation. A properly authenticated message that recipients keep marking as spam will still get throttled.
Often-missed details
The three pillars are the headline. These are the things that quietly break compliance even when the headlines look green:
- Valid forward and reverse DNS (PTR records). Every IP you send from should have a PTR record (reverse DNS) that resolves to a hostname, and that hostname should resolve back to the same IP (forward-confirmed reverse DNS, or FCrDNS). If you send through an ESP, the ESP owns this and almost always gets it right. If you run your own mail server or a dedicated IP, missing or mismatched PTR is a common, silent reputation hit.
- TLS for transmission. Google requires that connections delivering mail to Gmail use a TLS connection. Any reputable ESP already enforces this. Self-hosted senders need to confirm their outbound MTA is configured for opportunistic (or enforced) TLS.
- ARC for forwarded mail. If you operate a mailing list or forward mail (for example, a
support@alias that fans out to a team), Authenticated Received Chain (ARC) headers preserve the original authentication results across the hop so the final receiver can see that the mail was authenticated before you forwarded it. Bulk senders that forward mail are expected to add ARC headers. This mostly matters for forwarders and list operators, not for an app sending its own mail. - DMARC must be aligned, not just present. Publishing
p=noneis not enough on its own: at least one of SPF or DKIM has to pass and be aligned with the domain in your visible From address. A record that exists but where nothing aligns does not satisfy the requirement. This is exactly the gap aggregate reports surface, which is why the difference betweenp=rejectandp=quarantineonly matters once alignment is solid.
None of these require enterprise tooling. For most indie senders on a reputable ESP, PTR, TLS, and ARC are handled for you. The job is to confirm, not to build.
The compliance checklist
Here's the full list with how to verify each item:
| # | Requirement | How to verify |
|---|---|---|
| 1 | SPF record published, resolves within 10 DNS lookups | Email auth checker |
| 2 | DKIM signing enabled with a domain-aligned key (1024-bit min, 2048 recommended) | Email auth checker; format keys with the DKIM generator |
| 3 | DMARC record published at p=none or stronger, with a rua= reporting address |
Gmail & Yahoo compliance checker |
| 4 | SPF or DKIM passes in alignment with the From domain | Read your DMARC aggregate reports; DMARCdrift parses them for you |
| 5 | Valid forward + reverse DNS (PTR) on sending IPs | Usually your ESP's job; check Postmaster Tools "IP reputation" |
| 6 | TLS used for transmission | Default on any reputable ESP; confirm in your MTA config if self-hosting |
| 7 | One-click unsubscribe (List-Unsubscribe + List-Unsubscribe-Post) on marketing mail |
Inspect raw headers of a sent campaign ("Show original" in Gmail) |
| 8 | Unsubscribe requests honored within two days | Test it: click your own unsubscribe link and confirm you stop receiving mail |
| 9 | Spam-complaint rate under 0.3% (ideally under 0.1%) | Google Postmaster Tools; only Google can measure this |
Items 1 through 6 are DNS- and infrastructure-level and can be checked with tools. Items 7 through 9 require inspecting actual sent mail and your Postmaster Tools dashboard. Run the Gmail and Yahoo compliance checker for the parts that are verifiable from outside, then close the loop on the rest by hand.
What Yahoo requires
Yahoo's requirements are substantially identical to Google's. SPF, DKIM, DMARC with alignment, one-click unsubscribe, and a low spam-complaint rate all apply. Yahoo's enforcement timeline tracked Google's closely.
In practice, fixing Gmail compliance fixes Yahoo compliance. The same authentication configuration covers both. Microsoft (Outlook, Hotmail, Live) has a separate program called SNDS (Smart Network Data Services) for monitoring sender reputation there, and announced its own bulk-sender requirements that lean on the same SPF/DKIM/DMARC foundation, so getting Gmail and Yahoo right puts you most of the way to Microsoft too.
Enforcement reality: what happens if you fail
The requirements rolled out in stages, and that staged approach is also how enforcement escalates. It is not a single on/off switch.
- Rate limiting first. When you fall short, say your complaint rate creeps up or alignment drops, Gmail and Yahoo start by slowing down how much of your mail they accept. You'll see temporary
4xxdeferrals ("4.7.x" rate-limit responses telling you to retry later) rather than hard rejections. Your mail isn't bounced, but it's trickling instead of flowing, and time-sensitive mail (password resets, OTPs) arrives late. - Junking next. Mail that gets accepted may be routed straight to the spam folder rather than the inbox. There's no bounce here at all, which is the most dangerous failure mode: everything looks delivered from your side while your open rates quietly collapse.
- Outright rejection last. Persistent or serious failures, such as no DMARC record at all, an authentication setup that never aligns, or a complaint rate that stays well above 0.3%, earn a hard
5.7.xrejection. The message bounces and never reaches the recipient.
The rollout itself was deliberately gradual so senders could fix things before getting cut off. Enforcement began in February 2024 with errors and temporary deferrals on a percentage of non-compliant traffic, ramped through the spring, and reached the point where non-compliant bulk mail to Gmail could be rejected outright. The one-click unsubscribe requirement was given extra runway, with required enforcement landing in June 2024. The takeaway for a small team: you usually get warning signs, deferrals and a dip in inbox placement, before the door closes. The whole point of monitoring your DMARC reports and Postmaster Tools is to catch those signs while they're still warnings.
Common failure patterns
Sending through an ESP without domain-aligned DKIM. This is the most common cause of DMARC failures. If your ESP sends mail from @yourdomain.com but signs with its own DKIM key for its own domain, neither SPF nor DKIM alignment holds. The fix is configuring DKIM for your domain in your ESP's settings. Most major ESPs support this, it just isn't always the default.
Forgetting to add a new sending service to SPF. Every service you send from needs to appear in your SPF record. When you add Intercom, Calendly, a new transactional provider, go add an include: to SPF. Not doing this is how your SPF record silently breaks new email flows.
rua= address not monitored. Reports arrive at your rua= address as gzipped XML. If nobody reads them, you have no signal that alignment is dropping. Set up a monitoring tool or at minimum review the reports occasionally. Alignment issues compound silently.
One-click unsubscribe missing on old marketing sequences. If you built email sequences before 2024 using a platform that didn't automatically add the RFC 8058 headers, those campaigns may not be compliant. Check your platform's documentation and resend affected templates through the updated headers.
What to check right now
If you're not sure where you stand, run your domain through the Gmail and Yahoo compliance checker. It checks SPF, DKIM, and DMARC configuration and maps the results directly to Google's and Yahoo's requirement lists.
If your DMARC reports are showing authentication failures you can't explain, the reports themselves tell you which sending sources are failing and why, but parsing them manually is painful. DMARCdrift surfaces them in a weekly digest and alerts you when something new appears, so the gap between "passing today" and "quietly broken next month" doesn't go unnoticed.