DMARC

DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on top of SPF and DKIM. The domain owner publishes a TXT record at _dmarc.example.com that tells receiving mail servers what to do when a message claiming to be from the domain fails authentication.

The p= tag sets the policy: none means only monitor, quarantine asks receivers to deliver suspicious messages to spam, and reject asks them to refuse the message outright. The rua= tag specifies an address that receives aggregated XML reports, giving the domain owner visibility into who is sending email on behalf of the domain — both legitimate services and abuse. A separate ruf= tag can request per-message forensic reports, but those are rarely used in practice for privacy reasons.

DMARC also enforces alignment: it requires the domain in the visible From header to match the domain validated by SPF or DKIM. Alignment can be relaxed (same organisational domain) or strict (exact match). This ties authentication to the identity the user actually sees and is what closes the gap that SPF and DKIM individually leave open.

The sp= and pct= tags support gradual rollout: sp= applies a different policy to subdomains, and pct= applies the policy to only a percentage of messages, which lets operators ramp up enforcement without breaking legitimate mail flows that have not yet been brought into alignment. DMARC is also a prerequisite for BIMI (Brand Indicators for Message Identification), which lets verified senders display a logo next to their messages at major mailbox providers, and is increasingly treated as the baseline policy that mail systems expect from a serious sender domain.