PostureAudit

Google & Yahoo bulk sender requirements: what you can check, and what you can’t

Both providers now enforce a set of requirements on anyone sending significant volume to their users. The requirements split cleanly in two: some are properties of your domain, verifiable by anyone from public DNS. The rest are properties of your mail, which no external tool can see. Knowing which is which saves a lot of wasted checking.

Verifiable from DNS

SPF

A valid record listing your senders. “Valid” is doing real work in that sentence — a record that exceeds the ten-lookup limit is a permerror and receivers treat it as though no SPF exists, while it still looks fine. See the lookup limit guide.

DKIM

Your mail must carry a valid signature. Selectors can't be enumerated from DNS, so “not found” from any checker means “not found at the selectors tried” — confirm yours from a real message's DKIM-Signature header. See the DKIM guide.

DMARC

A published policy. p=none satisfies the requirement, which surprises people — the bar is that a policy exists, not that it enforces. none gives you reporting and no protection, so treat it as the starting point rather than the destination.

Alignment

The visible From: domain must align with the SPF or DKIM domain. This is what makes DMARC meaningful, and it's the usual reason a domain with working SPF and DKIM still fails DMARC.

Not verifiable from outside

These matter just as much. No external checker can confirm them, and any tool claiming a clean bill of health on these is overreaching.

RequirementWhy it can't be checked externally
Forward and reverse DNS on sending IPs Depends which IPs you send from, which isn't derivable from the domain. Your provider usually handles it.
One-click unsubscribe on marketing mail A message header (List-Unsubscribe and List-Unsubscribe-Post). Only visible in mail you send.
Spam complaint rate under 0.3% Measured by the receiving provider. Track it in Google Postmaster Tools.
TLS in transit A property of the connection. Publishing an enforced MTA-STS policy is the closest observable equivalent, and covers inbound only.
The 0.3% rate is the one that catches people. The others are configuration you fix once. Complaint rate is ongoing, driven by list quality and sending practice, and it is the requirement most likely to be failed by a domain whose DNS is immaculate.

A sensible order

  1. Publish SPF and confirm it's under the lookup limit.
  2. Enable DKIM and verify a real message is signed.
  3. Publish DMARC at p=none with a rua= address.
  4. Read reports until every legitimate sender passes.
  5. Move to p=quarantine, then p=reject.
  6. Add one-click unsubscribe to marketing mail.
  7. Watch complaint rate in Postmaster Tools.

Steps 4 and 5 are where people rush. Moving to reject before reports are clean means silently destroying your own legitimate mail — the one failure mode here that actively causes damage rather than merely failing to prevent it.

Volume thresholds

The rules are framed around bulk senders, commonly cited at around 5,000 messages a day to a given provider. Treating that as a line to stay under is a mistake: authentication is checked on everything, thresholds get lowered over time, and a domain that sends 500 messages a day is one campaign away from being in scope. The configuration half costs an afternoon and applies to any volume.

Related guides