Gmail, Yahoo and Outlook sender requirements, in plain terms

The three largest consumer mailbox providers now require authenticated mail from bulk senders. The rules are similar but not identical, and several apply to every sender regardless of volume.

Use the Email Security Check

The timeline

Google and Yahoo began enforcing new sender requirements in February 2024. Microsoft announced equivalent requirements for Outlook.com, Hotmail.com and Live.com addresses, in effect from May 2025. In each case enforcement was phased in: first warnings and spam-folder placement, later temporary and permanent rejections.

Who counts as a bulk sender

Google defines a bulk sender as a domain that sends around five thousand or more messages a day to personal Gmail accounts. Microsoft uses the same five-thousand threshold for its consumer domains. Messages are counted by the domain in the visible From address, so several systems sending as the same domain are added together.

Smaller senders are not exempt from authentication. Google's guidelines ask every sender for SPF or DKIM, valid forward and reverse DNS for sending IPs, and TLS for transmission.

What bulk senders must have

The common core is the same across the three providers.

SPF and DKIM both set up for the sending domain.
A DMARC record published for the domain. A policy of p=none is accepted; it does not have to be quarantine or reject.
Alignment: the domain in the visible From address must match the SPF domain or the DKIM signing domain.
A working one-click unsubscribe in marketing and subscribed mail, honoured within two days (Google and Yahoo).
A low spam complaint rate. Google asks senders to stay below 0.3 percent as reported in Postmaster Tools.

What p=none does and does not give you

Publishing p=none satisfies the DMARC requirement, which is why many domains stop there. It does not protect the domain: receivers are asked to deliver failing mail as usual.

The value of p=none is the reports. With a rua address, receivers send aggregate reports that list every source sending mail as your domain and whether it passed. Those reports are what make it possible to move to quarantine or reject without losing legitimate mail.

How to check a domain

Read the published records rather than the intended configuration. Confirm there is exactly one SPF record and that it stays within ten DNS lookups, that the selectors your senders use publish valid DKIM keys, and that a single DMARC record exists with a report address.

Then confirm alignment using real mail: send a message to a mailbox at each provider and read the Authentication-Results header. Records can be correct while alignment still fails because a third-party service signs with its own domain.

What this means for agencies and MSPs

If you manage domains for clients, one misconfigured client domain produces a deliverability incident that the client experiences as their email being broken. Checking each domain once is not enough, because records change when a client adds a tool or a provider changes its includes. Continuous monitoring with change alerts is what turns this from an incident into a routine fix.

Frequently asked questions

Is DMARC p=none enough for Gmail and Yahoo?

Yes, for the requirement itself. A DMARC record with p=none is accepted. It does not ask receivers to block failing mail, so it is a starting point, not protection.

Do the rules apply to senders under 5,000 messages a day?

The bulk-sender rules apply above the threshold, but every sender is asked to authenticate with SPF or DKIM, and unauthenticated mail is more likely to be deferred or filtered.

Does CloudSpex measure my spam complaint rate?

No. Complaint rates are only visible in the providers' own tools, such as Google Postmaster Tools. CloudSpex checks the public DNS records and reports.

Use public checks as a starting point

CloudSpex reads limited public-facing signals. It does not change DNS, website, certificate, or email settings. Confirm the responsible provider and test relevant changes before applying a remediation.

Editorial details

Author and reviewer: CloudSpex. Sources: public technical standards and provider documentation relevant to the topic. Last reviewed: August 10, 2026. We update guides when the product behavior or the underlying guidance changes.