2012/02/07 by Maarten Oelering.
What DMARC means for you
A week ago DMARC went public causing a tidal wave of publicity, discussion, and fuzz. Many senders are now asking what they should do with it. In this post I will try to put things in perspective, so senders can judge better what DMARC means for them.
First of all, DMARC is not something completely new. For 18 months Paypal, Cloudmark, Facebook, Google, and others have been working on a new policy framework. They recognized that receivers didn’t apply SPF policies due to the forwarding issue. And that many senders were hesitant to use ADSP (RFC5617) due to the “all or nothing” nature of ADSP policies.
Now that the DMARC framework has gone public, it doesn’t mean it’s a standard and ready to be used by anyone. The intention is to get feedback from early adopters so it can further develop into a common standard. Senders should understand what it is about. But there is no distinctive reason to implement it at this stage.
So what is DMARC exactly? So far email authentication has been effective in allowing receivers to collect domain reputation when validation passes. But one of the main goals of authentication has always been to prevent spoofing and phishing. In short, DMARC tells a receiver what to do when authentication is missing or failing for a specific From: header domain. This means that DMARC should not be seen as deliverability “best practice” for commercial senders. Instead, it is should be seen as a security measure for senders susceptible to spoofing and phishing.
For organizations that want to use email authentication to prevent spoofing and phishing, DMARC addresses the following challenges:
- knowing that all valid email sources are properly authenticating
- the risc of introducing strict authentication policies with a bang
- the risc of incidental failing SPF or DKIM causing false positives
- properly authenticated email with a spoofed From header
- enforcing the use of strict policies by receivers
- getting intelligence from unauthenticated phishing emails
So for those organizations, I think DMARC is a great development. In the future, it could mean they don’t have to resort to commercial services, such as Return Path Domain Assurance or Agari, to get authentication policies in place.
Even if you are not subject to phishing and only interested in your own deliverability, there are some things they could pick up from DMARC. One of these things is “alignment”. SPF applies to the envelope sender (return-path) domain, DKIM applies to an arbitrary signing domain (d=), and what the user sees is the From: header address. These can all be completely different domains, so the question: “who actually sent this email?”, is difficult to answer for the recipient.
ADSP already required that the DKIM signing domain matches the visible From: header domain. Now DMARC also requires that the envelope sender and the DKIM signing domain have the same “organizational domain” as the From: header domain. The “organizational domain” is a public suffix plus one private domain part, such as firstbank.com or secondbank.co.uk. Even if phishing is not an issue, alignment will improve trust in the real sender identity.
If you are an ESP, alignment means that you should prepare for custom DKIM domains and custom envelope sender domains. A common third-party DKIM signature and a common envelope sender domain could be taken less seriously by receivers in the future. But then ESPs could use DMARC’s feedback mechanism to check for proper authentication, even if no policies are applied.
Google has already adopted DMARC, even in this experimental stage. Unfortunately, many smaller ISPs and mailbox providers have yet to adopt SPF and/or DKIM validation. I hope that the publicity around DMARC is a sign for quick adoption by providers. When they are not applying requested policies, SPF and DKIM will remain window dressing for deliverability instead of becoming an effective anti-phishing measure.