Table of contents
What is DMARC?
DMARC (Domain-based Message Authentication, Reporting and Conformance) is a standard for monitoring problems related to email authentication and domain name abuse.
The aim is to combat spam and phishing (cf. identity theft). DMARC uses the SPF and DKIM authentication systems to apply a security policy in the event of failure, and to notify the message owner via a feedback mechanism and a deliverability monitoring.
DMARC also ensures the consistency and legitimacy of the domain names used to send the message (see below for more details on this subject).
Background and challenges
In 2018, 75% of businesses experienced at least one phishing attack in the past two years.
An alarming observation
In 2018, according to a study conducted by ProofPoint (Leader in securing email flows in large enterprises) on email fraud, 75% of companies have experienced at least one phishing attack in the past two years. These phishing attacks are directed at both the employees of these companies, and their customers.
We must not forget that the email channel remains the main source of spam and identity theft in the world. The SMTP protocol (Simple Mail Transfer Protocol), designed in the 80's, 9 years before the web, was not developed with strong security standards. It is easy for a malicious person to pretend to be someone he is not.
Implementation of authentication systems
To make the email channel a little more secure, all the market players have successively implemented authentication standards - we are talking here about SPF and DKIM - whose objective is to protect the good senders as much as possible and to refuse emails detected as fraudulent or illegitimate.
Unfortunately SPF and DKIM both have their limits and it is in 2015 that DMARC (Domain-based Message Authentication, Reporting and Conformance) appears to reduce this volume of spam and fraudulent emails by providing email senders with reports on the use of their domains and allow them to apply a security rule in case of SPF and DKIM failure.
Even if the arrival of DMARC allows to identify these illegitimate sources, its deployment is unfortunately not yet a priority for many companies.
Why this guide?
We conducted a study on the deployment of DMARC among CAC40 and TOP 100 French E-commerce companies and found that a minority of companies had still not deployed DMARC on their main domain.
We must not forget that the email channel remains the main source of spam and identity theft in the world. The SMTP protocol (Simple Mail Transfer Protocol), designed in the 80's, 9 years before the web, was not developed with strong security standards. It is easy for a malicious person to pretend to be someone he is not.
The initiative behind this guide for us is threefold:
- Realize that no company is safe from a phishing attempt
- Be aware of the need to implement DMARC as soon as possible on all routing infrastructures in order to identify all your domain traffic
- Leverage data from various DMARC reports to reduce fraudulent emails.
Objectives
Considering the major security risk of its ecosystem, the deployment of DMARC on all the company's sending domains becomes a major objective. This deployment would allow :
- Minimize the risk of false positives (i.e. emails mistakenly considered as spam or phishing by anti-spam filters or by your customers) thanks to the validation of SPF/DKIM authentication systems and DMARC compliance
- Retrieve detailed authentication reports to identify illegitimate traffic on the one hand and misauthenticated legitimate traffic on the other.
- Enforce the sender's policy with the recipients (via the security policy defined in the DMARC policy).
- Reduce delivery of fraudulent emails to employees and customers/vendors.
We must not forget the multiple challenges of the company:
- Protect their domain names from fraudulent use.
- Protect their employees from fake emails supposedly coming from the management.
- Protect their customers/suppliers from personal information theft.
- Protect their reputation and identity.
Fighting phishing with DMARC
The main interest of DMARC is of course to fight against phishing. Its implementation will allow you to quickly know who is using your domain name without your knowledge.
The most impactful action is going to be the tightening of the policy. After a period of monitoring, analysis and compliance, you will move your policy from "none" (no action) to "quarantine" (spamming) to "reject" (refusal of non-compliant email). This change to "reject" will allow you to considerably reduce the risks of identity theft on your domains and sub-domains.
To achieve this result, it is important to work with all of your partners to ensure that all of your domains and email flows are compliant. Once the policy is set to "reject", all emails using your domain name that do not comply with the DMARC compliance rules will be refused by the messengers.
Be careful though, DMARC has a limit of exploitation, only ISPs / Webmails / Anti-Spam Filters knowing how to interpret DMARC will be able to apply the "policy" (among others Gmail, Microsoft, Yahoo, La Poste, ...).
What are the DMARC features?
We gave a brief introduction to DMARC at the start of this guide. But what does DMARC actually do?
Declaration of a policy
The first feature is the application of a security policy.
For DMARC to be effective, a security policy must be defined upstream by the domain administrator. In case of SPF and/or DKIM failure, this policy will be applied by the organization receiving the email. There are 3 levels of settings:
- "none" : nothing special happens, the server receiving the message does as usual, as if no DMARC record was present. Only feedbacks are sent to the sender.
- "quarantine": this statement asks the receiving server to inspect the email with a higher level of attention than usual. If this fails, the email will have to be put in spam.
- "reject": this policy asks the receiving server to reject the email addressed to it if it does not respect SPF, DKIM or domain alignment rules.
To continue the small study we conducted on the deployment of DMARC at CAC40 and TOP 100 E-commerce companies, we looked at which DMARC security policy is applied to each company's main domain:
Even today, few companies have taken the plunge and turned their security policy into a "reject".
Analysis of DMARC reports
The second feature of DMARC allows you to receive detailed reports about the results of SPF and DKIM authentication.
These reports allow domain owners to track and analyze legitimate and illegitimate activity generated by email traffic from their domains. This mechanism offers the possibility to intervene quickly in case of a major incident such as a phishing attack or loss of authentication on a legitimate source.
The reports are sent by email in XML format, but many DMARC monitoring tools allow you to simply analyze the results and generate automatic alerts.
DMARC... That's cool! BIMI... Is that better?
Always with the aim of going further and protecting brands and messaging users, a new standard was created and appeared a few months ago, it is called BIMI!
The interest of BIMI is to display a logo of the brand in the mailbox of the recipient ... if it has a good reputation!
The most important criterion remains the implementation of DMARC. It must be correctly deployed on your domains with a DMARC security policy restricted to "quarantine" (at least) or "reject" (strongly recommended).
This means that you can only implement BIMI if DMARC is already well established. Today, Yahoo (Verizon) & Google (since spring 2020) are already able to interpret BIMI! Others should follow later this year and in 2021.
As you can see, BIMI is a kind of carrot to encourage marketers to secure their email flows: "If you secure your emails, you will get a nice logo in my webmail!"
Focus on the notion of domain alignment
To make all email flows compliant with SPF & DKIM, a domain alignment is necessary. Unfortunately, SPF & DKIM are not based on the same domain. SPF authenticates the "MailFROM" domain and/or the "Helo/Ehlo" domain (not visible to the user) while DKIM authenticates the "From" domain (sending address).
SPF Alignment
Authentication-Results:mx.google.com;
dkim=pass header.i=@badsender.com header.s=selector2 header.b=S0W1FpEi;
arc=pass (i=1 spf=pass spfdomain=badsender.com dkim=pass dkdomain=badsender.com dmarc=pass fromdomain=badsender.com);
spf=pass (google.com: domain of sfi@badsender.com designates 40.107.5.62 as permitted sender) smtp.mailform=sfi@badsender.com;
dmarc=pass (p=QUARANTINE sp=NONE) header.from=badsender.com
From: "Sébastien Fischer"
To: Badsender Deliv Team
Subjet: DMARC Alignment
Date: Tue, 11 Aug 2020 14:18:20 +0000
Example 1: The From address is yesreply@badsender.comthe address declared in the MailFRom is yesreply@badsender.com
=> Domains are aligned for SPF (FROM and MAILFROM domains are identical) the "strict" alignment policy must be set (cf. aspf="s").
Example 2: The From address is yesreply@badsender.comthe address declared in the MailFRom is yesreply@emailing.badsender.com
=> Even if the FROM domain is different from the MAILFROM domain (yet they are part of the same infrastructure), it will be considered aligned in "relaxed" mode, but not in "strict" mode.
DKIM Alignment
Authentication-Results:mx.google.com;
dkim=pass header.i=@badsender.com header.s=selector2 header.b=S0W1FpEi;
arc=pass (i=1 spf=pass spfdomain=badsender.com dkim=pass dkdomain=badsender.com dmarc=pass fromdomain=badsender.com);
spf=pass (google.com: domain of sfi@badsender.com designates 40.107.5.62 as permitted sender) smtp.mailform=sfi@badsender.com;
dmarc=pass (p=QUARANTINE sp=NONE dis=NONE) header.from=badsender.com
From: "Sébastien Fischer"
To: Badsender Deliv Team
Subjet: DMARC Alignment
Date: Tue, 11 Aug 2020 14:18:20 +0000
Example 1: The From address is yesreply@badsender.comthe "d" tag declared in the DKIM public key is [d=badsender.com](http://dbadsender.com/).
=> Domains are aligned for DKIM (FROM and "d=" domains are identical) the "strict" alignment policy must be set (cf. adkim="s").
Example 2: The From address is yesreply@badsender.com, the "d" tag declared in the DKIM public key is [d=emailing.badsender.com](http://demailing.badsender.com/).
=> Even if the FROM domain is different from the domain declared in "d=" (yet they are part of the same infrastructure), it will be considered aligned in "relaxed" mode, which will not be the case in "strict" mode.
For maximum security of the infrastructure, a "strict" alignment policy is strongly recommended.
How to deploy DMARC?
Take your time: Deploying DMARC and upgrading the policy should be done gradually.
You can't directly apply a "reject" policy overnight without having a disastrous impact on whole swaths of your legitimate traffic that are incorrectly set.
You must therefore take the time to analyze the reports received in order to correct all the problems affecting legitimate traffic. Once all legitimate traffic is correctly authenticated and respects the domain alignment rules, you can progressively apply a more and more restrictive security policy "None" then "Quarantine" then "Reject".
You will anyway have the possibility to set the restrictive policies (quarantine & reject) of DMARC only to a portion of the traffic during these transition periods before applying them to 100%.
Think about attacks that don't use your domains: Look-a-like domains
DMARC is only effective against phishing attacks if they use your domain names on which DMARC is configured. But we mustn't forget that our "friends" the spammers and hackers are often... very good at what they do... especially when it comes to deceiving third parties. Let's imagine a phishing attack made with the domain "mail.pay-pal.com". As this domain does not belong to Paypal, Paypal will have no way, via DMARC, to be alerted of this attack.
It is therefore important to use other analysis techniques, based for example on mass monitoring of domains close to yours in order to check if they appear in blacklists or if they are visible to spamtraps networks.
Evaluate the size and complexity of the infrastructure
This first step must take place before the initial configuration of DMARC and the monitoring solution that will be used for implementation and monitoring.
The objective is to list all the domains to be monitored and for which you want to use a "reject" policy.
REMEMBER: Your domains are sometimes used by partners to send emails. These partners will also have to set up DMARC and apply the same policy as you in order to protect all the email flows that concern you.
1st analysis of collective data
Once DMARC is implemented and operational on all your domains (with a "none" policy at first), the reports will come in very quickly. These reports should be studied in order to have a first basis to evaluate the situation and to answer the following questions:
- What are the different email sources for your domains?
- What is the compliance level of the sources in question?
- Which sources are identified as legitimate?
- In the sources not identified as legitimate, which ones are from partners and which ones are from attacks?
- What are the major problems? Lack of authentication, alignment problems, ...
In case of identification of serious problems (example: an unknown IP located in an Asian country and using your sending address), you will have the possibility to act immediately by contacting the host of the IP of this usurpation but also to alert the organizations of fight against the spam (like Signal-Spam).
Identification of priority projects
Based on the analysis of the complexity of the infrastructure to be secured, the first data collected and potentially the extent of the damage caused by the look-a-like domains, you can then define a precise plan on the DMARC settings you will have to deploy.
- Define a "quarantine" or "reject" security policy.
- Define a "strict" or "relaxed" (or soft) alignment.
- Define the strategy for partners using your domains: should you switch them to other domains or have them use the same DMARC settings as you?
- Define what actions to take in case of phishing detection.
Compliance
Compliance is the action of making your email traffic compatible with DMARC (authentication and domain alignment mainly). This will not be done in one day, it may even take several weeks or months (depending on the complexity of the infrastructure and internal procedures).
During this transition period, you will be tasked with analyzing, through the collection of report data, to identify any legitimate traffic that does not have sufficient compliance for a switch to policy reject. You will then need to contact the various legitimate sources to assist them in making the necessary changes. Once the corrections are made, you will need to verify them and ensure that the traffic has become DMARC compliant. If it is not, you will have to continue to exchange with the different sources until they are compliant.
Deployment of the policy=reject
As soon as compliance is reached, you will have to progressively change your policy to "reject". The advantage of DMARC is that you will be able to define a percentage of non-compliant (and unauthenticated) traffic on which the DMARC policy will be applied.
Example 1: Only 10% of traffic that will not comply with the domain badsender.com will be put in junk mail.
v=DMARC1; p=quarantine; rua=mailto:dmarc_agg@dmarc.250ok.net; ruf=mailto:dmarc_fr@dmarc.250ok.net; fo=1; adkim=r; aspf=r; rf=afrf; pct=10; sp=none;
Example 2: 100% traffic that will not conform with the domain badsender.com will be put in junk mail.
v=DMARC1; p=quarantine; rua=mailto:dmarc_agg@dmarc.250ok.net; ruf=mailto:dmarc_fr@dmarc.250ok.net; fo=1; adkim=r; aspf=r; rf=afrf; pct=100; sp=none;
Thus, the implementation of a deployment plan over several weeks/months is desirable (or even essential) to ensure that everything is in compliance:
- 1st to 2nd week: setting to "quarantine" at 5%
- 3rd to 4th week: setting to "quarantine" at 25%
- 5th to 6th week: setting to "quarantine" at 50%
- 7th to 8th week: set to "quarantine" at 100%
- 9th to 10th week: set to "reject" at 5%
- 11th to 12th week: set to "reject" at 25%
- 13th to 14th week: set to "reject" at 50%
Deployment of BIMI
Once the "policy reject" has been applied to 100%, the BIMI configuration can be set up on your DNS servers (even if, in theory, as soon as you go to "quarantine", BIMI can be deployed).
The only verification that will have to be done is that the logo is correctly displayed in the messengers supporting BIMI at that time (Yahoo! and Gmail to date).
Maintenance and monitoring
After the adoption of the "reject" security policy, you should nevertheless continue to monitor for at least 6 months any possible compliance problems (and correct them if necessary), without forgetting of course to continue monitoring attacks (which will be permanent because spammers never take a vacation).
Frequently asked questions about DMARC
Do DMARC reports go back to the DMARC record of the root domain?
While DMARC's logic is one of inheritance from root domains to sub-domains, the reverse is not true.
For example, if the domain badsender.com has a record of this type :
v=DMARC1; p=reject; rua=mailto:dmarc@badsender.com; ruf=mailto:dmarc@badsender.com; fo=1;But the subdomain email.badsender.com has a DMARC record of this type :
v=DMARC1; p=reject; rua=mailto:dmarc-subdomain@badsender.com; ruf=mailto:dmarc-subdomain@badsender.com; fo=1;So DMARC reports generated for the email.badsender.com sub-domain will arrive at dmarc-subdomain@badsender.com and not dmarc@badsender.com.
On the other hand, a sub-domain that does not have its own DMARC record will have its reports sent to dmarc@badsender.com.
