DMARC

The policy layer that tests whether an SPF or DKIM pass aligns with the visible From domain, tells receivers what to do when neither does, and requests reports from them.

DMARC, defined in RFC 9989, is a TXT record published at _dmarc.yourdomain.com. It authenticates nothing itself. It reads the SPF and DKIM results and adds the three things they lack. Alignment is the test that the domain which earned a pass, either the envelope domain SPF checked or the domain that signed, matches the domain in the From: header a person actually reads. It is the only check in the chain that compares the authenticated identity against the displayed one. Policy tells receivers what to do with mail that fails. Reporting asks receivers to send data back. Only one of SPF or DKIM has to pass and align for DMARC to pass.

The policy value is the detail that decides scenarios. p=none is monitor only: reports flow, delivery is unchanged, and the domain stays spoofable, so a domain can truthfully claim to have DMARC while having no protection at all. p=quarantine routes failures to junk. p=reject refuses them, and is the only setting that stops exact-domain spoofing. A separate sp= governs subdomains, and leaving it weaker than p= is a well-worn bypass. Aggregate reports, requested with rua, are what make a staged rollout possible.

Exam relevance: when a scenario mentions a DMARC record, look for the p= value before anything else, because publishing and enforcing are different things. Rollout questions tend to reward the staged answer: start at none, use the reports to find every legitimate sender, then climb. Moving straight to reject blocks the organisation’s own forgotten mail.