What this check looks at
Checks each custom domain publishes a DMARC record with a quarantine or reject policy applied to all mail.
DMARC is a TXT record at _dmarc.<domain> that tells receiving mail systems what to do with a message whose From address uses the domain but which fails both SPF and DKIM alignment: p=none (deliver, and report only), p=quarantine (treat as suspicious, usually the junk folder) or p=reject (refuse it). It also names where receivers send aggregate reports (rua). Microsoft 365 does not create it; without one, receivers decide for themselves, and most deliver.
The check reads public DNS for every custom domain. It fails a domain with no DMARC record or with a record that has no valid policy, warns at p=none (monitoring only), and warns when the pct tag applies the policy to less than 100% of mail. It passes at p=quarantine or p=reject applied to all mail. The evidence shows each domain’s current record and the record to publish.
SPF on its own checks only the envelope sender, which the recipient never sees; DMARC ties authentication to the From address people read. Without an enforcing policy an attacker can send as accounts@ the organisation’s domain to customers, suppliers and staff, and it passes many filters. The p=none stage is meant to last a few weeks of reporting, but many domains are left there for years.
Why it matters
DMARC is what tells receiving mail systems to act on SPF and DKIM failures. Without an enforcing policy, spoofed mail from the organisation's own domain is still delivered — to customers, suppliers and its own staff.
Spoofing the organisation’s own domain is the cheapest route into invoice fraud: a message to the finance team apparently from the managing director asking for an urgent payment, or a message to customers from the accounts address with new bank details. At p=reject, major receivers such as Microsoft, Google and Yahoo refuse those messages outright; with no DMARC, they arrive looking genuine.
The cost lands twice, in fraud and in deliverability. Google and Yahoo have required a DMARC record from bulk senders since 2024, and mailbox providers use DMARC to judge how far to trust a domain. A domain without a policy sees more genuine mail junked while criminals use its name freely.
The CIS Microsoft 365 Foundations Benchmark (2.1.10) asks for DMARC on all Exchange Online domains, CISA SCuBA asks for a DMARC record on every domain (MS.EXO.4.1) at p=reject (MS.EXO.4.2), CIS Controls v8 9.5 is Implement DMARC, and the Essential Eight lists email content filtering and authentication. The NCSC’s email security guidance recommends working towards p=reject, including for domains that do not send mail.
How to fix it
Where: Your DNS provider
Before you start
- Make sure SPF and DKIM are in place for every sender first.
- Start with p=none and a rua reporting address, and read the reports for a few weeks.
Step by step
- Make sure every sender passes SPF or DKIM. Before enforcing, every legitimate service sending as the domain must pass SPF or DKIM with the domain aligned to the From address. Complete the SPF and DKIM findings first, and for third-party senders (marketing, CRM, invoicing) set up their DKIM signing with your domain, because their SPF usually uses their own envelope domain and does not align.
- Choose where the reports go. Aggregate reports are XML files that receivers send daily. Use a DMARC reporting service (several have free tiers for small volumes) or a dedicated mailbox, not a person’s inbox. If the report address is on a different domain from the one protected, that domain must publish an authorisation record (<yourdomain>._report._dmarc.<reportdomain> TXT "v=DMARC1"); reporting services do this for you.
- Publish a monitoring record. At the DNS host add a TXT record with the host name _dmarc and the value v=DMARC1; p=none; rua=mailto:<reporting address>. Keep one DMARC record per domain. For domains that never send mail, skip monitoring and publish v=DMARC1; p=reject straight away.
- Read the reports and fix failing senders. Over two to four weeks, review the reports by sending source: Microsoft 365, each third-party service and anything unknown. For each genuine source failing alignment, add it to SPF or set up its DKIM with your domain. Unknown sources sending in volume are usually spoofing, which is exactly what enforcement will stop.
- Move to quarantine. When every genuine source passes, change the record to v=DMARC1; p=quarantine; rua=mailto:<reporting address>. Leave out pct or set it to 100, as the check warns on any lower percentage. Watch the reports and the client’s support queue for a week or two for anything genuine being junked.
- Move to reject. Change the policy to p=reject once quarantine has run cleanly. This check passes at quarantine, but reject is what CISA’s baseline and the NCSC aim for, and the separate DMARC reject check in this assessment asks for it, with report addresses.
- Confirm the published policy. Run Resolve-DnsName -Name _dmarc.contoso.com -Type TXT and check there is one record with p=quarantine or p=reject and no pct below 100. Send a test message to an external mailbox and check the headers show dmarc=pass. The next assessment shows the domain as passing.
What users will notice
None for legitimate mail. Spoofed mail using the domain is quarantined or rejected by receivers.
How to confirm it worked
Look up _dmarc.yourdomain: the record shows p=quarantine or p=reject, and the reports show your real senders passing.
Frameworks and controls
This check maps to controls in 12 frameworks. Passing it is evidence that the setting is in place, not a certification against any of them.
| Framework | Control |
|---|---|
| NCSC CAF | B4.b Secure configuration |
| DSPT | Standard 9: IT protection |
| NIS2 | Art. 21(2)(g) Basic cyber hygiene practices and training |
| Zero Trust | Applications |
| SOC 2 | CC6.6 Protection against threats from outside the system boundaries |
| PCI DSS 4.0.1 | 5.4.1 Personnel are protected against phishing attacks |
| ISO 27001:2022 | A.5.14 Information transfer |
| CISA SCuBA | MS.EXO.4.1v1 DMARC published for every second-level domainMS.EXO.4.2v1 DMARC policy set to reject |
| CIS M365 | 2.1.10 Ensure DMARC Records for all Exchange Online domains are published |
| CIS Controls v8.1 | 9.5 Implement DMARC (IG2) |
| NIST CSF 2.0 | PR.PS-01: Configuration management practices are established and applied |
| NCSC 10 Steps | Architecture and configuration |
The framework mappings were last checked against the published standards in October 2026.
Microsoft’s documentation
- Set up DMARC to validate the From address (Microsoft Learn)