Gmail & Yahoo Rules: What Applies to Transactional Mail

When Gmail and Yahoo announced their sender requirements, most of the coverage was written for email marketers — and a lot of developers concluded, reasonably but wrongly, that "transactional email is exempt, this doesn't apply to us." Some of it genuinely doesn't. But some of it applies to everyone who sends a single email to a Gmail address, and one detail — how the 5,000/day threshold is counted — catches transactional senders who thought they were safely under the line. This is the tier-by-tier breakdown for people who send app email, not campaigns.

"Transactional email is exempt" is half-true and dangerous. The unsubscribe rule doesn't apply to your receipts — but your receipts still count toward the bulk threshold.

Three tiers, not one rule#

The requirements aren't a single checklist; they apply at different thresholds. Sorting them this way is the whole game.

Read the last column first. Nearly every row applies to you regardless of volume. The one row that mostly doesn't — one-click unsubscribe — is the one everyone remembers, which is why the "we're transactional, we're exempt" myth took hold.

The detail that trips people up: the threshold counts everything#

Here's the part worth reading twice. Google defines a bulk sender as one sending more than 5,000 messages to Gmail addresses in a single day, and — critically — there is no transactional exemption from that count. Google counts all mail to Gmail users from your domain together: marketing, receipts, alerts, notifications, verification codes. A team that sends 3,000 marketing emails and 3,000 transactional emails a day is a bulk sender, even though neither stream alone crosses the line.

So "we only send transactional, we're under 5,000" can be false in two ways: your transactional volume alone may cross it at scale, or it may combine with other mail on the same domain to cross it. If you're near the line, assume the strict tier applies and set up SPF, DKIM and DMARC now — which you should do anyway.

What actually changed, and when#

• February 2024 — Gmail and Yahoo began enforcing the requirements. Early non-compliance drew temporary errors with error codes on a portion of traffic.
• November 2025 — Gmail ramped up enforcement on non-compliant traffic; failing mail now sees disruptions including temporary and permanent rejections. "It still mostly gets through" stopped being true.
• Microsoft aligned Outlook.com with essentially the same authentication and unsubscribe expectations (adopted in 2025), so treating this as "just Gmail and Yahoo" is increasingly outdated. Between the three, these policies effectively set the industry baseline.

The direction is one-way: less tolerance for partial or broken setups, more consistent rejection of unauthenticated mail. A configuration that "worked" in early 2024 can fail now.

Your compliance checklist as a transactional sender#

Whatever your volume, do these — they're the base tier and they also happen to be what keeps transactional mail out of spam:

• [ ] SPF and DKIM both set up and aligned to your From: domain. (The base tier needs one; do both — it's what DMARC and the bulk tier require anyway.)
• [ ] DMARC published, at least p=none, and ideally advancing toward enforcement (see DMARC rollout).
• [ ] Valid PTR / reverse DNS on your sending IPs, with matching forward DNS.
• [ ] TLS on transmission (a good provider handles this).
• [ ] Spam complaint rate under 0.3% — monitor it in Postmaster Tools and suppress bounces/complaints (see bounce & complaint handler).
• [ ] No From: spoofing — don't send as @gmail.com from your own servers.
• [ ] List-Unsubscribe where you send anything promotional from the same domain — and consider isolating promotional mail entirely so it never drags your transactional reputation.

Using a provider that authenticates your domain and handles TLS covers several of these for you; the DNS records and the complaint rate are still yours to own.

Example scenario: the "we're under the limit" surprise#

(Illustrative scenario, not a customer case.) A growing app sends transactional mail — verification, receipts, alerts — and, from the same domain, a weekly product newsletter. Each stream is comfortably under 5,000/day, so the team assumes the bulk rules don't apply. Then a seasonal spike pushes combined daily volume over 5,000 for a week. Without DMARC published, a slice of their mail starts getting temporary rejections during exactly the week they most need reliability. The threshold was never about one stream; it counts everything to Gmail from the domain. Publishing DMARC and separating the newsletter onto its own subdomain would have made the spike a non-event.