Skip to Navigation
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.
| Tag | Meaning |
pct | 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. |
sp | 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. |
adkim | 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’. |
aspf | 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’. |
ri | 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). |
fo | 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’. |
How to implement DMARC records
The whole process comes down to the following steps:
- Validating if SPF/DKIM are set up and domains aligned.
- Generating a DMARC record and specifying its settings.
- Adding it to your domain’s DNS.
Verify if DKIM and/or SPF are set up properly
As mentioned earlier, having either of them is compulsory for DMARC to work. But having one that returns negative results for legitimate emails will also do no good. The DMARC test will fail automatically if SPF or DKIM fails.
If you have only SPF set up, check if the following two match:
- ‘Envelope from’ address – the address emails are sent from.
- ‘Return-path’ address – the address emails will be directed to if a recipient responds to an email.
If you rely only on DKIM, check if the following two match:
- ‘Envelope from’ address – the address emails are sent from.
- ‘d’ tag of your DKIM record.
If you use both methods (and rightly so!), perform both checks, of course.
Choose an email account for receiving DKIM records
A great thing about DMARC is that, when set up, your server starts sending you daily reports of how your emails performed (separate aggregate and forensic reports). This way, you can quickly spot any abnormalities and improve your performance using data.
Keep in mind that reports are sent in a raw, hard to read format. You may want to use tools like Dmarcian or MXToolbox to get the most out of data.
Generate DMARC record
And now, let’s finally generate a DMARC record. Dmarc.org recommends a number of resources for this task. There are several tags mentioned above you need to use in a record and a number of optional ones. Note that the ‘p’ tag (as in ‘policy’) will directly represent the previous step.
Add DMARC record to your domain’s DNS
Once you have your record, you can go ahead and add it as a DNS Record. You may be able to do it on your own or, in some cases, the help of your hosting provider may be needed.
In the domain registrar, you need to add the newly-created DMARC as a TXT record. We won’t go through any details here as the process differs for each provider. If you did everything correctly, you should receive your first reports within the next 24 hours.
Three major DMARC myths busted
DMARC is set for security reasons only
Partially true. DMARC indeed aims at preventing spoofing and phishing attacks. However, there is more to DMARC than that. DMARC enforcement policies and advanced reporting capabilities significantly improve legitimate mail delivery. They help build and increase brand trust and analytics. Thus, DMARC is quite a boost to any marketing campaign.
DMARC is just for domains that send mail
Not true. The fact that your domain doesn’t send emails does not mean that it cannot be impersonated. In fact, the more famous your brand, company, organization, or personality is, the higher the attraction malagents have to spoof it. The receivers of malicious emails from “your” brand will mostly not be able to identify that your domain is not configured for sending mail. As a result, you’ll have to face many unpleasant consequences concerning your reputation and credibility.
Setting DMARC policy to “none” is enough for email security
Wrong. Setting DMARC policy to ‘none’ is usually the first step to make sure that DMARC reporting and delivery is set right, but it doesn’t improve your security nor help protect your domain from being impersonated. Eventually, to make the best of DMARC security and marketing enhancement, you will need to arrive at a policy of (at least) quarantine or (best of all) reject at a pct=100.
Moreover, should you decide to move with the times and adopt BIMI as the latest brand authentication strategy, your DMARC record should be set to “reject” policy to be qualified for BIMI certification.
Why you should use DMARC?
We said it many times, but it’s worth repeating it again – DMARC is the most effective way to protect yourself from spoofing. Period. This alone should be a good enough reason to add the implementation of DMARC to your next sprint.
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.
There are two major DMARC benefits to consider:
- Cybercriminals are much more likely to give up on trying to spoof a domain if they see (properly configured) DMARC records in the domain’s DNS. 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).
Final thoughts
Email security should never 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.
