DMARC
DMARC builds on SPF and DKIM: it says what receivers should do with mail that fails, and asks them to report back.
What DMARC adds
DMARC, specified in RFC 7489, sits on top of SPF and DKIM. It closes the gap those two leave: both authenticate a domain, but neither requires that domain to match the From address a reader actually sees.
The policy is a TXT record at the _dmarc subdomain — _dmarc.example.com — beginning with v=DMARC1.
Alignment is the point
DMARC passes when SPF or DKIM passes and the domain it authenticated aligns with the From header domain. Either one is enough; both are not required.
The aspf and adkim tags choose how strict alignment is. Relaxed alignment, the default, accepts a match on the organisational domain, so mail.example.com aligns with example.com. Strict alignment requires an exact match.
The policy tags
p=none asks only for reporting and changes nothing about delivery. p=quarantine asks receivers to treat failing mail as suspicious. p=reject asks them to refuse it outright.
sp= sets a separate policy for subdomains. Without it, subdomains inherit the domain policy, which is worth knowing if subdomains send mail that is not aligned.
pct= applies the policy to a percentage of failing mail, which exists to make a staged rollout possible.
Rolling it out without breaking mail
Starting at p=none with a rua= reporting address collects data without affecting delivery. The reports show which senders are failing alignment, and the list usually contains legitimate services nobody remembered.
Moving to quarantine or reject before legitimate senders align is the standard way to lose your own mail. Fix alignment first, then tighten the policy.