Deliverability
Bulk sender requirements checker
Check one domain against Google's and Yahoo's own published bulk-sender rules, with what neither can see named outright.
Free, no accountLive check
Result
Fill in the form and press Check the requirements. The verdict and the detail appear here.
What this is
This bulk sender requirements checker runs SPF, DKIM, DMARC and forward-confirmed reverse DNS for one domain and lines each one up against the gmail yahoo bulk sender requirements, cited to the page each company actually publishes it on - never one company's number attributed to the other.
Google and Yahoo each publish their own rules for a sender crossing their own bulk threshold, and the two pages overlap on four things a domain can actually have checked from outside: SPF or DKIM (both, past Google's own 5,000-messages-a-day figure), a DMARC record, and forward-confirmed reverse DNS on the sending IP. Two more items both companies also require - a spam-complaint rate kept low, and TLS on the SMTP connection - cannot be read from outside at all, and this page says so on the same row rather than leaving them out.
The two pages are not the same page copied twice. Yahoo's own FAQ states plainly that it will not publish a volume threshold at all, which is why the 5,000-a-day figure belongs to Google alone - a number quoted for Yahoo under that heading is simply wrong.
How to read the result
Each requirement gets its own small block of three rows - what Google asks for, what Yahoo asks for, and what this domain actually does - so no part of the comparison is ever off the side of the screen, at any window width. The two blocks nothing outside can measure read "Not visible from outside" rather than a dash, since a tool that can't see something should say so, not guess at it.
The tree below those blocks is the evidence behind the forward-confirmed reverse DNS one: the sending IP, the hostname its PTR record names, and every address that hostname resolves back to - the one that matches the original IP is marked, and a second address next to it is a multi-homed host, not a second fault.
Our guides walk the same rules in prose, rule by rule: "What Google and Yahoo require from bulk senders, and how to prove you meet it" lines up every row above against both companies' own pages and names the parts no tool, including this one, can check.
Common mistakes
What goes wrong most often, and how to tell.
- Quoting Google's 5,000-a-day figure as if Yahoo published it tooYahoo's own FAQ refuses to name a volume threshold at all - "we will not specify a volume threshold" - so a page or email that cites 5,000 messages a day as a Yahoo rule is quoting a number Yahoo never published.
- Guessing the sending IP from the MX recordAn MX record names the host that *receives* mail for a domain, not the server that sends it. Forward-confirmed reverse DNS is a check on the sending IP, so a tool - or a person - that reads it off MX instead is checking the wrong machine entirely.
- Treating "p=none" as a DMARC failure for a bulk senderGoogle's own page says the DMARC enforcement policy "can be set to none" and still satisfies its bulk-sender requirement - the record only has to exist and parse. A general review of DMARC maturity is a different question from whether this specific rule is met.
Questions
What people ask about this tool.
- No - it is Google's own published figure for mail to Gmail accounts. Yahoo's sender best-practices page states the same four authentication requirements but never names a per-day number, and its own FAQ says outright that it will not specify a volume threshold at all.
- Both are real requirements on Google's and Yahoo's own pages, so leaving them off entirely would make the comparison look more complete than it is. Each gets the same three-row block as the four checkable requirements, with "Not visible from outside" where the domain's own answer would be rather than being silently dropped.
- It means the one piece of forward-confirmed reverse DNS that Google's and Yahoo's own pages both name as a requirement is not in place yet. Some receivers are stricter about it than others, but neither company's own page treats it as optional once a sender is at bulk volume.
- Because that is exactly what Google's own page allows: "Your DMARC enforcement policy can be set to none." A record that exists and parses satisfies the bulk-sender rule even before it is tightened to quarantine or reject.
Sources
Every fixed value here comes from the provider’s own documentation. These pages change, so each says the day it was last read.
- Google, “Email sender guidelines” read 13 October 2026
- Yahoo, “Sender Best Practices” read 13 October 2026
- Yahoo, “FAQs | Sender Hub” read 13 October 2026
Use it from the API
The same check, as one request.
This example uses a name RFC 2606 reserves for documentation, ending in .example, .test, .invalid or .localhost. None of them is a real domain, and nobody can register one.