Home › Guides › Email Authentication › Google & Yahoo Bulk Sender Requirements: The Complete Compliance Checklist
Email Authentication•9 min•Updated 2026-03-01

Google & Yahoo Bulk Sender Requirements: The Complete Compliance Checklist

In February 2024, Google and Yahoo began enforcing a set of email authentication and deliverability requirements that had been announced in October 2023. For senders already operating with proper SPF, DKIM, and DMARC configurations, the changes were largely invisible. For organisations relying on unauthenticated email or manual unsubscribe workflows, the consequences were immediate: messages routed to spam, bounced, or rejected at the SMTP level. This guide covers every requirement in the **Google and Yahoo bulk sender requirements**, who each requirement applies to, what "compliant" looks like in practice, and how to verify your current status against each condition.

What Changed and Who It Affects

The two sender thresholds

Google and Yahoo's requirements apply differently based on daily sending volume:

RequirementAll SendersBulk Senders (5,000+/day to Gmail)
SPF or DKIM authentication✓ Required✓ Required
DMARC policy at p=none or higher—✓ Required
DKIM authentication specifically (not just SPF)—✓ Required
One-click unsubscribe (List-Unsubscribe-Post)—✓ Required (marketing/subscriptions)
Spam rate below 0.10%—✓ Required
Forward DNS and reverse DNS match✓ Required✓ Required
TLS connection for message transfer✓ Required✓ Required

"Bulk sender" means an organisation sending 5,000 or more messages per day to Gmail addresses across all sending domains and IPs. The 5,000-message threshold is measured by Google based on your sending history — it's not self-declared.

Yahoo's requirements mirror Google's in all substantive areas. The thresholds and specific mechanics of enforcement differ slightly but the required technical configuration is identical.

What these requirements don't change

  • p=none DMARC is acceptable for the bulk sender DMARC requirement — you are not required to enforce p=reject to meet the baseline. However, p=none provides no protection against domain spoofing; it only satisfies Google's minimum bar.
  • There is no explicit domain age requirement, though new domains face additional scrutiny from reputation systems.
  • The requirements apply to the sending domain — not just the IP. If you use a subdomain for marketing email, the subdomain's DNS records must satisfy the requirements independently.

Requirement 1 — SPF Authentication

What's required

Your sending domain must have a valid SPF record that passes for messages sent from your infrastructure. For all senders (under and over the 5K threshold), at least SPF or DKIM must authenticate.

What compliant looks like

Code
; SPF record at your domain root
example.com. TXT "v=spf1 include:_spf.google.com include:sendgrid.net ~all"

; The SPF check must pass — meaning the sending IP is authorised by the record
SPF result: pass

An SPF softfail (~all) is technically compliant for this requirement but weakens your overall authentication posture. A hard fail (-all) is stronger and preferred if you can be confident all your legitimate sending IPs are enumerated.

Common failure modes

  • No SPF record at the sending domain
  • Sending from an IP not listed in the SPF record (common with ESPs not properly configured)
  • SPF permerror due to exceeding the 10-DNS-lookup limit
  • Using a subdomain for sending without an SPF record on that subdomain

How to check

Code
# Check your SPF record
dig TXT example.com | grep "v=spf1"

# Check SPF for a subdomain used for sending
dig TXT mail.example.com | grep "v=spf1"

Use our SPF Checker tool to validate the full SPF record, count DNS lookups, and simulate a pass/fail result for specific sending IPs.

For the full SPF record syntax guide and 10-lookup limit explanation, see our SPF Record guide.

Requirement 2 — DKIM Authentication

What's required

For bulk senders (5,000+/day), DKIM authentication is specifically required — SPF alone is not sufficient. The DKIM key must be at least 1024 bits; Google strongly recommends 2048-bit keys.

For all senders, at least SPF or DKIM must authenticate — but DKIM is preferred because it survives email forwarding (where SPF typically breaks), making it the more reliable alignment mechanism for DMARC.

What compliant looks like

Code
; DKIM record at the selector subdomain
google._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQC..."

; The DKIM signature must verify — confirmed in Authentication-Results header
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=google; ...
Authentication-Results: dkim=pass header.d=example.com

The d= domain in the DKIM signature must match (or be organisationally aligned with) the From: header domain for DMARC alignment. Signing with d=sendgrid.net or d=mailchimp.com instead of d=example.com satisfies DKIM authentication but does not satisfy DMARC alignment for example.com.

Key size verification

Code
# Retrieve DKIM record and check key size
dig TXT google._domainkey.example.com +short

# A 2048-bit RSA key's p= value is approximately 350+ Base64 characters
# A 1024-bit key is approximately 175 Base64 characters
# Count the characters between p= and the closing quote to estimate

Most ESPs that provide CNAME-based DKIM automatically use 2048-bit keys. For self-managed DKIM, verify your key size during any rotation.

How to check

Use our DKIM Checker tool to look up any selector, verify the record syntax, confirm the key size, and check that the selector is actively signing for the correct domain.

For the complete DKIM setup, selector strategy, and key rotation guide, see our DKIM Explained guide.

Requirement 3 — DMARC Policy

What's required

Bulk senders (5,000+/day) must have a DMARC record published at _dmarc.yourdomain.com. The minimum acceptable policy is p=none — DMARC must be present, but enforcement is not required to meet Google's baseline.

The DMARC record must include an rua= address to receive aggregate reports — this is technically required for Google's compliance check.

What compliant looks like

Code
; Minimum compliant DMARC record for bulk senders
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.com"

; Stronger (recommended) — enforcing policy with reporting
_dmarc.example.com. TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@example.com; pct=100"

What p=none actually means for security

Meeting Google's DMARC requirement with p=none satisfies the technical checkbox but provides zero protection against domain spoofing. A p=none DMARC record tells receiving servers to do nothing differently — it's purely a monitoring policy. Attackers can still send email that appears to come from your domain and receivers will deliver it normally.

The DMARC requirement is the floor, not the target. The goal should be p=reject — which actually blocks spoofed email. See our DMARC Policy Enforcement guide for the safe progression from p=none to p=reject.

DMARC and subdomain sending

If you send from a subdomain (marketing.example.com), the DMARC record at _dmarc.example.com applies by default (via the sp= subdomain policy or organisational domain fallback). However, if the subdomain has its own DMARC record at _dmarc.marketing.example.com, that record governs instead.

Verify your DMARC is discoverable for the actual sending domain:

Code
# Check DMARC at root domain
dig TXT _dmarc.example.com +short

# Check DMARC at sending subdomain (if using one)
dig TXT _dmarc.marketing.example.com +short

Use our DMARC Checker to validate the record syntax, confirm alignment settings, and verify the rua= reporting address is reachable.

Requirement 4 — One-Click Unsubscribe

What's required

Bulk senders (5,000+/day) sending marketing or subscriptions email must support one-click unsubscribe using the RFC 8058 List-Unsubscribe-Post header. This applies to commercial email, newsletters, promotional campaigns, and subscription confirmations. It does not apply to transactional email (receipts, password resets, account notifications).

Google began enforcing this requirement in June 2024. Yahoo enforced it simultaneously with the February 2024 launch.

What compliant looks like

Every marketing message must include both the List-Unsubscribe header (the unsubscribe URL or mailto) and the List-Unsubscribe-Post header (the RFC 8058 mechanism that enables one-click action in Gmail's UI):

Code
; Required headers in every marketing/subscription message
List-Unsubscribe: <https://example.com/unsubscribe?id=abc123>, <mailto:unsubscribe@example.com?subject=unsubscribe>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

The List-Unsubscribe-Post: List-Unsubscribe=One-Click header is what enables Gmail to display the "Unsubscribe" button directly in the inbox interface, without requiring the user to open the email. When a user clicks it, Gmail sends an HTTP POST to the URL in List-Unsubscribe, the body being List-Unsubscribe=One-Click.

Implementation requirements

  • The unsubscribe URL must respond to HTTP POST requests (not just GET)
  • The URL must process the unsubscribe immediately — no confirmation pages, no "are you sure" steps, no requiring the user to log in
  • The unsubscribe must take effect within 2 days
  • The URL must remain valid for the lifetime of the campaign — broken unsubscribe URLs trigger compliance violations

⚠️ Warning: A List-Unsubscribe header with a URL that only handles GET requests (not POST) does not satisfy RFC 8058. Gmail's one-click button sends a POST. If your endpoint doesn't handle POST, the unsubscribe fails silently — the user sees a success message in Gmail but remains subscribed, which guarantees spam complaints.

Who implements this

If you use an ESP (Mailchimp, Klaviyo, SendGrid, Campaign Monitor, HubSpot, etc.), they typically add these headers automatically for campaigns. Verify by checking the raw headers of a sent test message:

Code
# Inspect headers of a received test message (from Gmail "Show Original")
# Look for:
List-Unsubscribe: <https://...>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

If you send via a custom mail system, you must add these headers programmatically to every marketing message and implement a compliant POST endpoint.

Requirement 5 — Spam Rate Below 0.10%

What's required

Bulk senders must keep their spam rate — as measured by Google Postmaster Tools — below 0.10%. Google will begin applying additional enforcement when spam rates approach 0.30%.

These thresholds are ongoing, not one-time. A spike above 0.10% doesn't immediately result in blocking, but sustained rates above 0.10% trigger deliverability degradation. Rates above 0.30% can result in messages being blocked entirely.

What spam rate means

Spam rate in Google Postmaster Tools is calculated as the fraction of your messages that Gmail users mark as spam, divided by total messages delivered to Gmail over a rolling period. It's domain-based, not IP-based.

Code
Spam rate = (messages marked as spam by Gmail users) / (total messages delivered to Gmail)

Threshold:  < 0.10% to maintain full deliverability
Warning:    0.10% – 0.30% — apply caution
Danger:     > 0.30% — expect blocking

A 0.10% spam rate means 1 in 1,000 recipients marking your mail as spam. For a sender dispatching 100,000 emails to Gmail users, that's 100 spam complaints.

Setting up Google Postmaster Tools

ℹ️ How to access: Visit postmaster.google.com, add and verify your sending domain (via a TXT record or HTML file), then monitor the Spam Rate dashboard. Data appears within a few days of sending sufficient volume to Gmail.

Postmaster Tools shows spam rate per domain (not per campaign), domain reputation (Low/Medium/High/Very High), IP reputation, DMARC compliance, and delivery errors. Monitor it regularly — it's the only authoritative source for how Gmail perceives your mail.

Factors that affect spam rate

  • List hygiene: Sending to disengaged subscribers inflates spam rates. Remove subscribers who haven't opened in 6–12 months.
  • Sending frequency: Sudden volume increases (sending 10× your normal volume) trigger spam rate spikes.
  • Content relevance: Subscribers who feel they're receiving irrelevant email mark it as spam without unsubscribing.
  • Easy unsubscribes: Counterintuitively, making unsubscribing easy reduces spam rates — frustrated users who can't unsubscribe easily mark mail as spam instead.
  • Suppression compliance: Failing to honour unsubscribes within 2 days means previously unsubscribed users receive subsequent campaigns and spam-flag them.

Requirement 6 — Valid PTR Record and TLS

PTR record (forward-confirmed reverse DNS)

Your sending IP must have a valid PTR record (reverse DNS), and the hostname in the PTR record must forward-resolve back to the sending IP:

Code
# Check PTR record for a sending IP
dig -x 203.0.113.45 +short
# Returns: mail.example.com.

# Verify forward resolution matches
dig mail.example.com A +short
# Must return: 203.0.113.45

If you use an ESP, their sending IPs already have correctly configured PTR records. For self-managed mail servers, ensure your hosting provider or ISP has set the PTR record for your IP — this is typically done through your hosting panel or by requesting it from your ISP.

TLS for message transfer

All messages must use TLS (Transport Layer Security) for SMTP connections. This is standard behaviour for all modern mail servers and ESPs — it's unlikely to be an issue unless you're running a legacy mail infrastructure that hasn't been updated in years.

Code
# Test TLS on your outbound mail server
openssl s_client -connect mail.example.com:587 -starttls smtp

The Full Compliance Checklist

Use this checklist to audit your current sending configuration against all requirements:

For all senders:

  • Sending domain has a valid SPF record (v=spf1 ... all)
  • SPF record passes (sending IP is authorised) — verify with SPF Checker
  • Sending IP has a PTR record (reverse DNS)
  • PTR hostname forward-resolves to the same IP (FCrDNS match)
  • All outbound SMTP connections use TLS
  • No active blacklistings — verify with Blacklist Check

Additionally for bulk senders (5,000+ messages/day to Gmail):

  • DKIM is enabled and signing outbound mail with a 2048-bit key
  • DKIM d= domain aligns with the From: header domain (not just ESP's domain)
  • DMARC record published at _dmarc.yourdomain.com with at minimum p=none
  • DMARC rua= reporting address set and functional
  • DMARC rua= address is authorised to receive reports (if using a third-party address, add yourdomain.com._report._dmarc.reportingdomain.com TXT record)
  • Marketing and subscription messages include List-Unsubscribe header
  • Marketing and subscription messages include List-Unsubscribe-Post: List-Unsubscribe=One-Click header
  • Unsubscribe URL responds to HTTP POST requests
  • Unsubscribes processed within 2 days
  • Google Postmaster Tools domain verified and spam rate monitored
  • Spam rate below 0.10% (check Postmaster Tools Spam Rate dashboard)
  • Domain reputation in Postmaster Tools is "High" or "Very High"

How to Verify Your Compliance Right Now

Step 1: Check authentication records

Code
DOMAIN="example.com"

# SPF
echo "--- SPF ---"
dig TXT $DOMAIN | grep "v=spf1"

# DMARC
echo "--- DMARC ---"
dig TXT _dmarc.$DOMAIN | grep "v=DMARC1"

# DKIM (check known selectors)
echo "--- DKIM ---"
for sel in google s1 s2 selector1 selector2 mail default; do
  result=$(dig TXT "${sel}._domainkey.${DOMAIN}" +short 2>/dev/null | grep "v=DKIM1")
  [ -n "$result" ] && echo "${sel}: FOUND"
done

Step 2: Send a test message and read the authentication headers

Send a message from your sending domain to a Gmail address. In Gmail, open the message, click the three-dot menu → "Show original." Look for:

Code
Authentication-Results: mx.google.com;
  dkim=pass header.i=@example.com header.s=google;
  spf=pass (google.com: domain of sender@example.com designates 1.2.3.4 as permitted);
  dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

All three — dkim=pass, spf=pass, dmarc=pass — should be present. If any show fail, permerror, or are absent, you have a gap to fix.

Step 3: Check Postmaster Tools

Visit postmaster.google.com and confirm:

  • Domain is verified
  • Spam Rate dashboard shows < 0.10%
  • Domain Reputation is "High" or "Very High"

Step 4: Check for blacklistings

An otherwise compliant sender can face deliverability problems if their sending IP appears on major blacklists. Use our Blacklist Check tool to scan your sending IPs against the major DNSBL lists. See our Email Blacklist Removal guide for the delisting process if you find any active listings.

What Happens If You Don't Comply

Google and Yahoo don't apply a binary block/allow — compliance failures result in graduated deliverability degradation:

FailureGoogle's Response
No SPF or DKIMMessages more likely to be spam-filtered or rejected
No DMARC (bulk sender)Messages routed to spam; increasing rejection over time
No one-click unsubscribe (bulk sender)Messages routed to spam for affected campaigns
Spam rate 0.10%–0.30%Deliverability degradation; increased filtering
Spam rate > 0.30%Temporary or permanent message blocking
Sustained non-complianceIP/domain reputation damage that persists after fixing

Google began rejecting a percentage of non-compliant bulk sender messages in April 2024 and increased enforcement through mid-2024. As of the current enforcement state, non-compliant bulk senders face systematic spam routing and rejection for authentication failures.

Yahoo applies similar enforcement with some differences in timing and thresholds, but the required configuration is identical.

Frequently Asked Questions

Q: I send fewer than 5,000 emails per day to Gmail. Do these requirements apply to me?

The stricter requirements (DKIM specifically, DMARC, one-click unsubscribe, spam rate monitoring) technically apply only to bulk senders at the 5,000/day threshold. However, SPF authentication and a valid PTR record apply to all senders. More importantly, meeting all the bulk sender requirements is best practice regardless of volume — proper authentication improves deliverability, protects your domain from spoofing, and future-proofs you against threshold changes. The configuration effort is the same whether you send 500 or 500,000 messages.

Q: Does p=none DMARC actually satisfy the requirement?

Yes — Google's stated minimum for the DMARC requirement is a valid DMARC record with any p= value, including p=none. The requirement is about having the record present with a valid rua= address, not about enforcement level. That said, p=none is monitoring-only and provides no protection against spoofing. The requirement is the floor; p=reject is the goal. See our DMARC Policy Enforcement guide for the path there.

Q: My ESP adds the List-Unsubscribe header automatically — do I still need to check?

Verify it. ESPs generally do add these headers, but the specifics matter: the URL must respond to POST (not just GET), the unsubscribe must process within 2 days, and the header must include List-Unsubscribe-Post: List-Unsubscribe=One-Click — not just List-Unsubscribe. Send a test message to Gmail and check the raw headers to confirm both headers are present with the correct values.

Q: How does Google count the 5,000 messages per day threshold?

Google measures sending volume across all messages sent to Gmail addresses from all domains you send from, aggregated at the sending organisation level. You don't self-report this threshold — Google's systems classify you as a bulk sender based on observed volume. If you're near the threshold, treat yourself as a bulk sender and meet all requirements proactively.

Q: We recently started getting messages routed to spam — could this be related to these requirements?

Possibly. Check Google Postmaster Tools for your domain reputation and spam rate. Check that DKIM is signing correctly (verify the Authentication-Results header in a received test message). Check that your DMARC record is present. If any of these are newly broken — due to a DNS change, ESP reconfiguration, or expired DKIM key — fixing the authentication issue will typically restore normal deliverability within a few days.

Next Steps

Use our SPF Checker, DKIM Checker, and DMARC Checker tools to audit each authentication record for your sending domain right now. The Email Deliverability Report runs all three checks in a single scan.

If your DMARC is at p=none and you want to progress to actual enforcement, see our DMARC Policy Enforcement guide for the safe none → quarantine → reject escalation process.

If you're seeing deliverability issues that aren't explained by authentication problems, check for blacklistings with our Blacklist Check and follow the removal process in our Email Blacklist Removal guide.

Browse all email guides on DNSnexus for related topics.

Related Guides