The DMARC email protocol has been available for several years now. Yet while a powerful tool in email authentication, its voluntary take-up, misunderstood benefits, and the myth of complexity that surrounds it has held it back. 2017, however, is shaping up to be its year.
Just 3 years ago, the number of emails sent with DMARC implemented was a small proportion of global email traffic (fig.1). Part of the reason is that it required both sender and receiver to comply with what was an emergent and voluntary protocol.
However, 2016 started to see the larger global freemail providers jump on the bandwagon after seeing what it can do to combat the rise of sophisticated spoofed phishing attacks. Now in 2017, we're experiencing the knock-on effects in the private sector with organisations taking a more pro-active role in protecting their customers, employees and brand; not to mention the added deliverability improvements for marketing and transactional channels.
It's not as difficult as one might think to get compliant, and the benefits are huge.
Now is the time.
What is DMARC?
Very simply, it’s another email authentication protocol. However, DMARC’s been specifically designed to combat the increasing sophistication and proliferation of email scams/phishing-attacks where an email looks like it has come from a legitimate source, but in fact hasn’t.
Technically-speaking, it is a way for a sender to instruct a receiving server on what action it should take if it cannot validate the sender’s From address using either of the other email authentication protocols (SPF/DKIM), for any message sent to it.
The sender’s ‘instructions’ are present in the sender’s DNS records, which the receiver can look up at any time for any message from, or looking like it is from, the sender.
So, to re-phrase, DMARC is a way to authenticate the often-spoofed From address.
Why is it necessary?
Spam and Phishing attacks commonly ‘spoof’ the From address of legitimate companies to fool the user. They will change the From address to something recognisable, which is easily done (whereas the actual email could be coming from anywhere).
Legitimate or not? The From address - easily changed by the sender.
SPF and DKIM protocols are already there to combat this by helping to prove the legitimacy of the sender, but what happens if they do not check out (or are not even enabled)? How does the receiving server know whether the sender has simply not set things up properly, or if it is indeed an intentionally spoofed phishing attack from someone else?
The DMARC records in the sender’s DNS are there to help the receiving server to decide what the reality is.
How does it work?
When a message is received by a receiving server, it will check whether SPF and DKIM authentications pass or fail, and for which domains (From address, Envelope address etc).
If DMARC is enabled on the receiving server, it will also look up the DNS records of the from address to see if there is a DMARC policy.
This policy will contain information as to what it should do if neither of those initial SPF and DKIM authentication checks pass for the From address. They may check out for the other addresses in the email, but there needs to be an SPF or DKIM pass for the From address in order to pass DMARC.
So, if a sender is confident that they have setup SPF and/or DKIM correctly, they might set the policy to say (in layman’s terms):
“If neither SPF and DKIM check-out for our From address, then it’s not an email from us. We suggest you quarantine it for further checks of its legitimacy (or even outright discard it).”
An actual DMARC DNS record that does this would look something like this (for the imaginary acmecompany.com domain):
_dmarc.acmecompany.com 60 TXT "v=DMARC1; p=quarantine; rua=mailto:dmarc@acmecompany.com;"
With the following explanations:
_dmarc.acmecompany.com
Host i.e. the name of the DMARC record and which domain it applies to
60
TTL or Time To Live (how quickly the DNS record updates upon change)
TXT
The type of DNS record. DMARC uses TXT
v=DMARC1
The DMARC version being used - this is mandatory and has to come first
p=quarantine
The DMARC policy for what a receiving-server should do with a failed email (here, it suggests quarantine) - this is also mandatory and has to come after the version
rua=mailto:dmarc@acmecompany.com
The address that DMARC reports should be sent to (more about these below) - this is optional
There are, of course, many other options and fine-tuning that can be done when you start getting into it; this is simply an overview to illustrate the basics.
Is it perfect?
No, but close. There are two instances where it can be either ineffectual or problematic:
Ineffectual - if a hijacked computer is used to send phishing email (as part of a botnet, for example) it will pass both SPF and DKIM scrutiny, and also DMARC.
Problematic - very occasionally DNS records can be temporarily inaccessible, or there can be a delay in the information returned which can cause a temporary SPF or DKIM error. If the DMARC policy is set to instruct the receiving server to reject on failure (a very strict policy), there is a chance it can reject legitimate email on a temporary SPF or DKIM error. This issue is minimised since DMARC will pass if either SPF or DKIM passes for the From address domain, but there is still the chance of accidental error (which is why we would not recommend the strictest DMARC policy setting).
The benefits, however, far-outstrip these minor issues.
DMARC Benefits
Security
The most compelling benefit for both senders and receivers is DMARC's ultimate aim: the reduction of successfully-delivered spoofed email.
For the sender this involves ensuring solid SPF and DKIM implementation and a decent policy in the DMARC DNS record, such as recommending quaratine for any emails failing DMARC checks (although many receiving servers will treat emails that fail their own DMARC policy with suspicion anyway).
Another considerable security benefit (with Deliverability overlap, as we will see later) is DMARC's other main feature, which is the reporting of a sender's DMARC activity across the receiver's network.
This takes the form of aggregate (or individual) reports that the sender can request to be sent to it at regular intervals by the receiver. At time of writing, most of the major freemail providers (Google, Outlook et al.) are now set up to produce and send DMARC reports. These contain all the instances of DMARC passes and failures for emails sent to their network from (or purportedly from) the sender, with some extra identifying details (counts, IP addresses, SPF and DKIM authentication results etc).
This feedback can provide valuable insight about a sender's management of internal operations and the presence of external domain name abuse.
Deliverability
As with anything that helps prove the legitimacy of an email, there are email deliverability benefits to be had.
A few years ago these effects were negligible, as the number of receiving servers set up to handle DMARC was a tiny percentage of the overall. However, as can be seen in figure 1. at the top of the article, this is rapidly changing.
Even with a relaxed DMARC policy, the mere fact that there is one in place that checks out, immediately separates your email out from the hordes of spam. This is especially true for the more commonly-spoofed transactional emails delivering official/business/financial content, or requests for information.
Running analytics on DMARC report data can also provide the marketer with additional insights into deliverability patterns or unexpected events. For example, a campaign may suddenly experience a significant drop in engagement with a particular provider, with none of the usual causes (high bounce-rate and other list-problems, poor content quality, blacklisting etc).
It turns out that a rogue IP has been sending thousands of spoofed emails to that provider using your domain as the From address.
How would you know if it wasn't for DMARC?
Successful Implementation
Enabling DMARC is one of the pro-active steps organisations can take in the protection of their customers, employees and the brand itself. It is also one more tick in the box for successful inbox-placement.
These days, most senders will already have SPF and DKIM setup correctly (especially if using the services of an ESP). It's not much of a jump to go from this to the additional benefits of a DMARC ‘pass’ from a receiving server, involving the addition of a valid DMARC record with a bare-minimum implementation. This alone doesn’t take advantage of any of DMARC’s reporting capabilities, but will nevertheless demonstrate compliance.
The next step is setting-up a policy for instructing receiving servers on what to do with email that isn't coming from you, to help prevent spoofed emails from reaching your customers (and employees). Simple enough, but organisational sub-domains and how DMARC should be treated in each case are an added complexity to be considered here, though the protocol adequately allows for specific rules on sub-domains where necessary.
To really reap the benefits, DMARC reports needs to be requested, received and processed, with investigative analytics run on the resulting datasets to identify domain abuse, organisational mis-configurations, and deliverability issues.