Why Gmail, Yahoo and Microsoft now require DMARC

20 May 2026 · DMARC Engine · 11 min read

Sometime in early 2024, the rules of sending email changed for everyone. Google and Yahoo announced that bulk senders would have to authenticate their mail with SPF, DKIM and DMARC, or face the consequences. Microsoft followed with its own enforcement timeline. For years, DMARC had been a best-practice recommendation: useful, advisable, the sort of thing a careful administrator set up and a busy one ignored. Now it is a precondition for reaching the inbox at three of the largest mailbox providers on the planet, who between them control where the overwhelming majority of business email lands.

This article explains what actually happened, what each provider requires in precise terms, what the word "require" means when you read the small print (it is not a single on/off switch), the volume thresholds that decide whether the rules apply to you, and a concrete checklist to get compliant without breaking your own mail. The short version is that you need SPF and DKIM passing and aligned, a published DMARC record, and a few hygiene items. The longer version is worth understanding, because the alignment requirement is where most senders quietly fail.

What changed, and why

For most of email's history, authentication was optional. A message with no SPF record, no DKIM signature and no DMARC policy could still reach the inbox. Spam filters leaned heavily on content analysis, sender reputation and IP block lists. Authentication was one signal among many, and a weak one, because so few senders bothered with it that filtering on its absence would have rejected too much legitimate mail.

That calculus flipped. Phishing and business email compromise grew into a multi-billion-pound problem, and the single most effective defence against an attacker impersonating your domain is domain-based authentication. Mailbox providers also wanted a cleaner signal for bulk mail specifically, where the cost of letting spoofed or unwanted messages through is highest and the senders are sophisticated enough to do authentication properly. So Google and Yahoo coordinated a joint announcement, set a date, and started enforcing. Microsoft, which had long published guidance recommending the same controls, formalised its own requirements for high-volume senders into Outlook, Hotmail and Live addresses.

The result is a de facto industry standard. The three providers do not phrase their requirements identically, but they converge on the same core: authenticate with SPF and DKIM, align at least one of them to your visible From domain, publish a DMARC policy, keep complaint rates low, and offer one-click unsubscribe on marketing mail. If you want the background on the protocols themselves, the DMARC product overview and our requirements guide cover the mechanics. Here we focus on the mandate.

What "require" actually means

"Require" sounds binary, as though one day your mail flows and the next it is rejected outright. In practice enforcement is graduated, and understanding the gradient matters because it changes how you detect and respond to a problem.

The first stage is spam-foldering. When a non-compliant message arrives, the provider does not bounce it. It accepts the message and quietly files it in the recipient's Spam or Junk folder. From the sender's side this is invisible: your logs show a 250 OK, the message was delivered, no bounce came back. But a human never sees it unless they go digging through spam. This is the most dangerous failure mode precisely because it is silent. Your delivery dashboard looks healthy while your open rates and reply rates quietly collapse.

The second stage is rejection. As enforcement tightens, or for senders who persistently ignore the requirements or who exceed certain volume and complaint thresholds, providers move from foldering to outright SMTP rejection. Here you do get a bounce, often with a temporary 421 (try again later, effectively throttling) or a permanent 5xx error code carrying an explanatory URL. Gmail returns errors that point at its sender guidelines; Yahoo and Microsoft return their own equivalents. At this point the mail simply does not get delivered, and the failure is at least visible in your bounce logs.

Providers tend to introduce a new rule at the foldering stage, give senders a grace period, then escalate to rejection. The reason to comply now rather than wait for a bounce is that the foldering stage can run for months, and during that time you are losing inbox placement without any alarm going off. The only reliable way to know whether your mail is being foldered is to watch your DMARC aggregate reports, which we will come to.

Google's requirements

Google distinguishes between ordinary senders and bulk senders, defined as those sending roughly 5,000 or more messages per day to Gmail addresses (gmail.com and Google Workspace accounts). The threshold is approximate and counts mail to Gmail recipients specifically, not your total send. Once you have sent close to 5,000 in a day, Google treats you as a bulk sender going forward; you do not drop back out by sending less the next day.

For all senders, Google requires:

• A valid SPF or DKIM record. The bare minimum is that mail is authenticated by at least one of the two.
• Valid forward and reverse DNS (the PTR record of your sending IP must resolve, and resolve back). You can confirm this with the PTR record checker.
• Not sending from a residential or dynamically assigned IP.
• Keeping spam complaint rates low, ideally below 0.10% and never spiking to or above 0.30%, as measured in Google's Postmaster Tools.

For bulk senders, Google adds the harder requirements:

• SPF and DKIM both configured, not just one.
• A published DMARC policy. The policy can be as light as p=none to satisfy the rule, but it must exist.
• Alignment: the domain in the message's visible From header must align with either the SPF-authenticated domain or the DKIM-signing domain. This is the requirement that catches people out, covered in detail below.
• One-click unsubscribe for subscribed (marketing) mail, implemented with the List-Unsubscribe and List-Unsubscribe-Post headers, with the unsubscribe honoured within two days.
• Sending only authenticated, wanted mail that conforms to the relevant Internet message format standards.

A p=none DMARC record is enough to tick the compliance box, but it gives you no protection against spoofing and no enforcement. It is a starting line, not a destination. The point of p=none is to begin collecting reports so you can move safely towards p=reject.

Yahoo's requirements

Yahoo (which also operates AOL and a range of regional mailbox brands) published requirements that mirror Google's closely, by design, since the two announced together. Yahoo applies them to bulk senders without committing to a single hard public number the way Google does; the practical guidance lands in the same 5,000-messages-per-day region for triggering bulk treatment, and Yahoo reserves the right to apply requirements to any sender.

Yahoo requires bulk senders to:

• Authenticate with both SPF and DKIM.
• Publish a DMARC policy of at least p=none.
• Achieve DMARC alignment through SPF or DKIM.
• Maintain low spam complaint rates (the same sub-0.3% expectation, with under 0.1% as the healthy target).
• Provide one-click unsubscribe on marketing mail and process opt-outs promptly.
• Send mail that recipients actually want, with valid forward and reverse DNS on the sending infrastructure.

Yahoo's enforcement, like Google's, started with foldering and rate-limiting and has tightened over time. Because the two providers share a rulebook, a sender who is compliant for Gmail is almost always compliant for Yahoo, which is part of why the joint announcement was so effective at moving the industry.

Microsoft's requirements

Microsoft enforces its own version for high-volume senders into consumer Outlook domains: outlook.com, hotmail.com, live.com and msn.com. Microsoft's threshold is higher than Google's: it targets senders pushing roughly 5,000 or more messages per day into those domains as the point where the requirements begin to apply with enforcement, having framed its rollout around protecting those personal mailboxes.

Microsoft requires qualifying senders to have:

• SPF that passes for the sending domain.
• DKIM signing that validates.
• A published DMARC record with at least p=none, where DMARC passes by aligning to SPF or DKIM.

Microsoft's stated enforcement path is the now-familiar one: non-compliant bulk mail is routed to Junk first, with the warning that continued non-compliance leads to rejection. Microsoft has been explicit that foldering is the initial penalty and that it intends to escalate. The notable point for senders is that Microsoft's reputation systems and its routing into the Junk folder operate somewhat differently from Google's, so it is entirely possible to look fine at Gmail and still be foldered at Outlook if, for example, your DKIM alignment is correct but your sending IP reputation with Microsoft is poor. Treat the three providers as three separate exams that happen to share a syllabus.

The part that catches everyone: alignment

You can have a perfectly valid SPF record and a perfectly valid DKIM signature and still fail DMARC. This is the single most common reason a sender believes they are compliant and is not. The cause is alignment.

DMARC does not simply ask "did SPF pass?" and "did DKIM pass?". It asks whether the domain that passed is the same domain the recipient sees in the From address. That is the whole point of DMARC: it ties authentication to the visible identity, so an attacker cannot pass authentication on a domain they control while displaying yours in the From line.

There are two flavours:

• SPF alignment compares the domain in the SMTP envelope sender (the MAIL FROM, also called the Return-Path or bounce address) with the From header domain. SPF passes against the envelope domain, but DMARC only counts it if that envelope domain matches your From domain.
• DKIM alignment compares the domain in the DKIM signature's d= tag with the From header domain. DKIM passes cryptographically for whatever domain signed it, but DMARC only counts it if the signing domain matches your From domain.

DMARC passes if either SPF or DKIM is both valid and aligned. You do not need both to align; one is enough. But you need at least one.

Here is the classic failure. You send marketing mail through a provider such as a CRM or an email platform. Your From address is news@yourbrand.com. The platform sets the envelope sender to something like bounces@mail.theplatform.com so that bounce handling stays on their side. SPF therefore passes for theplatform.com, not for yourbrand.com, so SPF is not aligned. If you have not set up DKIM signing with your own domain in the d= tag, DKIM either does not run or signs as theplatform.com, so DKIM is not aligned either. Both underlying checks pass. DMARC fails. To Gmail, Yahoo and Microsoft, that mail is non-compliant.

The fix is almost always to configure DKIM with your own domain. Every reputable sending platform supports this: they give you a few CNAME or TXT records to publish in your DNS, after which they sign your mail with d=yourbrand.com. That produces DKIM alignment regardless of what the envelope sender is, which is exactly why DKIM is the more robust of the two for mail that passes through third parties. You can verify what a given platform is actually signing with the DKIM checker, and confirm the From-domain alignment outcome end to end with the DMARC checker.

There is a relaxed-versus-strict dimension too. DMARC's default alignment mode is relaxed, which treats a subdomain as aligned with the organisational domain (so mail.yourbrand.com aligns with yourbrand.com). Strict mode demands an exact match. Relaxed is the sensible default and is what the providers expect; you would only choose strict in specific, well-understood circumstances.

A concrete compliance checklist

Work through these in order. Each step builds on the last, and the order matters because publishing an enforcing DMARC policy before your legitimate mail is aligned will block your own messages.

1. Inventory every source that sends as your domain. Your own mail server, Google Workspace or Microsoft 365, your CRM, your transactional email provider, your invoicing tool, your help desk, your marketing platform, any subsidiary or agency that sends on your behalf. You cannot authenticate sources you do not know about. Aggregate DMARC reports are the best discovery tool for the ones you forgot.

1. Publish a correct SPF record. One TXT record per domain, listing every authorised sending source, ending in ~all (soft fail) or -all (hard fail). Watch the ten-DNS-lookup limit: SPF that resolves to more than ten lookups returns a permerror and breaks. If you are near the limit, flatten or restructure. Check it with the SPF checker, and see the SPF product page for the lookup-limit detail.

1. Set up DKIM signing on every source, using your own domain. This is the step that produces alignment. For each platform, publish the DKIM DNS records they provide and confirm the signature validates with your domain in d=. Use the DKIM checker to verify each one. Do not skip a source because it is low-volume; one unaligned source can drag down your domain's reputation and, once you reach enforcement, will have its mail rejected.

1. Publish a DMARC record at p=none with reporting on. Start with v=DMARC1; p=none; rua=mailto:reports@yourdomain.com. The rua address is where aggregate reports are delivered. This is non-enforcing: it changes nothing about how your mail is handled, but it begins the flow of data that tells you which sources are aligned and which are not. See the DMARC product page for the full tag breakdown.

1. Read the aggregate reports for a few weeks. These XML reports, sent daily by each receiving provider, show you every source sending as your domain, the volume from each, and whether SPF and DKIM passed and aligned. This is where you find the forgotten subsidiary, the misconfigured invoicing tool, the marketing platform that never had DKIM set up. Raw DMARC XML is unreadable by hand; our monitoring service parses it into a plain account of what is passing, what is failing and which source is responsible, with alerts when something changes.

1. Fix every legitimate source until it aligns. Work down the list from the reports. For each failing legitimate source, add DKIM signing or correct SPF until DMARC passes for it. Do not move on until the reports show your real mail authenticating cleanly. This is the bulk of the work and the reason the whole process is staged rather than done in an afternoon.

1. Add one-click unsubscribe to marketing mail. Implement List-Unsubscribe and List-Unsubscribe-Post headers so recipients can opt out in one click, and honour those requests within two days. This is a hard requirement for subscribed mail at Google and Yahoo, separate from authentication.

1. Keep complaint rates down. Monitor Google Postmaster Tools and the equivalent feedback loops. Stay below 0.1% spam complaints; never approach 0.3%. Send only to people who asked, segment inactive recipients, and make unsubscribing easier than reporting spam.

1. Move the policy to p=quarantine, then p=reject. Once the reports confirm your legitimate mail is fully aligned, raise the policy. Quarantine sends failing mail to spam; reject blocks it. You can ramp gradually with the pct tag (for example p=quarantine; pct=25) to apply the policy to a quarter of failing mail first and watch the effect. The goal is p=reject, which is the only policy that actually stops attackers spoofing your domain, and the one that fully satisfies the spirit of the requirements rather than just the letter.

Why getting to enforcement is the real goal

A p=none record satisfies the published rule at all three providers, and you could stop there. You should not. p=none tells receivers "do whatever you would have done anyway"; it provides reporting but no protection. Anyone can still send mail with your domain in the From line and have it land in inboxes. The reason the providers built their requirements on DMARC is that DMARC at enforcement (p=quarantine or p=reject) is what stops impersonation. Meeting the minimum gets you into the inbox; reaching enforcement keeps attackers out of it.

The honest difficulty is step 6: identifying and fixing every legitimate source before you turn on enforcement, without accidentally blocking a payroll system or a support tool you forgot about. That is the work that takes weeks of reading reports, and it is where most do-it-yourself DMARC projects stall at p=none indefinitely.

The practical takeaway

Gmail, Yahoo and Microsoft moved DMARC from advice to requirement because authentication is the most effective defence against domain impersonation, and they have the leverage to insist on it. "Require" means foldering first, then rejection, with the foldering stage silent enough to cost you inbox placement long before you notice. Compliance rests on three pillars: SPF and DKIM both passing, at least one of them aligned to your From domain, and a published DMARC policy, plus complaint-rate discipline and one-click unsubscribe for marketing mail. Alignment is where most senders unknowingly fail, and DKIM with your own domain is usually the fix.

Start by checking exactly where you stand today. Run your domain through the DMARC checker, the SPF checker and the DKIM checker to see what passes and what aligns. If the reports look daunting, or you want to reach p=reject without taking your own mail down in the process, our done-for-you service takes a domain from p=none to enforcement safely, and the monitoring service keeps it there with alerts the moment something changes.