Domain-based Message Authentication, Reporting and Conformance, or DMARC, connects the domain visible in the From header with SPF and DKIM authentication. A message can pass DMARC when at least one of those mechanisms both passes and aligns with the visible From domain.
DMARC also lets a domain owner publish handling guidance for messages that fail and request aggregate reports. A policy should be introduced with evidence: inventory legitimate senders, review alignment, monitor reports and only then increase enforcement.
Authentication is not the same as alignment
SPF checks the domain used for the SMTP envelope sender, while DKIM checks the signing domain in the DKIM signature. DMARC compares those authenticated domains with the domain shown to the recipient in the From header.
This distinction matters when a third-party platform sends for a business. The platform may authenticate its own infrastructure successfully while still failing DMARC for the customer's visible domain unless aligned return-path or DKIM signing is configured.
What belongs in a DMARC record
The policy is published as a TXT record at _dmarc.example.com. The record begins with v=DMARC1 and includes a p= policy. Common optional tags control aggregate reporting, subdomain policy and alignment strictness.
- Use p=none to collect evidence without requesting rejection or quarantine.
- Use rua= with a mailbox or reporting service prepared to process aggregate XML reports.
- Treat pct, subdomain policy and strict alignment as deliberate operational controls, not decorative tags.
Roll out enforcement in controlled stages
Start by listing every legitimate source that uses the domain in visible From addresses. Confirm aligned SPF or DKIM for each source and monitor DMARC aggregate reports long enough to identify forgotten applications and regional systems.
After legitimate traffic consistently aligns, move toward quarantine or reject according to the organization's risk tolerance. Continue reviewing reports after enforcement because new senders, DNS changes and key rotation can introduce regressions.
What a public DMARC check can and cannot prove
A DNS check can confirm that a syntactically usable record is published and explain its policy tags. It cannot prove that every legitimate sender aligns, that report mailboxes are processing data correctly, or that enforcement will be safe for a particular organization.
Primary sources
Provider interfaces and requirements change. Check the linked source before applying a production change.