DMARCDomain-based Message Authentication, Reporting & Conformance
DMARC is the record that tells other mail servers what to do when someone sends email pretending to be your domain. Without one, an attacker can forge "from your-company.com" and Gmail, Yahoo, and everyone else will happily deliver it — because nothing told them not to.
A DMARC record does three things: it declares a policy (ignore it, quarantine it, or reject it outright), it says where to send reports about mail claiming to be your domain, and it ties that policy to whether SPF and DKIM actually lined up. Publish nothing, and every receiver is left to guess.
The DMARC DNS record
DMARC is a TXT record published at _dmarc.yourdomain.com, defined by RFC 7489. A minimal record looks like v=DMARC1; p=none; rua=mailto:[email protected] — v is the version (always DMARC1 and must come first), p is the policy applied to your domain's own mail, and rua is where aggregate reports go. Optional tags include sp (subdomain policy), pct (percentage of mail the policy applies to — being phased out, see DMARCbis), adkim/aspf (strict or relaxed alignment), and ruf (forensic report address, rarely honored by large receivers).
Alignment: the mechanism DMARC actually checks
DMARC doesn't authenticate anything itself — it checks that SPF or DKIM passed AND that the domain they authenticated matches (is "aligned" with) the visible From: address. A message can pass SPF for a sending vendor's domain and still fail DMARC if that domain doesn't match yours. This is why a domain can have valid SPF and DKIM and still fail DMARC — alignment is the piece most misconfigurations miss.
The enforcement ladder
p=none monitors without affecting delivery — the safe starting point while you review reports and confirm every legitimate sender passes. p=quarantine tells receivers to send failing mail to spam. p=reject tells them to refuse it outright. Most organizations sit at p=none indefinitely because moving up without checking who's actually sending on your behalf risks breaking legitimate mail — the aggregate reports rua= collects are what make that move safe.
Aggregate reports (RUA)
Every 24 hours, participating receivers (Google, Microsoft, Yahoo, and others) send an XML report to the address in rua= listing every IP that sent mail claiming your domain, whether SPF/DKIM passed, and whether it aligned. It's the only reliable way to discover shadow-IT senders — a marketing tool, a help desk platform, a forgotten vendor — before you flip a policy that blocks them.
How Trustliant handles this
Trustliant parses every DMARC record with DMARCbis-aware validation (RFC 9989) — flagging deprecated tags and rollout traps most tools miss — and ingests aggregate (RUA) reports continuously, identifying every sender by vendor fingerprint rather than a bare IP address. The Trust Score itemizes exactly what's wrong with a domain's DMARC posture and hands technicians the alignment evidence needed to move a client up the enforcement ladder with confidence, not guesswork.
Questions we get about DMARC
- Does DMARC stop spam?
- No. DMARC only governs mail that claims to be sent from your domain. It stops impersonation of your brand — it doesn't filter spam arriving from other domains, which is what your regular spam filter handles.
- Is DMARC required?
- Google and Yahoo require it for anyone sending meaningful volume to their users (since 2024), and Microsoft added its own enforcement in 2025. PCI DSS 4.0 and CIS Controls v8.1 both name it as a required or recommended control in specific contexts. See our compliance page for exactly where "required" is accurate.
- What's the difference between p=none and no DMARC record at all?
- p=none still collects aggregate reports and signals to receivers that you're monitoring, which some scoring systems credit. No record at all means zero visibility into who's sending as your domain, and zero signal to receivers about your intent.