Security term · last reviewed 2026-08-31
DMARC
Also known as: Domain-based Message Authentication, Reporting and Conformance, RFC 7489
DMARC (RFC 7489) is a DNS policy record that adds alignment and reporting on top of SPF and DKIM, telling receivers to monitor, quarantine, or reject mail that fails authentication while claiming to come from your domain.
How it works
DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489) is a DNS policy record that tells receivers what to do with mail claiming to come from your domain that fails authentication. It builds on SPF and DKIM by adding two things neither has alone: alignment, which requires the authenticated domain to match the visible From header, and reporting, which sends you aggregate XML on every sender using your domain. The policy tag p= takes three values: none (monitor only), quarantine (route to spam), and reject (refuse at SMTP). Enforcement means quarantine or reject at pct=100.
When it matters
DMARC matters for every domain that sends mail, and for every domain that does not (a parked domain should publish p=reject). It is the single highest-leverage anti-spoofing control available, and it is a hard prerequisite for BIMI. The risk lives in the rollout: moving to p=reject before you have inventoried every legitimate sending system silently drops real mail, typically invoices, password resets, and recruiting outreach. Run p=none with rua reporting for two to four weeks first and read the reports.
Common misconceptions
- "We have SPF and DKIM, so we are covered." Without DMARC there is no alignment requirement, so an attacker can pass SPF on a domain they control while displaying yours in the From header.
- "`p=none` protects us." It protects nothing. It only collects reports. Attackers ignore it because receivers do.
- "`pct=` is a safety valve worth keeping." It is a staging tool. A record parked at
pct=25leaves three quarters of spoofed mail delivered, and it disqualifies you from BIMI.
Explained in depth