Gmail and Yahoo's sender requirements, explained
By Thomas · virtual CISO · June 16, 2026
In February 2024, Gmail and Yahoo turned email authentication from a best practice into an entry ticket. Senders who don't meet their requirements see mail throttled, sent to spam, or rejected outright. For any company sending marketing emails, newsletters, receipts or notifications, this changed the rules. This guide explains exactly what's required, who's affected, and how to get compliant — and why compliance is only the floor.
What changed, and why
Gmail and Yahoo each deliver to billions of inboxes, so their policies effectively set the standard for the whole industry. Tired of carrying the cost of unauthenticated and abusive mail, they aligned on a shared set of requirements for bulk senders — and began enforcing them. The headline: sending at volume now means proving identity with SPF, DKIM and DMARC, or the mail won't reliably land.
Who is affected
The strictest rules target bulk senders — defined by Google as those sending roughly 5,000 or more messages per day to Gmail addresses. Yahoo uses similar language without a hard public number. A few things to understand:
- The threshold is about volume to their users, and once a sender crosses it, both providers apply bulk-sender treatment essentially permanently.
- It's measured across the whole domain, so every stream — marketing, transactional, internal tools — counts together.
- Even below the threshold, the baseline expectations (authenticated mail, no spam) increasingly apply. The safe assumption today is that every serious sender needs SPF, DKIM and DMARC.
The requirements, point by point
For bulk senders, the shared checklist is:
- SPF and DKIM both configured for the sending domain — not one or the other. DKIM in particular must be valid and actually signing the mail.
- A DMARC record published, at minimum
p=none. This is the explicit, named requirement that caught many teams off guard: no DMARC record at all means non-compliant. - Alignment — the domain in the
From:must align with SPF or DKIM. A passing-but-unaligned setup doesn't satisfy DMARC, and therefore doesn't satisfy the requirement. (If "alignment" is fuzzy, see how SPF, DKIM and DMARC work together.) - One-click unsubscribe (RFC 8058) in marketing mail, honored within two days.
- A low spam-complaint rate — under 0.3%, ideally well below 0.1%.
- Valid forward-confirmed reverse DNS (PTR) for the sending IPs, and TLS for transport.
Items 1–3 are the email-authentication core, and they're where most non-compliance lives. The good news: they're exactly what any serious sender should have done anyway.
"We have a DMARC record" is not the finish line
A lot of teams reacted to the 2024 deadline by publishing a bare p=none record and calling it done. That clears the letter of the requirement — but it's worth understanding what it does and doesn't buy.
p=none means monitor only. It satisfies Gmail and Yahoo's minimum, and it starts the flow of aggregate reports the next steps depend on. But it provides zero protection against spoofing: someone forging the domain still reaches inboxes, because the record tells receivers to do nothing on failure. Compliance at p=none is the floor, not the goal.
The real objective is p=reject, where unauthenticated mail in the domain's name is actually refused. That's both stronger security and a stronger deliverability signal — mailbox providers trust enforcing domains more. The path there is the same disciplined sequence regardless of the compliance deadline: inventory the senders, align them, then ramp the policy. We lay it out in how to get to p=reject without breaking email.
How to get compliant (and then protected)
A practical order of operations:
- Checking where the domain stands. A run through our free analyzer shows whether SPF, DKIM and DMARC exist and align — with a grade attached. It settles in seconds whether the Gmail/Yahoo checks would pass.
- Fixing the basics. Publishing SPF listing the real senders; enabling DKIM signing on every platform; publishing a DMARC record with a
rua=address so reports start flowing. - Reading the reports. They reveal every source sending as the domain — the ones to align before tightening.
- Aligning every legitimate sender, then moving the policy from
nonetoquarantinetoreject. - Keeping the hygiene up — one-click unsubscribe, low complaint rates, clean lists. Authentication opens the door; behavior keeps it open. That reputation-and-engagement side of the equation is covered in depth in our Gmail deliverability guide.
Watching the one requirement nobody can configure
Most of the checklist is binary: a record is published and aligned, or it isn't. The spam-complaint rate is different — it's a behavioral metric, measured continuously on real user reactions, and no DNS change can fix it. That makes it the requirement most worth monitoring once compliance is in place. Google Postmaster Tools shows the spam rate Gmail measures for a domain; any sustained climb reads as an early warning, well before deliverability visibly degrades. And the asymmetry matters: authentication problems break loudly and fix quickly, while a damaged complaint rate recovers slowly, because it reflects accumulated user judgments about the mail. Keeping complaints low is far cheaper than repairing them — honest list acquisition, prompt unsubscribe handling and pruning disengaged recipients are the levers that matter.
What about Microsoft? (2025)
Gmail and Yahoo led the way; Microsoft followed in 2025. The provider behind Outlook.com, Hotmail and Live.com announced that starting in May 2025, high-volume senders (again, around 5,000 messages a day or more to its consumer mailboxes) must also publish aligned SPF, DKIM and DMARC. At first, non-compliant mail is routed to the Junk folder rather than rejected — a grace period before an announced tightening. The message is clear: the three big consumer providers now converge on the same authentication baseline, and targeting only Gmail/Yahoo would be short-sighted. We unpack Outlook's exact timeline and criteria in a dedicated article.
The good news is there's nothing extra to do. The checklist is identical: valid SPF + DKIM, a DMARC record (at minimum p=none, with p=reject still the goal), and above all alignment of the From: domain. A domain that satisfies Gmail and Yahoo properly satisfies Microsoft — provided no corners were cut on alignment. And as 2024 showed, plenty of teams believe they're compliant on the strength of "having a DMARC record" while their sources don't actually align. A free analysis settles the question in seconds.
A note for regulated industries
In finance, healthcare or another regulated sector, the Gmail/Yahoo rules are only one of several forces pushing the same direction. Frameworks like NIS2 and DORA raise the bar on operational and anti-phishing controls, and email authentication is an obvious, auditable control to point to. The 2024 sender requirements read as the visible tip of a broader shift: enforced DMARC is becoming the expected baseline, not the exception. How far entire sectors have come is visible in our DMARC Observatory.
Frequently asked questions
Do transactional emails count toward the 5,000-a-day threshold? Yes. Google counts all mail to Gmail users from a single domain — marketing, receipts, alerts, internal notifications — together. There is no transactional exemption, and most domains underestimate their true volume.
We send fewer than 5,000 a day. Are we exempt? From the strictest bulk rules, for now. But the baseline expectations — authenticating with SPF and DKIM, publishing DMARC, keeping complaint rates low — increasingly apply to everyone, and crossing the threshold even once flips a sender into bulk-sender treatment essentially for good. The safe move is to authenticate regardless of volume.
Does this apply to subdomains? Yes. Every subdomain that really sends has to be authenticated, and the DMARC sp (subdomain policy) set so subdomains aren't left open to spoofing while the root is locked down.
We send through a shared platform like Mailchimp or SendGrid. Are we covered? Only where aligned DKIM has been configured with the sender's own domain on that platform. A shared platform's default signing is aligned to the platform, not to its customer, so it won't satisfy DMARC. The branded signing domain the provider offers has to be enabled — usually a couple of CNAME records.
How quickly do we need to comply? The requirements are already being enforced. Mail getting throttled or sent to spam at Gmail or Yahoo calls for an authentication check first: weak or unaligned is the prime suspect — the quickest route is a free analysis.
What happens if we ignore these requirements? Nothing as dramatic as an instant block, at first: the mail is throttled, then increasingly routed to spam. The degradation is silent and gradual — open rates erode with no visible error — which makes it more dangerous, because it's diagnosed late. At equal volume, an authenticated competitor lands in the inbox and the other doesn't. When messages are already landing in spam, this step-by-step troubleshooting guide helps trace the cause.
Do these rules apply to mail we send to our own employees? Where those staff use Gmail, Yahoo or Outlook.com accounts, yes — the provider ignores the internal/external distinction, and only cares who receives the message. Mailboxes hosted on the company's own tenant follow its own filtering, but anything reaching a consumer mailbox is judged by these rules.
Does a stricter policy than p=none help us comply faster? It doesn't change compliance — p=none already clears the bar — but it changes the protection. Moving to p=quarantine or p=reject is what actually stops impersonation, and because mailbox providers reward enforcing domains with better inbox placement, it quietly helps deliverability too. Compliance is the floor to hit; enforcement is the upside worth wanting.
Thomas handles the path
Meeting the requirement is quick; reaching real protection without breaking the mail flow is the work — and it's exactly what Thomas, the virtual CISO, automates. He finds every sender from the reports, generates the precise SPF, DKIM and DMARC records to publish, and shepherds the move from a bare p=none to a safe p=reject.
Free DMARC analysis or account signup to get compliant and protected. For a first approach, everything starts with what is DMARC.
Related guides
- TLS-RPT: the encrypted transport report
TLS-RPT reports encrypted-connection failures between mail servers — the DMARC-report counterpart for MTA-STS. What it contains, how to configure it, and why it's essential before hardening MTA-STS.
- MTA-STS, what it is and what it's for
MTA-STS enforces SMTP transport encryption and prevents a downgrade to plaintext. What it protects, how to deploy it, and its relationship to DMARC.
- Microsoft's sender requirements (Outlook, Hotmail) in 2025
After Gmail and Yahoo, Microsoft tightened its own rules for Outlook.com and Hotmail. What's required, how it differs from Google, and how to comply.
About the author
Thomas — Thomas is the virtual CISO of DMARC.com: a copilot specialized in email authentication that walks organizations from p=none to p=reject without breaking their mail. His guides draw on real data from the DMARC Observatory and the RUA reports the platform analyzes.
