What this check looks at
Checks each custom domain’s DMARC record is at p=reject and names addresses for both aggregate (rua) and failure (ruf) reports, as the CISA baseline asks.
Three parts of a DMARC record matter here: the policy (p=none, quarantine or reject); the aggregate report address (rua), where receivers send daily summaries of who sent mail claiming to be the domain and whether it passed; and the failure report address (ruf), where some receivers send details of individual failures. p=quarantine asks receivers to treat failing mail as suspicious, which usually means the junk folder; p=reject asks them to refuse it outright.
The check reads public DNS for every custom domain, parked ones included, and fails a domain whose policy is not p=reject, that has no rua address, or whose record was read and has no ruf address. It warns when every domain is at p=reject with an aggregate address but it could not tell whether each has a failure address, or some domains could not be read. This is the stricter CISA baseline; the separate DMARC check passes at quarantine.
Spoofed mail at p=quarantine still reaches the recipient, in the junk folder, where people do look when they are expecting an invoice. Without report addresses the organisation cannot see who is sending as its domain, cannot spot a genuine sender that has started failing, and has no evidence to move safely from quarantine to reject.
Why it matters
p=quarantine still delivers spoofed mail to junk folders; p=reject stops it at the receiving server. Report addresses are how the organisation learns that its domain is being spoofed, or that a genuine sender is failing.
A typical case: a solicitors’ practice at p=quarantine learns that a client paid a fake completion invoice that the client retrieved from junk because it appeared to come from the firm. At p=reject the client’s mail provider would have refused it outright, and the aggregate reports would have shown the spoofing campaign starting the week before.
Failure reports need care: few large providers send them, and those that do can include headers or content of the failing message, which may be personal data. Point ruf at a reporting service or a restricted mailbox, and handle what arrives under the organisation’s UK GDPR obligations.
CISA SCuBA MS.EXO.4.2 asks for p=reject and MS.EXO.4.4 for an organisational contact to receive aggregate and failure reports; the CIS Microsoft 365 Foundations Benchmark (2.1.10) asks for DMARC records on all Exchange Online domains. CIS Controls v8 9.5, NIST CSF 2.0 PR.PS-01 and NCSC CAF C1.a support it, and the NCSC’s email security guidance recommends working towards p=reject.
How to fix it
Where: Your DNS provider
Before you start
- Read the DMARC aggregate reports for at least two weeks at p=none or quarantine, and make sure every genuine sender passes SPF or DKIM first.
- Choose a reporting service or monitored mailbox for rua and ruf.
Step by step
- Check every genuine sender passes DMARC. Before moving to reject, read at least two weeks of aggregate reports for each domain: every genuine source (Microsoft 365 and each third-party service) should pass DMARC through aligned SPF or DKIM. Fix any that fail first, because at p=reject their mail will be refused.
- Choose the report addresses. Use a DMARC reporting service or a dedicated, access-restricted mailbox for both rua and ruf. If the address is on another domain, that domain must publish the authorisation record <yourdomain>._report._dmarc.<reportdomain> TXT "v=DMARC1"; reporting services do this for you.
- Update the DMARC record. At the DNS host, edit the TXT record at _dmarc to v=DMARC1; p=reject; rua=mailto:dmarc@reports.example; ruf=mailto:dmarc@reports.example, using your chosen addresses. Leave out pct or set it to 100, and keep one DMARC record per domain.
- Set the parked domains to reject. For custom domains that never send mail, publish the same record with p=reject and the same rua and ruf addresses. The check covers parked domains too, and they are the easiest to spoof because nobody watches them.
- Watch the first weeks at reject. Keep reading the aggregate reports, and ask the client to pass on any customer saying their mail was refused. A genuine sender that starts failing needs adding to SPF, or its DKIM set up, straight away.
- Confirm the published records. Run Resolve-DnsName -Name _dmarc.contoso.com -Type TXT for each domain and check it shows p=reject, a rua= address and a ruf= address. The next assessment passes when every domain shows all three.
What users will notice
Mail that fails DMARC claiming to be from the domain is rejected by receiving servers. Genuine mail from senders not yet set up is rejected too.
How to confirm it worked
Look up the _dmarc TXT record: it shows p=reject with rua= and ruf= addresses.
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 configurationC1.a Monitoring coverage |
| 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.2v1 DMARC policy set to rejectMS.EXO.4.4v1 An organisational contact receives DMARC aggregate and failure reports |
| 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)