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.
For Example
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 abuse@example.com 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:
"v=DMARC1;p=reject;rua=mailto:abuse@example.com"
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:
- The official DMARC website – https://dmarc.org/
- DMARC on Wikipedia – https://en.wikipedia.org/wiki/DMARC
But if its built on top of SPF & DKMI,
how much is it really worth, since these two *should* be already enough, no?
Sure, adding an additional DNS record isn’t that much effor, though.
Hey Flo,
I think DMARC is important for a few key reasons:
1) DKIM doesn’t really include a definition of what to do if the email does not pass a DKIM test in the same way SPF does (i.e. ~all vs -all); this part is left up to the recipient email systems, so it’s a little ambiguous. By letting organizations define what to do with email that does not pass their own tests, the responsibility is put back on the organizations- which is where it should be.
2) Neither SPF nor DKIM directly include reporting functionality, which is incredibly useful for mail admins, as it can give you information about misconfigured servers or services. Without it, mail admins are effectively blind to the email being blocked on their behalf.
3) It gives a standard control for future email filtering technologies; they can simply be lumped under DMARC in the same way SPF and DKIM are.
Mike