M365EXO-018: DMARC enforcement set to p=reject (MS.EXO.4.2)
- Platform
- Entra ID / M365
- Category
- Advanced Threat Protection
- Severity
- High
- Zero Trust pillar
- Applications & Workloads (weight 2)
- Golden fixtures
- 3
- Branch coverage
- Observed: fixtures prove the verdicts they exercise
- Provenance
- baseline
What it checks
SCuBA MS.EXO.4.2 requires that the DMARC message rejection option be set to p=reject. Of the three policy values (none, quarantine, reject), reject provides the strongest protection by instructing receivers to drop unauthenticated mail outright. A policy of none or quarantine leaves a window for spoofed mail to reach or land near user inboxes.
Recommended value
DMARC record for each domain contains p=reject
Remediation
After confirming that all legitimate senders pass SPF or DKIM alignment under monitoring, update each domain's DMARC record to p=reject so receivers discard mail that fails authentication. Move through p=none and p=quarantine first to avoid disrupting legitimate mail. Continue monitoring aggregate reports after enforcing reject to catch any newly onboarded sender that is not yet aligned.
Fixture-proven verdicts
Every verdict below is proven by a golden fixture in the module's gating test suite. This table derives from the last green run; it cannot be edited by hand.
| Scenario | Expected verdict |
|---|---|
| clean | PASS |
| known-bad | FAIL |
| throttled | Not Assessed |
Framework mappings
- CISA SCuBA
- MS.EXO.4.2v1
- NIST SP 800-53
- SI-8
- MITRE ATT&CK
- T1566.001