You can catch up on Part 1 here.
As we discussed in part one of this series, SPF and DKIM are important foundational standards for email authentication. But, even after an email sender has fully deployed SPF and DKIM, there are still three key elements of email authentication equation missing—and that's what led to the development of DMARC.
#1: Which Matters More: SPF or DKIM?
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 isn't just a simple overnight on/off process. And there are often many emails that are completely legitimate but don’t fully pass SPF and DKIM. Which means 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 these tests."
That way, email receiving systems aren’t put in the position of having to guess about the legitimacy of an email and risk user anger and potential liability if they get it wrong and block legitimate email from being delivered.
#2: How Do You Alert the Sender?
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.
What's more, this feedback mechanism has to be automated, since estimates are that the daily email volume worldwide now averages north of 300 billion messages. Clearly, having people manually handling delivery problems for even a tiny fraction of that volume is impractical, to say the least.
#3: How Would Recipients Ever Know the Difference?
Third, SPF and DKIM each authenticate email using information that is 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 you 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 you see. In this case you end up with an authenticated spoof—a truly scary proposition.
Enter: DMARC
Domain-based Message Authentication, Reporting & Conformance, popularly known as DMARC, is a standard email authentication protocol 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. Its most aggressive enforcement policy is reject (p=reject), which means email messages that don't pass DMARC authentication will be rejected by a mail server and not delivered to its intended recipient.
This strong p=reject policy is the only way to ensure fraudsters are unable to hijack your domains for use in email attacks targeting your customers, partners, investors and the public at large. Weaker policies will not block spoofed messages outright.
Second, DMARC also allows 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 recipient sees matches the email domains that SPF and DKIM authenticate.
By filling in these missing links, DMARC makes it possible for email receiving systems 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."
Getting Started with DMARC
More than 2.5 billion mailboxes are DMARC protected worldwide, including Google, Yahoo, Microsoft and most other major mailbox providers. And failure to implement DMARC can cost you big.
But fair warning: While deploying DMARC on a single domain is relatively simple, implementing it across an enterprise's total universe of domains—which can span thousands of domains—can get very complicated, very fast. To learn how to do it right, start here.
