What Google and Yahoo require from bulk senders, and how to prove you meet it

Google requires SPF and DKIM, a DMARC record, From: header alignment, a matching forward and reverse DNS record on the sending IP, one-click unsubscribe, and a spam-complaint rate kept below 0.3% (0.1% recommended) once a sender passes 5,000 messages a day to Gmail accounts. Yahoo requires the same authentication, one-click unsubscribe honoured within two days, and a spam rate below 0.3%, but names no messages-per-day threshold at all. The two pages overlap on four requirements a domain can actually have checked from the outside, and they diverge on one number most write-ups get wrong.

This guide reads both companies' own pages - Google's email sender guidelines and Yahoo's sender best practices, both read 15 October 2026 - rule by rule, and says which parts a tool can check and which it cannot. For how many mailboxes and domains that volume actually needs, see cold email infrastructure: domains and mailboxes, which already covers that ground and the same complaint-rate figures in more detail - this guide does not repeat it.

What do Google and Yahoo actually require from a bulk sender?Copy Anchor Link

Both companies publish their own list, and four of the six items line up closely enough to check with the same tool.

Our bulk sender requirements checker runs the four checkable rows - SPF, DKIM, DMARC and forward-confirmed reverse DNS - against one domain at once, with Google's and Yahoo's figures shown side by side and cited to the page each one actually publishes it on. The two rows no outside tool can read, spam-complaint rate and TLS on the live SMTP connection, are shown too, marked "Not visible from outside" rather than left off the page.

One number deserves its own correction. Yahoo's page states no messages-per-day threshold for what counts as "bulk" at all. Its own FAQ, read 15 October 2026, settles it directly: "A 'bulk' sender is classified as an email sender sending a significant volume of mail. We will not specify a volume threshold". The 5,000-a-day figure repeated across many guides as "Yahoo's rule" is Google's own threshold for stricter requirements on Gmail accounts, imported into write-ups about Yahoo that never checked Yahoo's actual page.

What is forward and reverse DNS, and why do both companies require it?Copy Anchor Link

Forward-confirmed reverse DNS is two lookups treated as one answer, and it is the rule most senders have never actually checked.

1. A PTR lookup on the sending IP returns a hostname. Google's guidelines call this the "Pointer (PTR) record."
2. An ordinary forward lookup (A or AAAA) of that hostname has to resolve back to the same IP address.

Google states the requirement directly: "Ensure that sending domains or IPs have valid forward and reverse DNS records, also referred to as PTR records... The sending IP address must match the IP address of the hostname specified in the... PTR record". Yahoo lists the same expectation in plainer words: "Have a valid forward and reverse DNS record for your sending IPs".

A missing or mismatched PTR record is common, and worth fixing for mail rather than treated as proof something is broken. Our reverse DNS checker runs the first hop on its own - the PTR lookup for an IPv4 or IPv6 address - and our FCrDNS checker runs both hops and confirms whether the original IP actually comes back out the other end, which a PTR lookup alone cannot prove. A host that is multi-homed, answering for more than one address, can legitimately show a second address next to the match; neither tool calls that a fault on its own.

Are Google Workspace's and Microsoft 365's sending limits part of these rules?Copy Anchor Link

No, and the two get confused constantly. The bulk-sender rules above apply to any sender, on any platform, once Google or Yahoo decides the volume or practice counts as bulk. Google Workspace's and Microsoft 365's own sending limits are something else entirely: a platform ceiling on how much one mailbox is allowed to send at all, which exists to discourage bulk mail from a regular account rather than to define compliance for a sender built to do it properly.

Google Workspace caps a standard mailbox at 2,000 messages a day (1,500 for mail merge, 500 on a trial account), published on its own sending limits page, read 15 October 2026. Microsoft 365 caps a mailbox at 10,000 recipients on a rolling 24-hour window and 30 messages a minute, and states plainly, on a page also read 15 October 2026, that "the recipient rate limit and message rate limit are hard limits enforced at the service level and can't be increased" - unlike Google's mailbox limit, which can be worked around by routing through its separate SMTP relay service instead. Our provider sending-limit checker shows both vendors' own figures side by side, including the relay and API ceilings kept as their own, separate numbers rather than blended into the per-mailbox row.

What does one-click unsubscribe actually require?Copy Anchor Link

Both companies now require it on marketing mail, not merely ask for it, and the requirement is a specific pair of headers, not a general unsubscribe link in the body.

RFC 8058, read 15 October 2026, defines the syntax both inbox providers check for: "The List-Unsubscribe header field MUST contain one HTTPS URI", and "the List-Unsubscribe-Post header MUST contain the single key/value pair 'List-Unsubscribe=One-Click'". Get the scheme wrong (http:// instead of https://) or the body wrong by even a letter's case, and the receiver silently drops back to the slower mailto: or webpage flow instead of showing the one-click button at all. Yahoo adds a time limit Google does not state: unsubscribes must be "honored within 2 days".

Our list-unsubscribe header generator builds both header lines from an https:// link, and rejects a target that cannot carry a real one-click POST rather than producing a header that looks right but is not. Our list-unsubscribe header checker reads headers already written into a message and checks them against the same syntax. Neither tool ever sends a real request to the URL inside a header: doing so would actually unsubscribe whoever the header belongs to, so confirming an endpoint honours the POST, or honours it within Yahoo's two-day window, is not something either tool can do.

Why shouldn't a tracking link sit on the sending domain itself?Copy Anchor Link

It is not one of Google's or Yahoo's bulk-sender rules, but it is standard guidance from the email service providers that generate tracking links in the first place, and it is worth checking alongside the rest. Mailchimp Transactional's own documentation, read 15 October 2026, requires a subdomain for a tracking CNAME rather than the root sending domain: "You must use a subdomain (like mail.example.com) and not a root domain (like example.com)". SparkPost (Bird) gives the same subdomain isolation as general guidance for a sending-related domain, separate from the rest of a company's main domain, in its requirements for sending domains, also read 15 October 2026.

Our tracking domain CNAME checker follows a tracking subdomain's CNAME chain and says whether it ends at one of several email service providers' own published tracking hosts, or flags a tracking link sitting on the root domain with no subdomain at all. A target that matches none of the cited vendors is not automatically broken - it may belong to a provider not yet on that list - and a matching CNAME only confirms the DNS points at the right host, not that the provider has the custom domain configured and verified on its own side.

What can no tool here check?Copy Anchor Link

Three things, named plainly rather than left for a clean result to imply.

• The live spam-complaint rate. This is the number both companies actually enforce against - below 0.3%, with Google recommending below 0.1% - and it lives inside each sender's own Postmaster Tools or feedback-loop account. There is no public API to read it from outside, so no DNS lookup or header check can see it.
• Content and spam-word scoring. Nothing here reads a message's subject or body and scores it for spam-triggering wording. A message can pass every authentication and DNS check and still be written in a way a spam filter flags.
• List hygiene and engagement. Whether recipients actually opened, replied to or complained about a campaign, and whether a list has been pruned of invalid or unengaged addresses, is history a sending platform holds, not something a domain lookup can see.

A clean run through the tools in this guide confirms the parts of Google's and Yahoo's rules that can be checked from outside: authentication, DMARC, forward and reverse DNS, and unsubscribe header syntax. It is not the same as a clean Postmaster Tools account, and this guide does not say otherwise.