Back in 2012, engineers from Microsoft, PayPal, Yahoo!, and Google met to discuss making 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. And it’s quite easy to understand why.
DMARC 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.
How DMARC works
DMARC requires either SPF or DKIM records – or better, both of them – to be set.
When an email is received, a receiving server does a DNS lookup and checks if there’s an existing DMARC record.
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 address the message was sent from is the same as the address a potential reply would go to.
- In the case of DKIM, the value behind the ‘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, one of them needs to be successful with the respective alignment test but both are not required.
Notice how DMARC will still succeed even if, e.g. DKIM along with DKIM alignment fails, but SPF and its alignment succeeds (or the other way around).
Now, let’s assume an email failed a DMARC check for whatever reason.
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 also be 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 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:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com; ruf=mailto:dmarc-ruf@squareup.comYou 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.
v=DMARC1
This is the identifier (a DMARC version) that should always be 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.
p=reject
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.
rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com
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.
ruf=mailto:dmarc-ruf@squareup.com
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.
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.
Read further about DMARC email authentication in the original article on Mailtrap blog.