Gmail & Yahoo Bulk Sender Requirements: The DNS Checklist

Since February 2024, Gmail and Yahoo enforce a set of authentication and deliverability requirements for anyone sending bulk email to their users. “Bulk” is defined loosely — roughly 5,000 messages per day to Gmail addresses triggers the strict rules, but Gmail’s Postmaster tools and spam-rate throttling apply well below that threshold too. If your DNS setup is incomplete, you won’t get a bounce that clearly explains why; you’ll see messages silently routed to spam, or rejected with vague 5.7.1 errors. This checklist covers exactly what DNS records you need and how to verify each one.

Who actually needs to comply

Google’s own documentation states the strict requirements apply to senders of 5,000+ messages per day to gmail.com and googlemail.com addresses in a 24-hour window, counted per sending domain, not per campaign. Yahoo applies similar rules without publishing an exact number. In practice:

• Marketing platforms, transactional email services, and newsletter tools almost always cross the threshold on behalf of their customers.
• Small senders under the threshold still benefit from meeting the same requirements, since Gmail’s spam filtering increasingly treats unauthenticated mail as suspicious regardless of volume.
• The requirements apply per organizational domain (e.g. example.com), not per subdomain, so a poorly configured marketing subdomain can drag down your entire domain’s reputation with Gmail.

The DNS requirements

1. SPF record

You need a valid SPF record that authorizes your actual sending infrastructure. A minimal example for a domain sending through a third-party ESP:

example.com.  TXT  "v=spf1 include:sendgrid.net -all"

Common failure: forgetting to add include: statements for every service that sends as your domain (helpdesk tools, CRM, invoicing software), which causes SPF to fail for legitimate mail. Also watch the 10-DNS-lookup limit — if you’re already close to it, adding another include for compliance purposes can push you over into a permanent SPF error.

2. DKIM record

Every message needs a valid DKIM signature that verifies against a published public key. The DNS side is a TXT record at a selector subdomain:

selector1._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCSq..."

Use a key length of at least 1024 bits (2048 is now standard and recommended by Google). Rotate keys periodically, and make sure every sending platform has its own selector so a compromised key on one system doesn’t require re-signing everything.

3. DMARC record — mandatory, not optional

This is the requirement that trips up the most senders, because DMARC previously felt optional. Gmail and Yahoo now require a DMARC record to exist at the organizational domain, even if the policy is just monitoring:

_dmarc.example.com.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

p=none satisfies the bulk sender requirement — you are not required to enforce quarantine or reject. But without any _dmarc TXT record at all, Gmail will treat bulk mail as non-compliant. For a deeper comparison of policy levels, see our article on p=none vs p=quarantine vs p=reject.

4. SPF/DKIM alignment with the From: header

DMARC only passes if either SPF or DKIM is in alignment with the domain shown in the visible From: header. A common setup mistake: SPF passes because you’re sending through an ESP’s infrastructure, but the SPF-authenticated domain (the ESP’s return-path domain) doesn’t match your From: domain, and DKIM isn’t signed with your domain either. Result: SPF and DKIM individually pass, but DMARC still fails because neither is aligned. Fix this by using a custom return-path (bounce domain) that’s a subdomain of your sending domain, and by signing DKIM with your own domain rather than the ESP’s shared domain.

5. Valid forward-confirmed reverse DNS (FCrDNS)

The IP address sending your mail needs a PTR record that resolves to a hostname, and that hostname needs to resolve back to the same IP:

203.0.113.10  →  PTR  →  mail.example.com
mail.example.com  →  A  →  203.0.113.10

If you’re sending through a shared ESP IP pool, this is the ESP’s responsibility — but if you self-host mail or use a dedicated IP, missing or mismatched PTR records are one of the most common causes of Gmail rejecting connections outright with a 421 or 550 error before the message body is even evaluated.

Non-DNS requirements you still need to know

DNS is necessary but not sufficient. Gmail and Yahoo also require:

• One-click unsubscribe (RFC 8058) via the List-Unsubscribe and List-Unsubscribe-Post headers for marketing mail, honored within 48 hours.
• Spam rate below 0.3% as measured in Google Postmaster Tools — DNS authentication won’t save you if recipients mark you as spam at a high rate.
• Correctly formatted messages: valid MIME structure, no misleading From: names, and matching visible/DKIM-signed From: domains.

How to verify your setup

1. Query your SPF record: dig TXT example.com and confirm it includes all sending sources and ends in -all or ~all.
2. Query each DKIM selector: dig TXT selector1._domainkey.example.com and confirm a valid public key is published.
3. Query your DMARC record: dig TXT _dmarc.example.com and confirm it exists — this is the record most often simply missing.
4. Send a test message to a Gmail account and inspect the headers via “Show original” for spf=pass, dkim=pass, and dmarc=pass results, checking that alignment is also satisfied.
5. If you self-host or use a dedicated IP, verify PTR records with dig -x 203.0.113.10 and confirm the forward lookup matches.
6. Check your DMARC aggregate reports (the rua address) after a few days to confirm real-world pass rates match what your manual test showed.

Most senders who get flagged by Gmail or Yahoo aren’t dealing with exotic misconfigurations — they’re missing one of these five DNS records, or they have SPF and DKIM passing individually without alignment. Working through this list in order catches the vast majority of compliance failures before they turn into deliverability problems.