Google, Yahoo, Microsoft & PCI requirements

For years, email authentication was a best-practice that most senders quietly ignored. That changed on 1 February 2024, when Google and Yahoo started enforcing rules for bulk senders. Microsoft followed with its own consumer-mailbox requirements, and PCI DSS 4.0 made anti-phishing controls mandatory for any organisation handling card data. This page sets out exactly what each provider and standard asks for, who it applies to, and what you need to do to stay deliverable and compliant.

The common thread is simple: senders are now expected to prove their mail is genuine. SPF and DKIM verify the sending infrastructure; DMARC ties that proof to the visible From domain and tells receivers what to do when a message fails. None of these requirements are exotic. They are the same standards a careful mailbox provider has always wanted, now backed by policy and enforcement.

Google (Gmail): bulk-sender rules since 1 February 2024

Google's requirements apply to anyone sending email to Gmail addresses. The strictest rules target bulk senders, defined as roughly 5,000 or more messages a day to Gmail (counted across your domains, not per address). Hit that threshold and the following are mandatory.

• SPF and DKIM. Both must be set up, and at least one must pass with alignment. In practice you want both passing, because SPF breaks on forwarding while DKIM survives it.
• A DMARC record. A published policy of p=none is the minimum, but the record must exist and your mail must achieve DMARC alignment. Alignment means the domain that passes SPF or DKIM matches the domain in the visible From header.
• One-click unsubscribe. Marketing and subscribed messages must support RFC 8058 one-click unsubscribe, with a working List-Unsubscribe and List-Unsubscribe-Post header, and the request must be honoured within two days.
• Valid forward and reverse DNS. Your sending IP needs a PTR record (reverse DNS) that resolves, and that hostname should resolve back to the same IP.
• A spam complaint rate kept low. Google asks senders to stay below a 0.3% spam rate in Postmaster Tools, and to avoid ever reaching 0.3% even briefly. A clean rate sits closer to 0.1%.

The penalty for non-compliance is not a polite warning. Messages that fail these checks are rejected with a temporary error or sent to spam, and the effect compounds: a poor reputation makes every future send harder. If you do not have access to Postmaster Tools, set it up so you can see your authentication results and complaint rate from Google's side of the connection.

Yahoo: aligned with Google on the same timeline

Yahoo announced its requirements jointly with Google and applied them on the same date, 1 February 2024. The substance is effectively identical, so you do not need a separate strategy for Yahoo mailboxes (which include Yahoo Mail, AOL, and several regional brands).

• SPF and DKIM in place, with DMARC alignment on your mail.
• A published DMARC record, p=none at minimum.
• One-click unsubscribe for bulk and marketing mail, honoured promptly.
• Valid reverse DNS on the sending IP and low spam-complaint rates.

Because the two providers move together, treating Gmail compliance as your baseline gets you Yahoo compliance at the same time. The practical difference is reporting: Yahoo's sender tooling is less detailed than Postmaster Tools, so your DMARC aggregate reports become the better signal for how Yahoo is treating your mail. That is one more reason to publish a working rua= address and actually read what comes back.

Microsoft (Outlook.com, Hotmail, Live): high-volume rules rolling out from 2025

Microsoft announced in 2025 that high-volume senders to its consumer mailboxes, meaning Outlook.com, Hotmail and Live addresses, must pass SPF, DKIM and DMARC. The high-volume threshold is described as roughly 5,000 or more messages a day, in line with the Google and Yahoo bar.

Microsoft has been rolling this out in stages and the timing should be treated cautiously rather than as a single hard cut-off. The company began applying the rules by routing non-compliant mail to the Junk folder first, with outright rejection signalled to follow. That phased approach gives senders a window to fix authentication before mail is refused outright, but it is not a reason to wait. Junked mail is unread mail.

• SPF must be configured and pass for your sending domain.
• DKIM must sign your messages with a valid signature.
• DMARC must be published with a policy of at least p=none and your mail must align.

Microsoft has also pointed senders towards the same hygiene practices as Google and Yahoo: accurate From addresses, functional unsubscribe handling, and low complaint volumes. If you have already met the Gmail and Yahoo bar, the Microsoft requirements should need little or no extra work on the authentication side. The one thing to confirm is that DKIM is enabled and aligned for every stream that reaches consumer Outlook addresses, including any third-party platforms sending on your behalf.

PCI DSS 4.0 requirement 5.4.1: anti-phishing, mandatory from 31 March 2025

The provider rules are about reaching the inbox. PCI DSS is about audit and obligation, and it brings DMARC into a different conversation: the security review.

PCI DSS 4.0 introduced requirement 5.4.1, which calls for mechanisms and processes to protect personnel against phishing attacks. It was a future-dated requirement during the transition period and became mandatory on 31 March 2025. Any organisation that stores, processes or transmits cardholder data, or that can affect the security of that data, is in scope.

DMARC is the recognised technical control for the spoofing side of this requirement. By preventing attackers from sending mail that appears to come from your own domains, an enforced DMARC policy reduces the chance that staff receive convincing phishing that impersonates internal senders or trusted partners. A fake invoice from accounts@yourcompany.com, landing in a finance inbox, is exactly the attack an enforced policy is designed to stop.

Assessors expect enforcement, not a parked record

This is the point that catches organisations out. Publishing v=DMARC1; p=none demonstrates intent but blocks nothing. A QSA or internal assessor looking at requirement 5.4.1 wants evidence that spoofed mail is actually being stopped, which means a policy of p=quarantine or p=reject with full alignment. A monitoring-only record is a control on paper, not in practice.

• Protect your domains, not just your main one. Parked and look-alike domains you own should publish an enforcing DMARC record too, so they cannot be used to impersonate the brand.
• Be ready to show records and reports. Assessors may ask for the published policy and for evidence that you monitor authentication results, which is where DMARC aggregate reporting provides the paper trail.
• Treat it as brand protection, not just a tick-box. The same enforcement that satisfies an assessor also stops customers and suppliers receiving phishing that wears your name.

Anti-spoofing controls now appear well beyond PCI too. Cyber-insurance questionnaires routinely ask whether DMARC is enforced, and vendor security reviews increasingly check for it before signing. An enforced policy is becoming a baseline expectation of doing business, not a nice-to-have. See our compliance overview for how these obligations connect.

All requirements at a glance

The table below consolidates who is affected, what is required, and when each rule took effect. Use it to confirm coverage rather than as a substitute for each provider's own published guidance.

What this means for you

The four requirements above point in the same direction. Whether you are chasing inbox placement at Gmail or evidence for a PCI assessor, the work is the same, and it falls into three steps.

1. Authenticate everything you send

Map every system that sends mail using your domain: your mail platform, your CRM, billing, support, marketing tools, and any vendor sending on your behalf. Each one needs to pass SPF or DKIM with alignment. SPF has a hard limit of 10 DNS lookups under RFC 7208, and exceeding it returns permerror, so a record that has grown to 11 lookups silently fails. If you are near the limit, flattening the includes to IP ranges keeps you under it. DKIM should sign with a 2048-bit key published at a selector such as s1._domainkey.yourcompany.com, with the signing d= domain matching your From domain.

2. Get to enforcement

Most domains that publish DMARC stop at p=none, so they watch but never block. That meets the inbox-provider minimum, but it does not protect you from spoofing and it does not satisfy PCI assessors. Move through the policy stages deliberately: start at p=none to gather data, confirm every legitimate stream is aligned, then raise to p=quarantine and finally p=reject. Our guide to reaching enforcement walks through the sequencing so you do not block your own mail on the way.

3. Keep monitoring

Authentication is not a one-off project. New tools get added, vendors change their sending infrastructure, and a quiet misconfiguration can start failing alignment without anyone noticing until deliverability drops. Keep a working rua= address collecting aggregate reports and review them so you catch problems while they are small. A poor spam rate or a broken DKIM key is far cheaper to fix in a report than after Gmail starts junking your invoices. Our deliverability guide covers how authentication and reputation interact.

None of these requirements are going away, and the direction of travel is clear: monitoring-only is becoming the floor, and enforcement is becoming the expectation. The organisations that act now treat it as routine infrastructure. The ones that wait tend to discover the problem the hard way, when a campaign lands in spam or an assessor asks for evidence that is not there. Set the records up once, get to an enforcing policy, and keep an eye on the reports. That single piece of work answers Google, Yahoo, Microsoft and PCI DSS at the same time.