Google and Yahoo Sender Requirements: What Applies to Transactional Email
Gmail and Yahoo Mail have enforced sender requirements since February 2024, and Google says it has been ramping up enforcement since November 2025. This page separates what applies to every sender from what applies to bulk senders, and says plainly which parts do not apply to transactional mail such as password resets and receipts. As checked on October 30, 2026, every rule below is taken from Google's and Yahoo's own pages, linked at the end.
The short answer
Transactional senders are not exempt from the authentication, DNS, TLS and spam-rate rules. They are exempt from one thing: both Google and Yahoo say one-click unsubscribe is required only for marketing and promotional messages, not for transactional messages such as password resets and order confirmations. If you cross Google's bulk-sender volume, or Yahoo considers you a bulk sender, you also need DMARC and both SPF and DKIM.
What each provider requires, side by side
As checked on October 30, 2026, from Google's email sender guidelines, Google's sender guidelines FAQ, Yahoo's sender requirements and Yahoo's sender FAQ:
| Requirement | Google, all senders to Gmail | Google, bulk senders | Yahoo, all senders | Yahoo, bulk senders |
|---|---|---|---|---|
| Authentication | SPF or DKIM | SPF and DKIM | SPF or DKIM | SPF and DKIM |
| DMARC | Not required | Required; p=none is allowed; From domain aligned with SPF or DKIM | Not required | Valid policy of at least p=none, and DMARC must pass; relaxed alignment is acceptable |
| Forward and reverse DNS for sending IPs | Required | Required | Required | Required |
| TLS | Required | Required | Not listed on the requirements page | Not listed on the requirements page |
| User-reported spam rate | Keep below 0.3% | Keep below 0.3% | Keep below 0.3% | Keep below 0.3% |
| Message format | RFC 5322 | RFC 5322 | RFC 5321 and 5322 | RFC 5321 and 5322 |
| One-click unsubscribe | Not required | Marketing and subscribed messages only; transactional is excluded | Not required | Marketing and subscribed messages only; transactional is excluded |
| Honor unsubscribes | Not stated for all senders | Recommended within 48 hours | Not stated for all senders | Within 2 days |
Who counts as a bulk sender
Google defines a bulk sender as any sender that sends close to 5,000 messages or more to personal Gmail accounts within a 24-hour period, counting every message from the same primary domain. Senders who meet that once are permanently classified as bulk senders. Yahoo says a bulk sender is one sending a significant volume of mail and does not publish a volume threshold.
So a product that only sends receipts and password resets can still become a bulk sender in Google's terms if enough of its users are on Gmail. The practical advice is the same either way: set up SPF, DKIM and DMARC on your sending domain before you need them. Google itself recommends always setting up all three.
What this means for a transactional sender
- Authenticate the sending domain with SPF and DKIM, and publish a DMARC record. p=none satisfies both providers' minimum for bulk senders. Our guide to moving from p=none to p=reject covers the next steps.
- Keep spam complaints low. Google's FAQ says to keep the user-reported rate below 0.1% and never reach 0.3%; Yahoo says below 0.3%.
- Do not mix content types. Google's guidelines say not to include promotions in receipt-style messages, and Yahoo recommends separating bulk marketing from transactional mail by IP or DKIM domain. Keep marketing mail off your transactional domain.
- You do not need one-click unsubscribe on password resets, receipts and similar messages. Yahoo adds that if you see high complaint rates on mail that is not legally required to carry an unsubscribe link, offering one may still help.
- Increase volume gradually. Both providers warn that sudden spikes from a new sender can be flagged.
Forward and reverse DNS and TLS are properties of the servers that connect to Gmail and Yahoo. If you send through an email API, those servers belong to the provider, so ask the provider how it meets them. Google's guidelines also say to verify that any email service provider authenticates your domain with SPF and DKIM.
How this relates to AISend
AISend sends through AWS SES and requires a verified domain of your own before you can send to anyone other than your own account email, so SPF and DKIM are set up as part of onboarding. AISend is newer and has no long shared-IP history, and nothing on this page is a promise about where your mail lands. DMARC is a record you publish yourself: use the free SPF and DMARC checker to see what your domain currently publishes.
AISend's 3-day trial is free: 500 emails, no card, one verified domain. Paid plans are charged when you subscribe. AISend is for transactional and consented mail, and sending to anyone other than your own account email requires a verified domain.
Frequently asked questions
Do the Google and Yahoo requirements apply to transactional email?
Yes for authentication, DNS, TLS and spam-rate rules. No for one-click unsubscribe: both Google and Yahoo say it is required only for marketing and promotional messages, and name password resets and order confirmations as transactional examples.
Do I need DMARC if I send fewer than 5,000 emails a day?
Google requires DMARC from senders that send close to 5,000 or more messages a day to personal Gmail accounts, and recommends it for everyone. Yahoo requires it from bulk senders and does not publish a volume threshold, so publishing at least p=none is the safe default.
Is p=none enough to meet the requirement?
Google says the DMARC enforcement policy can be set to none, and Yahoo requires at least p=none with DMARC passing. Both providers' pages describe p=none as the minimum, not the recommended end state.
Does Yahoo have a volume threshold for bulk senders?
No. Yahoo's FAQ says a bulk sender is one sending a significant volume of mail and that it will not specify a volume threshold.
Sources
More guides
Check what your domain publishes
Run the free SPF and DMARC checker on your sending domain before a provider tells you what is missing.