Originally Posted on the RBLTracker Blacklist Monitoring Blog.
DMARC, or “Domain-Based Message Authentication, Reporting, and Conformance”, allows a domain owner to publish policies in DNS, telling remote mailers what to do with messages that do not align with these polices. DMARC is built on top of two existing technologies: SPF, or “Sender Policy Framework”, and DKIM, or “DomainKeys Identified Mail”.
By publishing a DMARC policy via DNS, domain owners can instruct remote mailers on what to do with messages that do not pass either a SPF or DKIM test. It also provides a mechanism for reporting under those policies. This gives remote mailers a channel for letting domain owners know that they received messages that did or did not align with those policies.
Why Is This Good?
The main goal of DMARC (and SPF and DKIM), is to detect and prevent email spoofing. For example, phishing scams that are designed to look like they’re coming from your bank or Paypal, prompting you to click on a link to reset your password or to give them your information.
Ultimately, SPF and DKIM are doing the hard work here. By designating email systems that are permitted to send email for a domain, and by cryptographically signing messages to avoid header modification en-route.
But DMARC ties the two technologies together, providing a single interface for instructing remote mailers on the domains policies, and actions to take when not met. It also opens up the possibilities of adding additional anti-spoofing or SPAM control software, which could also be handled under the DMARC umbrella.
As a domain owner of example.com, I can publish both SPF and DKIM records identifying my mail system (x.x.x.x) as the only authorized mail relay for my domain. I can then publish a DMARC record that tells remote mailers, that they should reject any messages that do not pass both a SPF and DKIM check, and that they should send reports to firstname.lastname@example.org to let me know if and when this happens.
A DMARC policy record, via a DNS TXT record, using the hostname _dmarc.example.com, would look something like this:
If a remote mail receives an inbound email from an email address @example.com, but not from my mail system (x.x.x.x), the SPF check should fail, and they should reject the email in accordance with my DMARC policy.
Technologies like DMARC, SPF, and DKIM are great tools in the seemingly never ending fight against email SPAM and spoofing.
For more information, see: