Skip to Navigation
Back in 2012, engineers from Microsoft, PayPal, Yahoo!, and Google met to discuss making authenticating emails even more bulletproof. Soon after, they released DMARC to the world.
What’s the purpose of DMARC; how it looks and works, plus many more questions related to the famous authentication protocol get answered in the text below. Make sure you keep reading!
What is DMARC?
We’ll kick off with a basic question – “What does DMARC stand for?”. And the answer is – Domain-based Message Authentication, Reporting & Conformance.
DMARC leverages DKIM (DomainKeys Identified Mail) and/or SPF checks (Sender Policy Framework) to perform a more advanced validation on each email message received.
DKIM authentication uses DKIM signatures to verify the integrity of an email’s content and its source. SPF, on the other hand, lets a domain owner authorize IP addresses to send email under the domain name and is used by internet service providers like Gmail, Yahoo, etc.
With DMARC authentication, a domain owner can specify their own authentication procedure, also known as a DMARC policy. Using the policy, 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 domain.
How does DMARC work?
The understand how DMARC works you should know that it requires either an SPF record or a DKIM record – better yet, both of them.
When an email is received, a receiving server does a DNS (Domain Name System) lookup and checks if there’s an existing DMARC record.
DKIM/SPF is performed as usual.
The receiving server then performs a so-called “DMARC alignment test” to verify if:
- In the case of SPF, the “envelope from” email address within the hidden technical header of the email 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 (email sender’s domain) matches the domain the email was sent from.
Of course, if both authentications are set up, both alignment tests are 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 authentications 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 succeed (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 emails that fail authentication.
Three options are available (they’re referred to as “policies”):
- “none” – the email should be treated the same as if no DMARC was set up (the 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 deliverability.
- “quarantine” – allow the email but don’t deliver it to an inbox. Usually, such messages go to the spam folder.
- “reject” – discard the email that failed the check right away.
These policies can also be customized. For example, with a “quarantine” policy, you could tell the email server to send only 10% of emails with a failed check to the 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 fully follow your advice. Still, it does put 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 with aggregated data about unsuccessful checks. This is invaluable for analyzing the performance of your message and keeping you in the loop if any phishing scams occur.
Why use DMARC?
We said it a few times, but it’s worth repeating again – DMARC is the most effective way to protect yourself from spoofing. Period.
Not only that, but in 2024 Google and Yahoo make the DNS email authentication #1 requirement for bulk senders. So you have to do it.
To put things into perspective, 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.
Without listing any other benefits of DMARC, this alone should be a good enough reason to add the implementation of DMARC to your next sprint.
But, if you need more, 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 worth 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).
What does a DMARC record consist of?
Got the basics? Great! Now, let’s break down a DMARC 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 email, so it’s no surprise they chose to protect themselves with DMARC.
You can access Square’s record under this link which leads to a site that will show you DMARC records for any domain, given, of course, that it has been configured.
v=DMARC1; p=reject; rua=mailto:dmarc-rua@square.com,mailto:dmarc_agg@vali.email,mailto:postmasters@squareup.com; ruf=mailto:dmarc-ruf@squareup.comLet’s go through each DMARC parameter of the above record, one by one.
v=DMARC1
This is the identifier (a DMARC version) that should always be included in the DNS record, as the receiving mail server always looks for it. If v=DMARC1 is missing or is modified in any way, the whole verification will be skipped.
p=reject
This is the policy Square chose to use, which rejects 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 emails that failed the verification. The reports will contain high-level data on the reasons for failures without giving any details for each. All the addresses added here must be proceeded with “mailto:” as in the example above.
ruf=mailto:dmarc-ruf@squareup.com
This is an email address to which individual forensics reports (a.k.a. failure reports) will be sent in real-time, including the details of each failure.
Other DMARC example records
In the Square DMARC record example, we showcased a record with a policy of “reject”. To cover the remaining two policy variations, we’ll now use some dummy data simply for demonstration purposes.
DMARC record with a policy of “none”:
v=DMARC1; p=none; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;Explanation:
- “p=none” specifies a “none” policy, which means that no action should be taken on emails that fail DMARC authentication.
DMARC record with a policy of “quarantine”:
v=DMARC1; p=quarantine; rua=mailto:dmarcreports@example.com; ruf=mailto:dmarcfailures@example.com;Explanation:
- “p=quarantine” specifies a “quarantine” policy, which means that emails that fail DMARC authentication should be quarantined or flagged as suspicious by the recipient’s email system but still delivered to the recipient’s inbox.
As is usually the case, there are also several optional fields that can be added to a DMARC record to customize it a bit.
| Tag | Meaning |
pct | Set the percentage of failed emails that the set policy should apply to. 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 for 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 as the one above, 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 also be allowed. Also, you can choose to be “strict” or “relaxed”. |
ri | Sets the intervals for how often you want to receive aggregate reports with authentication results (“rua” tag). The value is expressed in seconds and, by default, is 86400 (every 24 hours). |
fo | Settings for the forensics reports (“ruf” tag). You can choose to send the report if: “0” – all underlying checks fail to return a positive DMARC result; “1” – any mechanism fails; “d” – DKIM failed to verify; “s” – SPF failed to verify. By default, it’s “0”. |
How to implement DMARC records
The whole process of DMARC implementation comes down to the following steps:
- Validating if SPF/DKIM is set up and domains are aligned.
- Generating a DMARC record and specifying the DMARC settings.
- Adding it to your domain’s DNS.
Verify if DKIM and/or SPF are set up properly
As mentioned earlier, having DKIM or SPF is compulsory for DMARC to work. But having either one return 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, so you may want to use tools like Dmarcian or MXToolbox to get the most out of the data.
Generate the DMARC record
And now, let’s finally generate a DMARC record.
Dmarc.org recommends a number of resources for this task. Also, there are several tags mentioned earlier you need to use in the record and a number of optional ones.
Do note that the “p” tag (as in ”policy”) will directly represent the previous step.
Add the 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 this 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 hosting 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 to prevent email 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 improve brand trust and analytics. Thus, DMARC can provide 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 chances some spammer wants to spoof your domain and use it for malicious activities like sending fraudulent emails, be it marketing or transactional.
The recipients of malicious emails sent from “your” brand will most likely be unable 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 the DMARC policy to “none” is enough for email security
Wrong. Setting the DMARC policy to “none” is usually the first step to making sure that DMARC reporting and delivery are 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 use the policy of (at least) p=quarantine or (best of all) p=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 the “reject” policy to be qualified for BIMI certification.
Final thoughts
Email security should never be underestimated. The bigger you are, the more you have to lose if someone spoofs your domain and tricks your customers into something you probably wouldn’t approve of.
Given how easy it is to add each authentication method and how much you gain by having them all properly set up, there’s little reason not to give it 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 email deliverability.
On top of that, you’ll receive tons of data via the DMARC reports covering authentication issues. Using this, you can quickly identify if someone is trying to spoof your domain and potentially asking recipients to provide sensitive information or if a problem lies on your side so you can do proper troubleshooting.
