SPF, DKIM and DMARC: What Mailbox Providers Require

Three mailbox providers now publish hard rules for anyone who sends them email, and all three rest on SPF, DKIM and DMARC. The rules look alike from a distance. Up close they differ on who counts as a bulk sender, what happens to failing mail, and how much they tell you.

Everything below was read from the providers' own pages and the IETF standards on 13 Nov 2026. Nothing here was sent or measured; the methodology page explains what a desk-research label covers.

What each provider requires

Google's rules are in its sender guidelines and the accompanying FAQ. Yahoo's are in its best practices and FAQ. Microsoft set out its own in a blog post and a support page.

Two points of scope are easy to miss. Google's rules cover mail to personal Gmail accounts only; its FAQ says they "don't apply to messages sent to Google Workspace accounts". Microsoft's cover the consumer service: hotmail.com, live.com and outlook.com addresses.

Who counts as a bulk sender?

The three providers answer differently.

• Google defines a bulk sender as one that sends "close to 5,000 messages or more to personal Gmail accounts within a 24-hour period". Subdomains are pooled, and the status is permanent once reached.
• Microsoft applies its rule to "domains sending over 5,000 emails per day". It does not say whether that is counted per domain or whether it resets.
• Yahoo declines to give a figure: "We will not specify a volume threshold."

A company that sends invoices and a monthly newsletter can cross Google's line on a single busy day. Since the label then sticks, the practical reading is to meet the bulk rules before you need to.

How enforcement has tightened

Each provider started gently and then moved to rejection.

1. February 2024. Google and Yahoo requirements took effect.
2. June 2024. One-click unsubscribe became enforceable for marketing mail at both.
3. May 2025. Microsoft began rejecting. Its post originally promised the Junk folder first; an update dated 29 April says it had "made a decision to reject messages that don't pass".
4. November 2025. Google's FAQ says Gmail "is ramping up its enforcement", with "temporary and permanent rejections".

Alignment: the part that fails quietly

Passing SPF and DKIM is not enough for DMARC. One of them must also align, meaning the domain it authenticates matches the domain in the visible From address.

All three providers accept alignment through either mechanism. Google's FAQ puts it plainly: "only one of these needs to be aligned". This is where third-party senders go wrong. A newsletter service can pass SPF for its own domain while your From address shows yours, and that fails alignment unless DKIM is signed with your domain.

Google warns that the bar will rise: "It's likely that DMARC alignment with both SPF and DKIM will eventually be a sender requirement."

SPF, DKIM and DMARC records to publish, in order

The order matters. Google's DMARC page says to turn on SPF or DKIM first and to "allow 48 hours" before adding DMARC.

1. SPF

One TXT record at the root of the domain. Microsoft's SPF page gives this for Microsoft 365:

v=spf1 include:spf.protection.outlook.com -all

Google's SPF page gives this for Workspace:

v=spf1 include:_spf.google.com ~all

A domain may have only one SPF record. If two services send for you, they go in the same record. Note the different endings: Microsoft recommends -all, Google recommends ~all.

2. DKIM

For Microsoft 365, publish the two CNAME records the tenant generates, then enable signing in the Defender portal. Microsoft's DKIM page says custom domains added since May 2025 use a new record format ending in dkim.mail.microsoft, while older domains keep the old one. Read the real values from your tenant; do not copy an example.

For Google Workspace, generate the key in the Admin console and publish it as a TXT record named google._domainkey. Google's DKIM page recommends the 2048-bit option where the DNS host supports it. Then click "Start authentication".

3. DMARC

One TXT record at _dmarc.yourdomain. The minimum that satisfies all three providers is:

v=DMARC1; p=none; rua=mailto:[email protected]

The rua address receives daily reports showing who is sending as your domain. Reading them is how you find the forgotten senders before tightening the policy.

The pct tag is no longer in the standard

DMARC was an informational document, RFC 7489, for eleven years. In May 2026 the IETF published RFC 9989 as a standards-track replacement that obsoletes it.

RFC 9989 lists pct under "Tags Removed". That tag told receivers to apply a policy to only a percentage of mail. It is still in the example records on Microsoft's DMARC page and Google's DMARC page, and Microsoft's staged rollout advice is built on stepping pct from 10 to 100.

The new standard adds a t tag as a partial replacement, along with np and psd. None of the three mailbox providers' pages read for this article says how it treats pct under the new standard. A record without pct behaves the same under both, since the old default was 100.

Does an SPF record have a size limit?

Yes, and it is counted in DNS lookups, not characters. RFC 7208 section 4.6.4 says implementations "MUST limit the total number of those terms to 10", and must return a permanent error beyond that. The terms that count are include, a, mx, ptr, exists and redirect.

Each include can trigger further lookups inside the record it points to. Microsoft's page notes that "having fewer than 10 include: statements doesn't guarantee fewer than 10 DNS lookups". A company with a mail platform, a CRM, a help desk and a billing system can hit the limit without noticing.

From p=none to p=reject

A policy of p=none satisfies the mailbox providers and blocks nothing. Anyone can still send mail that claims to be from your domain.

The UK NCSC's anti-spoofing guidance says a policy of reject "on all of your domains is the best way to prevent spoofing", and reports that many organisations move from quarantine to reject "after about 3 months". US federal agencies were ordered to reach reject within a year by CISA's BOD 18-01 in 2017.

Mail authentication protects the domain, not the mailbox. Stolen passwords remain the other route in, which is why the password rules NIST now prohibits are worth reading alongside this. And if your mail runs on Microsoft 365, the mailboxes need protecting as well as the domain: see Microsoft 365 backup pricing compared.