DMARC (Domain-based Message Authentication, Reporting & Conformance)
DMARC is an email authentication protocol that helps senders protect their domain from spoofing and phishing by instructing receivers how to handle messages that fail SPF or DKIM.
DMARC is an email authentication policy that uses SPF and DKIM alignment to protect your domain from spoofing and to tell receivers what to do with messages that fail.
Definition and examples
DMARC is an email authentication protocol that tells receiving mail servers how to handle messages that fail SPF or DKIM. It helps prevent domain spoofing and phishing and improves email deliverability.
Why it matters
It prevents spoofing and phishing by requiring that the domains in SPF and DKIM match the visible From address. It can improve inbox placement when it is configured correctly and you monitor the reports. It protects your domain reputation with mailbox providers across regions and services. It meets evolving sender requirements (see Google’s bulk sender guidelines).
How it works
DMARC checks whether SPF or DKIM passed and whether that passing result aligns with the visible From domain. If the message fails alignment, your policy decides what happens next, usually monitor only, send to spam, or reject the message outright. The reporting layer is what lets you see failures before they become a bigger deliverability problem.
Common mistakes
A common mistake is enabling p=reject too early: blocklists legitimate mail before you’ve fixed alignment; start with p=none and review reports first. A common mistake is missing alignment: the visible From domain must match your SPF/DKIM domains; otherwise DMARC will fail even when SPF/DKIM individually pass. A common mistake is not monitoring reports: without rua and an inbox to receive them, you can’t see who is sending mail as your domain or where failures occur. A common mistake is multiple/conflicting records: only one TXT record at _dmarc.example.com should exist; duplicates cause providers to ignore DMARC. A common mistake is wrong host or type: DMARC must be a TXT at _dmarc.example.com (not at the root, and not a CNAME). A common mistake is ignoring subdomains: if vendors send from subdomains, set sp to a suitable policy so their traffic isn’t accidentally blocked. A common mistake is overly relaxed alignment: stay on relaxed while you configure third-party senders, then move to strict to further reduce spoofing.
Related terms
Key takeaways
DMARC builds on SPF and DKIM to add policy, alignment, and reporting
Begin with monitoring (p=none), then move to stricter policies as issues are resolved
Proper DMARC improves deliverability and meets modern sender requirements