Google and Yahoo made DMARC enforcement mandatory for large-volume senders in 2024, and since May 2025 Microsoft has done the same for its Outlook.com, Hotmail.com and Live.com consumer domains. In many Microsoft 365 environments I work in, that has created a new sense of urgency. Until recently, most organisations published a p=none DMARC record on their domains mainly so they had one. Now, if you send more than 5,000 emails a day, DMARC, SPF and DKIM (aligned!) are no longer best practice. They are prerequisites. Moving from p=none to quarantine or reject is not something you do by flipping a switch, though. If you haven't carefully inventoried every legitimate sender, including each newsletter platform, helpdesk system and multi-function device, some of your genuine email will disappear without a trace.

Microsoft now requires aligned SPF, DKIM and a DMARC record for bulk mail

Since 5 May 2025, Microsoft has required anyone sending volume mail to Outlook.com (and Hotmail.com/Live.com) addresses to have SPF and DKIM correctly configured and aligned, along with a DMARC record, even if that record only says p=none. That is the bare minimum, and Microsoft's DMARC documentation is very clear about it. The step to p=quarantine or p=reject is where it gets serious. A configuration mistake or a forgotten third-party sender means mail simply doesn't arrive. If you're still unsure about the basics of SPF, DKIM and DMARC, my practical guide SPF, DKIM & DMARC for Exchange Online: DNS done right walks through the setup with a focus on Exchange Online.

Third-party senders need a full inventory and proper alignment

The hardest part of DMARC enforcement, by a wide margin, is sorting out all the systems that send email "as" your domain. I mean SaaS newsletter tools, ticketing platforms and CRM systems, but also copy machines and cloud apps that use SMTP relay. Some of them support DKIM these days, although the documentation is usually thin. After a few long troubleshooting sessions, my advice is this: really inventory every legitimate source before moving to p=quarantine or p=reject, and check each one for SPF and, ideally, DKIM support. Pay particular attention to systems using so-called "Direct Send", which bypass Exchange Online. Otherwise you'll run into the problems I described in Reject Direct Send: Real anti-phishing for Exchange domains.

Pro tip: Start collecting DMARC aggregate reports while you're still at p=none. They surface unknown or misconfigured senders quickly, and on small domains a simple spreadsheet is enough for a first pass.

Aggregate reports tell you which senders, source IPs and authentication failures deserve your attention. If you send them to an analysis tool such as Dmarcian or Postmark, you get a clear picture without much effort.

DKIM for Exchange Online is enabled in the Defender portal

Microsoft has finally made DKIM configuration in the Defender portal straightforward, even in environments with several domains and subdomains. For Exchange Online, go to Defender portal → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. There you can see the DKIM status of each domain and turn on signing once the required CNAMEs are in your DNS. A common situation: Microsoft signs your main domain, but a marketing tool sends from a subdomain. In that case you'll usually need a custom DKIM key, which you can also enable in the portal after publishing the correct DNS records.

// To add in your domain's DNS: DKIM for Exchange Online
selector1._domainkey  CNAME  selector1-domain-com._domainkey.tenant.onmicrosoft.com
selector2._domainkey  CNAME  selector2-domain-com._domainkey.tenant.onmicrosoft.com

Prerequisite: You need admin rights in the Defender portal and access to your DNS provider. Microsoft's DKIM instructions are clear and current.

Subdomains and parked domains need their own DMARC records

This still gets overlooked in DMARC enforcement projects: DMARC only applies to the domain where it is published. Most DMARC parsing logic treats subdomains separately. If you want to stop attackers from using a parked or rarely used subdomain for phishing, publish an explicit DMARC record with a strict policy, usually p=reject. For domains that never send mail at all ("non-sending domains"), I recommend this record:

_dmarc.parkeddomain.com. IN TXT "v=DMARC1; p=reject; rua=mailto:[email protected]"

It reliably blocks misuse of parked or unused domains. I still come across organisations that leave these doors open, which makes things easy for attackers.

The move from p=none to quarantine and reject happens in stages

The tricky part is getting from p=none to p=quarantine or p=reject without breaking business-critical mail. I treat it as a staged, iterative process, and this is the overview I use in projects:

flowchart TD
    Start["DMARC p=none active"] --> Reports["Collect DMARC aggregate reports"]
    Reports --> Inventory["Inventory sender systems"]
    Inventory --> DKIMCheck["Check DKIM for all senders"]
    DKIMCheck --> Subdomains["Review subdomains & non-senders"]
    Subdomains --> Quarantine["Set policy to p=quarantine"]
    Quarantine --> Reject["Increase policy to p=reject"]

Figure: Moving to DMARC enforcement step by step, from test to production.

Keep watching the DMARC reports after the initial rollout, too. Months later, it's quite common to find a forgotten system or a newly introduced SaaS tool that suddenly fails DMARC. Also keep in mind that users reporting missing emails are often the first indication that a sender slipped through during enforcement.

I treat DMARC enforcement as a governance discipline

DMARC enforcement is not a one-off technical fix. It's an ongoing governance task. If you know your mail flows, your third-party senders and your domains, you'll be fine, but getting to that point takes effort. What matters most is having processes that bring new SaaS tools, subdomains and hybrid setups into scope early. Once SPF, DKIM and DMARC are properly in place, you're in a better position for future regulatory changes and far more resilient against phishing.