You can catch up on Part I here.
There are a few elements of the email authentication equation missing, even after an email sender has fully deployed SPF and DKIM, and that is what led to the development of DMARC.
First, there is no way for a recipient system to know how much reliance they should put on the SPF and DKIM results for any given email. Should they reject everything that doesn’t pass both standards, should they just scrutinize email more if it doesn’t pass at least one, or is the sender just in a test phase and the SPF and DKIM results don’t really matter at all yet? Since there are hundreds or thousands of servers sending email for most large organizations, deploying SPF and DKIM is not a simple overnight on/off process, so there are often many emails that are completely legitimate but don’t fully pass SPF and DKIM. Email senders need a way to tell the email receivers “We’ve deployed SPF and DKIM, and we are telling you what you should do with email from us that fails both tests”, so that the receivers aren’t put in the position of having to guess and risk user anger and potential liability when they get it wrong and block legitimate email from being delivered.
Second, SPF and DKIM provide no way for email receivers to provide any feedback to the email senders. If email is being blocked based on SPF and DKIM results, the receivers need a way to let the senders know what is happening in order to avoid a “black hole” effect where email just isn’t getting through to certain recipients. And this feedback mechanism has to be automated, since estimates are that the daily email volume worldwide has now passed the ½ TRILLION message mark. Clearly, having people manually handling delivery problems for even a tiny fraction of that volume is impractical, to say the least. This is where the 3rd and newest standard enters the picture.
Third, SPF and DKIM each authenticate email domains that are buried deep in the message headers and not easily visible to a typical end user. Most end users will see the From: header email address in their webmail or email client like Microsoft Outlook. Without DMARC it is entirely possible for a bad guy to send a message that passes SPF by authenticating a bad domain in the message headers, but then still use your bank’s email address in the From: header that a user sees. In this case you end up with an authenticated spoof, a scary proposition.
The DMARC standard (Domain-based Message Authentication, Reporting, & Conformance) is an overlay that adds these three key elements of feedback, policy, and identity alignment to the already deployed SPF and DKIM framework. First, DMARC allows email senders to publish policies telling receivers when they should rely on DKIM and SPF for a given domain, and what to do when messages fail those tests. Second, DMARC also allows the senders to tell receivers where to send feedback regarding their messages, so the senders can understand what is or isn’t being delivered and why. And finally, DMARC adds the requirement that the From: email address which a user sees is aligned with the email domains that SPF and DKIM authenticate.
By filling in these missing links, DMARC makes it possible for email receivers to make firm decisions about which emails to reject and which to deliver, confident that they are properly carrying out the policies set by the authorized sender of those emails. For example, if an email receiver rejects email from Chase.com that fails DKIM, they are doing so because Chase’s DMARC policy says “Reject email that fails authentication, and let us know that it was rejected”.
85% of the email inboxes in the U.S. are protected by DMARC including those at Gmail, Microsoft, Yahoo!, and AOL. Consumers are just waiting for their favored brands to catch up. To learn more about getting started, check out the resources available at MAAWG, DMARC.org or the Online Trust Alliance.