18 June 2026 · The DMARC Engine Team · 11 min read
A deadline that actually moved the needle
For two decades, email authentication was the broccoli of internet infrastructure: everyone agreed it was good for you, almost nobody bothered. SPF was published in 2006, DKIM in 2007, DMARC in 2015. By late 2023, a large share of legitimate senders still had no DMARC record at all, and a sizeable chunk of those that did were running p=none, which asks receivers to do precisely nothing. The standards existed. The adoption did not.
Then Google and Yahoo did something the standards bodies never could. In October 2023 they announced that, from 1 February 2024, bulk senders would have to authenticate their mail properly or watch it stop arriving. Microsoft followed with comparable rules for Outlook.com, Hotmail and Live.com, phased in through 2025. A voluntary best practice became a condition of delivery to roughly half of all consumer inboxes on the planet.
This is a retrospective on what that mandate actually changed. Not the press-release version, but what happened to real mail from real senders: what the rules required, how non-compliant messages were treated, the specific ways domains failed, how to check your own posture today, and where the major mailbox providers are pushing next.
What the rules actually said
The requirements split into two tiers. Almost everyone got the baseline. Bulk senders got the full set.
For every sender, regardless of volume, Gmail and Yahoo expected:
- Either SPF or DKIM to pass. A message with neither, sent to a personal Gmail or Yahoo address, became a candidate for rejection rather than just a trip to the spam folder.
- Valid forward and reverse DNS (PTR) records on the sending IP, so the connecting server's hostname resolves and matches.
- Messages sent over TLS.
- Spam rates kept low, monitored by senders, ideally below 0.1% and never spiking toward 0.3%.
- No impersonation of Gmail
From:headers, which Gmail began enforcing with aquarantine-style treatment of its own domain.
For bulk senders, defined as those sending close to 5,000 or more messages a day to Gmail accounts (counted across a primary domain and its subdomains, and never really un-counted once you cross it), the bar rose sharply:
- SPF and DKIM both configured, not one or the other.
- A published DMARC record on the organisational domain, even if only at
p=noneto start. - DMARC alignment: the domain in the visible
From:header must align with the domain validated by SPF or DKIM. Authentication that passes for some unrelated bounce domain does not count. - One-click unsubscribe on marketing and subscribed messages, implemented with
List-UnsubscribeandList-Unsubscribe-Postheaders per RFC 8058, with the unsubscribe honoured within two days. - A spam complaint rate kept under 0.3% as measured in Google Postmaster Tools, with 0.1% as the real target. Cross 0.3% and delivery degrades fast.
The alignment clause is the one that caught people out, so it is worth being precise. SPF checks the Return-Path (envelope sender). DKIM checks whatever domain signed the message in the d= tag. DMARC ignores both of those in isolation and asks a different question: does either of them match the domain your recipient actually sees in the From: line? You can pass SPF and DKIM with flying colours and still fail DMARC because nothing aligned with your From: domain. That distinction is the entire point of DMARC, and it is exactly where a lot of otherwise well-configured mail collapsed.
What happened to mail that did not comply
The enforcement was deliberately gradual, which is the main reason it did not break the internet.
In the first weeks of February 2024, Gmail began returning temporary errors (4xx SMTP responses) for a small percentage of non-compliant bulk mail. A temporary error tells the sending server to try again later, so nothing was lost outright; it was a warning shot with a delay attached. Senders watching their logs saw deferrals climb. Senders who were not watching saw nothing, which was the problem.
Through the spring, that percentage of rejected traffic ratcheted up, and the temporary failures hardened into permanent ones (5xx), the kind that produce a bounce and never retry. By around April 2024 the message was unambiguous: bulk mail without SPF, DKIM and an aligned DMARC record to Gmail was being refused at the door. The classic failure mode for messages that did authenticate but looked spammy, or carried a high complaint rate, was the spam folder; the failure mode for messages that did not authenticate at all was non-delivery.
Yahoo ran a parallel track on a similar timeline. Microsoft's enforcement for Outlook.com, Hotmail and Live arrived later. In 2025 Microsoft began routing non-compliant bulk mail (again, the ~5,000-a-day threshold) to the Junk folder rather than rejecting it outright at first, giving senders a softer landing before tightening toward refusal. The pattern across all three was the same: a grace period of degraded placement, then deferrals, then hard rejection, each step published in advance.
The practical upshot for a business: if your invoices, password resets and receipts depended on Gmail or Yahoo or Outlook delivery, and you were a bulk sender who had ignored authentication, you had a window of a few months where things quietly got worse before they failed completely.
The five ways domains actually failed
Across the audits we ran in this period, non-compliance was rarely exotic. It clustered into a handful of recurring mistakes.
1. DKIM was never set up, or was set up on the wrong domain
Plenty of senders had SPF, because their mail platform configured it during onboarding, but had skipped DKIM entirely or never rotated to a proper signing domain. Under the old regime, SPF-only was survivable. Under the new one, a bulk sender needs both, and SPF alone does not survive forwarding (a mailing list or a forward to my other account rule rewrites the path and breaks SPF, leaving DKIM as the only thing holding authentication together). Where DKIM was present but signed with a d= belonging to the email platform rather than the sender's own domain, it authenticated but failed to align, which brings us to the next failure.
2. SPF or DKIM passed but did not align
This was the single most common surprise. A company sending through a marketing platform would see spf=pass and dkim=pass in the headers and assume all was well. But the SPF pass validated the platform's bounce domain (bounces.sendingplatform.net), and the DKIM signature carried the platform's d=, while the From: header said @yourcompany.com. DMARC requires alignment with that From: domain. Nothing aligned, so dmarc=fail. The fix is to authenticate on your own domain: a custom Return-Path (or MAIL FROM) subdomain that you delegate, and a DKIM key published under your domain so the d= matches.
3. SPF with too many DNS lookups
SPF has a hard limit of ten DNS lookups when a receiver evaluates the record. Each include: for a vendor (your email platform, your CRM, your helpdesk, your invoicing tool, your newsletter tool) burns lookups, and the popular vendors each chain further includes of their own. Companies that had accumulated a dozen tools over the years quietly blew past ten, at which point SPF returns permerror and is treated as a failure. The record looked fine to the human eye and was broken to the machine. Flattening the record, or consolidating sending domains, was the remedy.
4. Multiple SPF records, or syntax that voids the record
The spec permits exactly one SPF TXT record per domain. We repeatedly found two, sometimes three, left behind by different teams or different vendor setup wizards. Two SPF records is not additive; it produces a permerror and authentication fails. The same outcome came from stray syntax: a +all that authorised the entire internet, a misplaced ~all after a -all, or a typo in an include.
5. A From: domain with no DMARC record at all
The bulk-sender rule made a published DMARC record mandatory, but a startling number of active sending domains had none. Worse were the domains that published DMARC on the apex but sent their transactional mail from a subdomain with no record and no explicit policy, relying on inheritance they had misread. DMARC policy is inherited by subdomains through the sp tag, but the alignment and the published record still have to be correct for the domain in the From: line.
If you recognise your own setup in any of these, the fastest way to confirm is to check the live DNS rather than trust memory. Our DMARC checker, SPF checker and DKIM checker read the actual published records and flag the exact failure, including the SPF lookup count and whether your records align.
How to check your own compliance now
The same checklist tells you where you stand, whether you send 500 messages a month or 500,000. Run it against every domain and subdomain you send from, because the rules count subdomains toward the bulk threshold and enforce per-From:-domain.
1. Confirm SPF exists, is singular, and is valid. One TXT record, starting v=spf1, ending in -all or ~all, and resolving in ten lookups or fewer. If you are not sure of the lookup count, a checker will count it for you. The SPF checker reports the count and the chain.
2. Confirm DKIM is signing with your domain. Find the selector your platform uses (it appears in the s= tag of the DKIM-Signature header of any message you send), then verify the public key is published at selector._domainkey.yourdomain.com. The signing d= should be your domain, not the platform's, so the signature can align. The DKIM checker validates the published key for a given selector.
3. Confirm DMARC is published and aligned. Look up _dmarc.yourdomain.com. You want at least v=DMARC1; p=none; rua=mailto:reports@yourdomain.com to start, with a reporting address so you can actually see what is happening. Then read the reports: they tell you which sources are passing alignment and which are not. Our DMARC checker parses the record, and the DMARC report analyzer turns the raw XML aggregate reports into a readable picture of who is sending as you.
4. Confirm one-click unsubscribe on marketing mail. Send yourself a campaign and inspect the headers for List-Unsubscribe and List-Unsubscribe-Post: List-Unsubscribe=One-Click. The unsubscribe link must work without forcing a login or a multi-step form, and the request must be honoured within two days.
5. Watch your complaint rate. Enrol the domain in Google Postmaster Tools and keep the spam rate under 0.1%. The single fastest way to spike it is buying lists or mailing people who never opted in; the slowest-burning version is failing to remove people who unsubscribed.
If you would rather see the whole posture for several domains at once, the bulk domain scanner checks SPF, DKIM, DMARC, MTA-STS and more across a list in one pass, and the spoofing risk calculator translates a weak policy into the concrete exposure it leaves open. The full provider checklist also lives on our requirements page.
The trap inside p=none
The mandate let bulk senders satisfy the DMARC requirement with p=none. That was a pragmatic choice: it got millions of domains to publish a record without risking mass false-positive rejections on day one. But it created a false sense of completion, and it is the single biggest piece of unfinished business a year on.
p=none publishes a DMARC record and asks receivers to take no enforcement action. It satisfies the letter of the requirement. It does nothing to stop someone spoofing your domain, because you have explicitly told the world's mailbox providers not to act on failures. The protection that DMARC was invented to provide only switches on at p=quarantine and p=reject. A domain stuck at p=none is a domain that ticked the compliance box and left the front door open.
The reason most domains stay at p=none is fear, and the fear is legitimate. Move straight to p=reject while a forgotten sending source (a CRM, a billing system, an office printer, a third-party that mails on your behalf) is still failing alignment, and you will silently destroy your own legitimate mail. The discipline that prevents this is unglamorous: publish p=none with reporting, read the aggregate reports for several weeks until you can account for every legitimate source, fix alignment on each one, then raise the policy in stages, often using the pct tag to ramp enforcement to a fraction of mail before applying it to all of it.
That staged journey from p=none to p=reject, with no outage, is precisely what our DMARC product is built to run for you, and the monitoring keeps watching afterward so a new sending source or a quietly broken record does not undo the work. If you prefer to drive it yourself, the DMARC report analyzer is where the raw reports become a plan.
Where enforcement is heading next
The 1 February 2024 deadline was a floor, not a ceiling. Three directions are now clear.
More mailbox providers, same rules. Microsoft's 2025 rollout for Outlook.com and Hotmail proved the Google and Yahoo template is becoming the industry baseline rather than a two-provider quirk. Apple's iCloud Mail, regional providers and corporate filters increasingly evaluate the same signals. The safe planning assumption is that any consumer or business mailbox of consequence now expects aligned SPF, DKIM and DMARC, and that the threshold for triggering the strict rules will drift downward over time. Designing for the bulk-sender bar even if you are below it is simply future-proofing.
Pressure to move off p=none. The providers have been explicit that p=none was a starting point. Industry guidance and procurement requirements (security questionnaires, cyber-insurance forms, vendor risk reviews) increasingly ask for an enforced policy, and some sectors and government frameworks already mandate p=reject. The direction of travel is that publishing a record will stop being enough and enforcing it will become the expectation.
Hosted alignment up and down the stack: MTA-STS, TLS-RPT and BIMI. Two further controls are moving from optional to expected. MTA-STS tells sending servers to require TLS for mail to your domain and to refuse to downgrade, closing a man-in-the-middle gap that plain opportunistic TLS leaves open; pair it with TLS-RPT to get reports when a connection cannot be secured. You can check both with the MTA-STS checker and our TLS-RPT checker, and run them properly with the MTA-STS product. BIMI, which displays your verified logo next to authenticated mail, is the carrot at the end of the journey: it requires p=quarantine or p=reject to qualify, so it gives marketing and brand teams a tangible reason to finish the enforcement work that security teams have been requesting. See the BIMI product for what that involves, including the Verified Mark Certificate most providers now expect.
The throughline is that authentication is becoming load-bearing. It used to be a hygiene item you could defer; it is now a precondition for your mail arriving, for your brand showing up correctly, and for passing the security reviews your customers run on you.
The practical takeaway
A year on, the Google and Yahoo rules did what twenty years of standards advocacy could not: they made email authentication mandatory in practice, and they did it without breaking the internet, by ramping enforcement from spam-foldering to deferral to rejection over a matter of months. Microsoft has confirmed the template is the new normal.
The mistakes that caused mail to fail were not exotic. Missing DKIM, authentication that passed but did not align with the From: domain, SPF records that exceeded ten lookups or duplicated themselves, and From: domains with no DMARC record at all accounted for the overwhelming majority. Every one of those is detectable in minutes and fixable in days.
The unfinished business is p=none. Millions of domains published a record to clear the bar and stopped there, which satisfies the providers but leaves the spoofing protection switched off. Finishing the job means reading your DMARC reports, accounting for every legitimate sender, and raising the policy to p=reject in controlled steps without dropping a single real message.
Start by checking exactly where your domain stands today with the free DMARC checker, or scan everything you own at once with the bulk domain scanner. When you want the move from p=none to p=reject handled safely, with no email outage and ongoing change alerts, that is what our done-for-you DMARC service and monitoring are for.