DKIM and SPF have been around for quite some time. One would think that authenticating your emails with either of them would erase spoofing from your long list of concerns. Unfortunately, it not always does. What if you used both of them, then? Better, better. But still not perfect. Back in 2012, engineers from Microsoft, PayPal, Yahoo! and Google met up to discuss how to make authenticating emails even more bulletproof. At the end of the day, they released DMARC to the world.
What is DMARC?
Domain-based Message Authentication Reporting and Conformance not only has the most complicated name of all three methods but is also the most effective one. And it’s quite easy to understand why.
DMARC is not an entirely new concept. As a matter of fact, it’s not even considered to be an authentication method like the other two. Instead, it leverages DKIM and/or SPF to perform a more advanced check on each email received.
With DMARC, a domain owner can specify its own authentication procedure (known as a DMARC policy). Using it, they instruct an incoming server on what to do if an email fails to pass the DMARC test. Finally, the policy can also provide reports with the details of each check to improve processes and provide immediate warning if anyone spoofs the account.
To get a full understanding of this method, let’s review how the other two approaches authenticate emails work.
How DMARC works
In our SPF article, we described how companies publish SPF records to specify which IP addresses can be used to send emails on their behalf. If the sender’s IP doesn’t match with one of the IPs from the record, the SPF check fails.
DKIM, as described in our article, is a digital signature that contains the headers and/or a body of an email message, hashed with a certain method and encrypted with a private key. The receiving server is able to recreate the values with a public key and compare it against the signature received. If the values don’t match, the DKIM check fails.
DMARC requires at least one of these checks to be present.
When an email is received, a receiving server does a DNS lookup and checks if there’s an existing DMARC record. Not all servers do that but all major ones do and more and more smaller ones rely on this for every incoming email. Let’s assume that a Domain-based Message Authentication Reporting and Conformance record was found and the check begins.
DKIM/SPF is performed as usual. A receiving server then performs a so-called “alignment test”. It verifies if:
- In the case of SPF, the “envelope from” email address matches the “return-path” address. In other words, it checks if the email message was sent from is the same as the address a potential reply would go to.
- In the case of DKIM, the value behind ‘d’ tag (sender’s domain) matches the domain an email was sent from.
Of course, if both authentications are set up, both alignment tests are also performed. The alignment requirements can be ‘strict’ (the domains need to precisely match) or ‘relaxed’ (base domains need to match but different subdomains are allowed).
DMARC will succeed in the following scenarios:
- If only one of the authentications is set up, its check must be successful along with a respective alignment test
- If both methods are set up, either of them needs to be successful with the respective alignment test but not both are required
Notice how DMARC will still succeed even if e.g. DKIM along with DKIM alignment fail but SPF and its alignment succeeds (or the other way around).
Now, let’s assume an email failed a DMARC check for whatever reason. If it was subject to only SPF or DKIM test (or both), such failure wouldn’t be a decisive factor of whether an email will be allowed in an inbox or not. It would, of course, influence the “decision” but lots of other factors would also be considered.
DMARC lets you instruct the incoming server on what should happen to an email that failed a check. Three options are available (they’re referred to as “policies”):
- ‘None’ – it means that an email should be treated the same as if no DMARC was set up (a message can still be delivered, put in spam or discarded based on the other factors). This is typically used to watch the environment and analyze the reports, without influencing the deliverability
- ‘Quarantine’ – allow an email but don’t deliver it to an inbox. Usually, such messages go to the spam folder.
- ‘Reject’ – discard the messages that failed the check right away
These instructions can be also customized. For example, with a ‘quarantine’ policy you could tell the server to send only 10% of emails with a failed check to a spam folder and ignore (‘none’) the other 90%. Note that just because you instruct the server on what to do, it doesn’t mean that it will follow your advice. But it still puts you in much more control than in the case of DKIM and SPF authentications.
Finally, a receiving server will send reports both for each failed DMARC verification and with aggregated data about unsuccessful checks. It’s invaluable for analyzing the performance of your message to keep you in the loop if any phishing attempts occur.
What does a DMARC record look like?
Let’s now break down an example record. Instead of relying on dummy data, we’ll use the record of Square, a unicorn provider of financial services for small businesses. Many cybercriminals probably dream of spoofing their emails so it’s no surprise they chose to protect themselves with DMARC.
v=DMARC1; p=reject; rua=mailto:firstname.lastname@example.org,mailto:email@example.com,mailto:firstname.lastname@example.org; ruf=
You can access this record under this link. This site will also show you DMARC records for any other domain, given of course that it has been configured. Let’s go through each tag mentioned above, one by one.
This is the identifier (a DMARC version) that should be always included in the DNS record. The receiving server always looks for it. If v=DMARC1 is missing or is modified in any way, the whole verification will be skipped.
The policy Square chose to use is to reject all emails that fail the DMARC check. Of course, they might still be delivered but a strong signal will be sent to the receiving server not to allow such messages.
These three addresses will be receiving daily, aggregate reports about the emails that failed the verification. This will be high-level data about the reasons for failures, without giving any details of each. Each address added here needs to be proceeded with “mailto:” as in the example.
This, on the other hand, is an email address where individual forensics reports will be sent in real-time, including the details of each failure.
Yup, this was clearly easier than trying to understand the DKIM record, wasn’t it?
As is usually the case, there’s also a number of optional fields that can be added to the record to customize it a bit.
Set the percentage of failed emails that the set policy should apply to. As in the example above, you could send to ‘quarantine’ only 10% of emails, the other 90% would be treated as though a ‘none’ policy was applied. The value should be a number between 1 and 100.
Set a specific policy for emails sent from subdomains. For example, you could choose to ignore failed emails sent from the main domain (p=’none’) but quarantine those sent from subdomains.
You can choose here the aforementioned approach to how strict DMARC should be when comparing the sender’s domain against DKIM’s ‘d’ tag. As mentioned earlier, ‘strict’ and ‘relaxed’ are the possible options. By default, the approach is ‘relaxed’.
The same choice, just for SPF alignment. You decide whether SPF should aim for a perfect match of “envelope from’ domain and “return-path” address or if subdomains of “envelope from” domain should be also allowed. As above, you can choose to be ‘strict’ or ‘relaxed’.
Sets the intervals for how often you want to receive aggregate reports (‘rua’ tag). The value is expressed in seconds, by default it’s 86400 (every 24 hours).
Settings for the forensics reports (‘ruf’ tag). You can choose to send the report if: ‘0’ – if all underlying checks fail to return a positive DMARC result, ‘1’ – if any mechanism fails, ‘d’ – if DKIM failed to verify, ‘s’ – if SPF failed to verify. By default, it’s ‘0’.
Why you should use DMARC?
We said it already but it’s worth repeating it once again – DMARC is the most effective way of protecting yourself from spoofing. Period. This alone should be a good enough reason to add the implementation of DMARC to your next sprint.
If you already have SPF and/or DKIM set up (and most companies have at least one of them), adding DMARC is just a few extra lines to be included in your DNS records. They’re not very complex too as you could see in the example above.
The often-referenced example comes from the UK’s Her Majesty Revenue & Customs agency. As you could guess, their domain HMRC.gov.uk is one of the most spoofed domains in the country. Who wouldn’t like to collect some extra taxes from their fellow peers, right?
HMRC estimates that the number of phishing emails sent from their domain decreased by 500 million in just 1,5 years after the implementation of DMARC. On top of that, adding this verification also significantly boosted the delivery rates of their legitimate emails. That’s something definitely worth a mention too.
DMARC is widely known to be the most effective weapon against spoofers. It comes with two main benefits:
- Cybercriminals are much more likely to give up on trying to spoof a domain if they see a (properly configured) DMARC records in the domain’s DNS. They realize their chances of succeeding are close to none so often they won’t even attempt to spoof it. Instead, they’ll look for a much easier target. The implementation of DMARC is not widespread yet so it won’t be hard to find something more worthwhile of their time.
- Receiving servers also know that emails coming from DMARC-secured domains are much more likely to be legit than those secured with just one of the other authentication methods (not to mention those without any security). As such, if an email passed a DMARC check, it will be way more likely to be delivered than another message that came without it. And that was the whole point of sending an email, right?
Email security is never to be underestimated. The bigger you are, the more you have to lose if someone spoofs your accounts and tricks your customers into something you probably wouldn’t approve of. Given how easy it is to add each method and how much you gain by having them all properly set up, there’s little reason not to give them a try.
What’s absolutely cool about DMARC is that you can start with a ‘none’ policy and observe what happens. This basically means that your emails will be going through the relevant checks on the receiving side but if they fail, it won’t influence your deliverability. On top of that, you’ll receive tons of data via the DMARC reports so you can quickly identify if someone is trying to spoof your domain or if a problem lies on your side. Use this data to improve your processes and you’ll see the results in no time.