Gmail and Yahoo sender requirements: a checklist

The part that is the same everywhere

Three things are required by all three providers, and they are the ones worth doing first because they are not conditional on volume or on which mailbox you are sending to.

• Authenticate with SPF and DKIM. Google requires at least one for every sender and both for bulk senders; Yahoo requires both for bulk; Microsoft requires both to pass for high-volume senders.

• Publish a DMARC record. All three require one above their volume threshold, and all three accept p=none as the minimum. This is the requirement people are most surprised by, because p=none provides no protection — it is required so that the providers can see a policy and so that alignment is evaluated, not because it stops anything.

• Align the authenticated domain with the visible From address. A passing SPF or DKIM check for an unrelated domain satisfies none of them. Relaxed alignment — a subdomain of the same organisational domain — is explicitly acceptable to Yahoo and is the default everywhere.

If those three are in place and correct, you meet the core of all three providers' rules. The rest is thresholds, hygiene and one-click unsubscribe.

Google

Google words its threshold two ways in two places. The main sender guidelines say "more than 5,000 messages per day to Gmail accounts"; the accompanying FAQ says "close to 5,000 messages or more to personal Gmail accounts within a 24-hour period". The FAQ wording is the one to plan against, because "close to" has no lower edge you can rely on. The count is across all messages sent from the same primary domain, so splitting a send across subdomains does not split the count.

For every sender, regardless of volume: SPF or DKIM; a valid forward and reverse DNS record for the sending IP, where the PTR hostname must itself resolve back to that IP; a TLS connection for transmission; and a spam rate below 0.3% as reported in Postmaster Tools.

For senders at or near the threshold, additionally: SPF and DKIM and DMARC, with the DMARC policy permitted to be p=none; From alignment with the SPF or DKIM domain; one-click unsubscribe in marketing and subscribed messages; and a tighter spam-rate target — Google asks for below 0.10% and says to avoid ever reaching 0.30%.

The unsubscribe deadline is not on the sender guidelines page; it is on Google's separate subscription guidelines, which say to process and honour unsubscribe requests within 48 hours. Google's FAQ also notes that from November 2025 it has been ramping up enforcement on non-compliant traffic, including both temporary and permanent rejections, so the failure mode is now a bounce rather than a spam folder.

Yahoo

Yahoo declines to publish a threshold, in as many words: "We will not specify a volume threshold." Treat its bulk requirements as applying to you if you send anything that looks like a campaign.

Its bulk requirements are SPF and DKIM both implemented, and a valid DMARC policy of at least p=none. Yahoo phrases the DMARC requirement differently from Google in a way that matters: it says DMARC must pass, not merely that a record must exist. It also states explicitly that relaxed alignment is acceptable.

One-click unsubscribe is required, and Yahoo cites RFC 8058 only, where Google cites both RFC 2369 and RFC 8058. Yahoo's deadline is two days rather than Google's 48 hours, which is the same number expressed differently.

Spam rate: below 0.3%, stated once and applying to everyone. Yahoo does not publish the 0.10% target that Google does.

Yahoo does not document a TLS requirement. That is not the same as saying TLS is not required — it is silence, and transmitting over TLS is correct regardless. Yahoo does add one requirement the others do not spell out: comply with RFC 5321 and RFC 5322, which in practice means well-formed messages with valid headers.

Microsoft

Microsoft's requirements for consumer mailboxes are narrower in scope and stricter in one respect. The threshold is 5,000 or more messages to Microsoft consumer email services, keyed on the domain in the From header rather than on the sending IP address.

SPF and DKIM must both pass, a DMARC record is required and may be p=none, p=quarantine or p=reject, and at least one of SPF or DKIM must align with the From domain. Mail that does not meet this is rejected with 550 5.7.515, naming authentication as the reason, which at least makes the cause diagnosable from the bounce.

Microsoft's published requirements do not mention one-click unsubscribe, a spam-rate threshold, TLS, or reverse DNS. That is a genuine difference in scope, not an omission on our part.

One honesty note: the widely repeated May 2025 start date for these requirements, and the reported transition from junk-foldering to outright rejection, could not be confirmed from Microsoft's own documentation — the support article carries no dates at all and the announcement post was not retrievable. The requirements themselves are documented; the timeline around them is secondary reporting and is presented here as unverified.

One-click unsubscribe, done correctly

The requirement is not a link in your footer. It is two headers that let the mailbox provider present its own unsubscribe control and act on it without the recipient visiting your site.

List-Unsubscribe carries an HTTPS URL, and optionally a mailto: address as well. List-Unsubscribe-Post carries the fixed value List-Unsubscribe=One-Click, which is what tells the provider it may send a POST to that URL rather than redirecting a human to it.

Three implementation details account for most failures. The URL must accept a POST and must unsubscribe on that POST alone — no confirmation page, no login, no landing page with a button. It must be HTTPS, not HTTP. And a mailto: on its own does not satisfy the requirement; the HTTPS URL is the part that matters.

Keep the visible unsubscribe link in the message as well. The header requirement is in addition to it, not a replacement, and the two should act on the same list.

List-Unsubscribe: <https://example.com/u/8f3a2b1c>, <mailto:unsub@example.com>
List-Unsubscribe-Post: List-Unsubscribe=One-Click

; the HTTPS URL must unsubscribe on a POST with no further interaction
; the mailto: is optional and does not satisfy the requirement alone

Spam rate is the requirement you cannot fix with DNS

Everything else on this page is configuration you can complete in an afternoon. The spam-rate threshold is a property of what you send and who you send it to, and it is the requirement that actually ends deliverability for most senders who lose it.

Google's Postmaster Tools is the only place you can see your own number as Google calculates it, and it requires verifying your domain to access. If you send meaningful volume to Gmail and have not set it up, do that before anything else on this list, because without it you are guessing at the one metric that has a published threshold.

The number to understand is that 0.30% is three complaints per thousand delivered messages. That is a low bar, and it is reached almost entirely by sending to people who did not ask, or who asked a long time ago. Purchased lists, long-dormant subscribers and an unsubscribe process that adds friction are the three reliable ways to cross it.

The structural fix is list hygiene rather than message content: confirmed opt-in, removing addresses that have not engaged in a long time, and making unsubscribing easier than marking as spam. A recipient who cannot find the unsubscribe control uses the spam button instead, and that is the one that counts against you.

A checklist, in the order to do it

• Inventory every system that sends mail as your domain. Everything below depends on this list being complete, and it is the step most often skipped.

• Publish an SPF record covering all of them, ending in ~all, and confirm it is under the ten-lookup limit.

• Enable DKIM signing on every platform, with its own selector per platform, and confirm each key resolves at 2048 bits.

• Confirm reverse DNS for every IP you send from directly — required by Google, and the PTR hostname must resolve forward to the same address. If you send only through providers, this is theirs to get right, not yours.

• Publish DMARC at p=none with a rua reporting address. This meets the requirement and starts the flow of information you need for the next step.

• Read the aggregate reports for two to four weeks and fix every legitimate source that is not authenticating in alignment.

• Add one-click unsubscribe headers to every marketing and subscribed message, and verify the URL unsubscribes on a bare POST.

• Set up Google Postmaster Tools and watch the spam rate.

• Move DMARC to p=quarantine, then to p=reject. This is beyond what any of the three providers require, and it is the only step on this list that actually stops anyone impersonating your domain.

Run the domain health check at the end to see SPF, DKIM, DMARC, reverse DNS and TLS reported together. It will not tell you your spam rate — nobody but the mailbox provider can — but it covers everything else on the list in one pass.

What commonly goes wrong

• Publishing DMARC at p=none, meeting the requirement, and stopping there. It satisfies the providers and protects nothing; treat it as the start of a rollout with a date attached.

• Assuming you are under the threshold. Google counts across the primary domain and says "close to 5,000"; Yahoo publishes no threshold at all. If you send campaigns, assume the bulk rules apply.

• An unsubscribe URL that returns a confirmation page instead of unsubscribing on the POST. It looks correct to a human and fails the automated requirement.

• SPF passing for the provider's bounce domain while DKIM is not configured, so nothing aligns with your From address. Alignment is what is being checked, not the raw pass.

• Adding a second SPF record when onboarding a new platform. Two records is a permerror, which removes SPF entirely and can take you below the requirement overnight.

• Treating a checker's green result as compliance. The configuration requirements are checkable; the spam-rate and list-quality requirements are not, and they are the ones that get senders blocked.