Sender Reputation and Email Security – Part 4: Domain-based Message Authentication, Reporting and Conformance (DMARC)
With SPF and DKIM, you can ensure the authenticity and integrity of emails and protect yourself and your company from phishing attacks and spam. But how do you deal with non-authenticated emails? And how can you be sure that no one is writing fake emails to your customers and partners in the name of your domain?
In the fourth part of our series of articles on sender reputation, we show you how you can use Domain-based Message Authentication, Reporting and Conformance (DMARC) to determine how the receiving server should authenticate your emails and what it should do if authentication fails. In addition, we explain how you can use DMARC to quickly be informed about abuse of your domain and thus protect the reputation of your domain.
Series of articles: Sender reputation and email security
Part 1: Authenticated Received Chain (ARC)
Part 2: Sender Policy Framework (SPF)
Part 3: DomainKeys Identified Mail (DKIM)
Part 4: Domain-based Message Authentication, Reporting and Conformance (DMARC)
In the previous articles in this series, we looked at different technologies that you can use to protect yourself and your company against attacks from the Internet:
With SPF and DKIM, you can therefore ensure the authenticity and integrity of emails. However, neither SPF nor DKIM give the receiving server explicit instructions on what to do with emails that have not successfully passed the SPF and DKIM checks. This gap is closed by Domain-based Message Authentication, Reporting and Conformance (DMARC).
What is Domain-based Message Authentication, Reporting and Conformance (DMARC)?
DMARC is an official IETF standard that builds on SPF and DKIM to reduce threats from phishing emails and spam. It answers the following questions:
In other words, DMARC allows an email sender to include additional information for processing sent emails. It tells the recipient
- how emails sent by him should be authenticated,
- what should happen to non-authenticated emails and
- to whom and how often reports should be sent back to the sender.
How does DMARC work?
To activate DMARC, the owner of a domain deposits a DMARC policy in his DNS zone. As with SPF and DKIM, the DMARC policy is stored in an RFC-standardised TXT record.
The policy contains information on which checks must be made by the recipient, i.e. SPF and/or DKIM. In addition, it specifies what the recipient should do if the checks fail: accept anyway, quarantine or reject.
Furthermore, the DMARC policy specifies email addresses to which reports are to be sent – the R in DMARC stands for reporting. These reports are generated by all servers on the Internet that support DMARC in receiving emails and have received emails from the respective domain. In addition, to prevent the amount of data generated by the reports from becoming too large, the DMARC policy can specify the percentage of emails for which a report is generated. Furthermore, the reports are collected and sent to the respective reporting address only once a day by default.
What does a DMARC entry look like?
The TXT entry used for a DMARC policy can contain the following fields:
| Field | Description | Examples |
|---|---|---|
| v | Version of the DMARC entry | v=DMARC1 |
| p | Policy on how to handle emails from the main domain that fail authentication | p=none: no action p=quarantine: quarantine p=reject: reject |
| sp | Policy on how to handle emails of the subdomain whose authentication fails | p=none: no action p=quarantine: quarantine p=reject: reject |
| pct | Percentage of emails to be reported according to DMARC policy | pct=100 (default) |
| rua | Specifies whether and to which email address an aggregated report of the received emails should be sent | rua=mailto:report@example.com |
| ruf | Determines whether and to which email address a forensic report on the received emails is to be sent. This report contains all details about the respective emails. Take note of data protection. | ruf=mailto:report@example.com |
| fo | Failure Reporting Options. Detailed setting for when emails are to be reported. Only applies in connection with “ruf”. | fo=0: SPF and DKIM have failed (default) fo=1: SPF or DKIM have failed fo=d: DKIM is considered failed if the signature is not correct – even if the key matches. fo=s: SPF is considered failed if the SPF evaluation fails for any reason, even if the SPF records in the header and DNS record match. |
| rf | Reporting Format. The file format for the reports. Only applies in connection with “ruf”. | rf=afrf: Authentication Failure Reporting Format (default) rf=iodef: Incident Object Description Exchange Format |
| ri | Reporting Interval. Frequency in seconds at which reports are sent. | ri=86400, once a day (default) |
| aspf | Alignment mode for the SPF check | s=strict, i.e. strict. The ‘MAIL FROM’ address must exactly match the Header-From address. Example: info@example.com r=relaxed, i.e. loose. It may also be a subdomain. Example: info@newsletter.example.com For more information, see mxtoolbox. |
| adkim | Alignment mode for the DKIM check | see above |
Examples of DMARC entries
dhl.com
v=DMARC1; p=reject; fo=0; rua=mailto:dmarc-reports@dhl.com, mailto:dmarc_agg@vali.email
Here, all non-authenticated emails are rejected if SPF and DKIM checks have failed (fo=0). In addition, aggregated reports are sent to the specified addresses.
gmail.com
v=DMARC1; p=none; sp=quarantine; rua=mailto:mailauth-reports@google.com
For non-authenticated emails to the main domain, nothing is done here, non-authenticated emails to the subdomain are quarantined. Since fo=0 is the default setting, these rules apply if SPF and DKIM checks have failed, even if it is not explicitly stated.
DMARC with SPF and DKIM
The different possibilities in DMARC testing with SPF and DKIM (highly simplified). A complete overview can be found here.
What can happen without DMARC? An example.
Imagine that your partners and customers are contacted using your domain and instructed to use a new (false) bank account for the payment of invoices from now on. Since the fake email can build on a previous communication history with the help of malware such as Emotet and uses your company’s domain, the fraud is not noticed at first and payments are made to the criminals’ account.
Only after the payment deadline has not been reached do you contact a customer. In the conversation that follows, it becomes clear that the money was indeed transferred weeks ago, but unfortunately to the wrong account.
DMARC could have prevented this with a reject policy, because then the non-authenticated email would have been rejected. Receiving servers sending DMARC reports would also have informed you in a timely manner about the failed SPF and DKIM checks as part of the reporting function. It is important to mention here that these protection mechanisms only take effect if the recipient has also implemented DMARC.
Protect the reputation of your domain
DMARC thus protects against phishing attacks and the resulting financial damage, but in addition, you prevent criminals from using your email domains to send masses of spam or phishing emails and thus destroy the domain reputation.
This abuse of your domain namely leads in many cases to the IP addresses of sending email servers ending up on block lists and being rejected by receiving email servers in the future. This means not only a danger for the communication flow between you and your customers and partners, but above all a great risk for the reputation of your domain.
How to check your DMARC record
With the help of tools such as mxtoolbox, you can quickly and easily check whether there is a DMARC record for your domain.
How to create a DMARC entry
(German only)
Best practices for implementing DMARC
We recommend implementing DMARC in several steps. Start with just monitoring your domain and gradually expand the policy to rejecting all emails that fail the DMARC check (p=reject).
Monitor
Start with monitoring only a subdomain and/or main domain and request the regular reports. For this step, the use of SPF and DKIM is not yet required. The corresponding DMARC entry could look like this:
“v=DMARC1; p=none; sp=none; rua=mailto:report@example.com”
Set up quarantine policy
Before you perform this step, you must have fully implemented SPF and DKIM. Once you have done this, implement a DMARC quarantine policy. This instructs receiving servers to put emails from your domain that do not pass DMARC checking into the spam folder. The corresponding DMARC entry might look like this:
“v=DMARC1; p=quarantine; sp=quarantine; rua=mailto:report@example.com”
Reject all non-authenticated emails
In the final step, you instruct receiving servers to reject emails from your domain that do not pass DMARC checks. The corresponding DMARC entry might look like this:
“v=DMARC1; p=reject; sp=reject; rua=mailto:report@example.com”
Set up DMARC and improve email security
Domain owners have improved control over their company’s electronic communication and improve the security of their IT infrastructure with the help of DMARC. Surveys have also shown that the use of domain as a sender address in spam mails decreases significantly once the domain is DMARC-protected.
The use of DMARC as an influencing factor for sender reputation is a milestone for security and efficiency in email communication. At the same time, it means that one does not fall behind in comparison to spam senders, since word has also spread there about the advantage DMARC-protected domains offer. The evaluation of the sender’s reputation is an extremely reliable instrument in the fight against constantly increasing amounts of spam and increasingly perfidious attack scenarios with malware.
