Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM) are two well-known email security protocols that help domain owners protect against domain impersonation in phishing emails. While both protocols do a good job of preventing domain impersonation, like any other protocol, they are also known to have specific weaknesses.
For example, both SPF and DKIM do not take the “From:” email header into consideration when verifying an email. A threat actor takes advantage of this and creates phishing emails that comply with SPF and DKIM.
To combat this, the Domain-based Message Authentication, Reporting, and Conformance (DMARC) protocol was invented in 2012. In this article, we look into this less-adopted protocol, how it works, best practices to consider when implementing it, and how to interpret and manage DMARC reports easily.
|
Concept |
Description |
|
DMARC |
DMARC is an email security protocol that is built on top of SPF and/or DKIM and was designed to cover one of its main weaknesses, namely the lack of alignment with the From email header. A threat actor can easily abuse this to deceive the victim about the origin of the email. |
|
Common reasons DMARC is not enabled |
Email administrators are sometimes reluctant when it comes to activating DMARC due to a lack of awareness, fear of misconfigurations, or the complexity of report interpretation. |
|
Consequences of no DMARC and how to avoid |
The lack of a DMARC record might hinder the delivery of legitimate emails from your domain. To avoid this, domain owners can increase the security awareness around DMARC, properly test DMARC/DKIM/SPF, and analyze DMARC reports. |
|
DMARC record anatomy |
Similar to SPF and DKIM, DMARC is implemented as a DNS TXT record. It contains several fields that define:
|
|
DMARC reporting and analysis |
DMARC provides two kinds of built-in XML reports that enable the domain owner to gain valuable insights into how their domain is being used in emails by legitimate and/or unauthorized entities. However, parsing, analyzing, and visualizing such reports is challenging to perform regularly. |
DMARC is an email authentication protocol developed to fix a key limitation in both SPF and DKIM. While SPF and DKIM rely on headers such as Mail From or DKIM-Signature for verification, they do not validate the From header — the one that is displayed to recipients as the sender of the email. This lack of verification creates a vulnerability that DMARC addresses by ensuring that the From header aligns with the authenticated domain, thereby improving email authenticity and trust.
For example, consider a threat actor that creates a domain like attacker.com. Since the threat actor is the domain owner, they can set up valid SPF and DKIM records for their domain and send out valid but malicious emails.
All they have to do is set:
The SPF and/or DKIM verification passes on the recipient’s mail server and delivers the email to the victim’s mailbox. Given that, by default, most email clients will only show the From, To, and Subject email headers, the victim only sees the From: forged_sender@trusted_vendor_domain.com and may trust the malicious email.
DMARC was created to solve this weakness of both SPF and DKIM. It works on top of SPF and/or DKIM and includes the From email header in the verification process. Using DMARC, an email is only considered valid if it passes the SPF and/or DKIM verification. The From email header must match other email headers, such as Mail From (i.e., “alignment”). This makes it much harder for the threat actor to forge a phishing email that impersonates your domain.
Compared to SPF and DKIM, DMARC is a relatively newer and less adopted email protocol. There are several reasons why your email administrator might be reluctant to enable DMARC.
Many domain owners or IT employees are unfamiliar with DMARC, what it does, or how to implement it. They often assume that SPF or DKIM is enough to protect the organization from domain impersonation. Furthermore, especially in small to mid-sized organizations, email authentication isn’t always prioritized unless a compliance or regulatory requirement mandates it.
Even if email administrators decide to implement DMARC, at some point, they will be faced with the dilemma of configuring DMARC in p=quarantine or p=reject mode. However, enforcing DMARC to quarantine or reject without proper testing might lead to legitimate emails getting rejected/quarantined, adversely impacting business. That is why email administrators might decide to leave DMARC in p=none mode to avoid any email delivery issues.
Since DMARC is dependent on the correct configuration of SPF and/or DKIM, a misconfiguration of these protocols leads to benign business emails getting rejected by recipients. To avoid additional challenges, the IT staff might opt out and not implement DMARC at all.
DMARC reports are typically received daily, are XML-based, often verbose, and hard to read without additional tools. Furthermore, depending on the size of the organization or how often it is abused for domain impersonation, the list of IP addresses, alignment results, domain names, and failure details might be overwhelming to understand or analyze regularly.
Without DMARC, receiver mail servers that have DMARC enabled cannot verify the authenticity of emails claiming to be from your domain. As a result, your organisation’s emails could potentially be rejected or sent to spam, hindering email delivery. This can negatively impact the effectiveness of marketing, partner relations, and customer outreach. We recommend:
Since DMARC’s introduction in 2012, over a decade has passed, and the IT community has experimented significantly with DMARC. There are numerous articles on the Internet from experienced IT professionals and documentation from mail server providers that thoroughly explain the DMARC protocol and how to correctly implement it. Email administrators can use all these resources to familiarize themselves with DMARC and get started.
Quarantine or reject are not the only modes DMARC provides. An email administrator should start testing DMARC by using the p=none mode, which instructs the recipient’s mail server to do nothing if the DMARC verification fails, but only report the email authentication results. After analyzing the DMARC reports for a while and making sure that legitimate emails are passing the DMARC verification as expected, the email administrators can gain the confidence to switch DMARC to strict mode, i.e., p=quarantine or p=reject.
The step-by-step process of carefully enforcing DMARC in strict mode
These two protocols have been introduced at least 10 years before DMARC, and are even better understood and adopted by the IT community than DMARC. Numerous articles simplify the process of setting up these protocols and avoiding misconfigurations. For example, in this separate article, we cover how to securely implement DKIM step-by-step.
While we agree that interpreting DMARC reports can be time-consuming, solutions have been developed to simplify this process for you. This service can help you manage, maintain, and simplify the analysis of DMARC reports, allowing you to save time.
Same as SPF and DKIM, DMARC is also configured as a DNS TXT record. To use DMARC, the domain owner has to create a new DNS TXT record for a specific subdomain of their domain, named _dmarc. In other words, if your domain is example.com, you need to create a DNS TXT record for _dmarc.example.com. A DNS TXT record for DMARC would look like this
|
v=DMARC1; p=none; rua=mailto:<some email address>; ruf=mailto:<some email address> |
It is important to emphasize that p=none should only be used during the audit or test phase of DMARC implementation. That is because, by setting DMARC to this mode, the receiving mail server will not take any action on an email that fails the DMARC authentication. To benefit from the email security benefits that DMARC provides, remember to change this field to a stricter DMARC mode.
DMARC is the only one of the three email security protocols (SPF, DKIM, DMARC) that provides the domain owner with reports concerning the email authentication of their domain. If DMARC is implemented, all mail servers that receive emails from your domain send the following reports to the email addresses configured in your DMARC report:
It is specified with the rua= field in your DMARC DNS record. It summarizes all the emails that were sent from your domain, regardless of the authentication result. It typically contains the following fields in an XML format:
It is specified with the ruf field in your DMARC DNS record. This is a detailed report for only failed DMARC authentications for your domain. It is also in XML format and contains the following fields:
These reports are (typically) sent daily by all mail servers that receive benign emails or malicious emails attempting to impersonate your domain. It is important to regularly review these reports to identify and react to domain impersonation trends promptly. For example, you may notify customers or business partners of an increasing trend of phishing emails impersonating your organization.
However, depending on the size of your organization, parsing, analyzing, and centrally visualizing the results of these XML-based reports might be quite time-consuming. We recommend investing in a solution that takes care of all these report processing steps. This way, you can save precious time and only focus on the already-parsed data and visualization to discover domain impersonation trends or debug email delivery issues, all in one place.
SPF and DKIM use two different approaches to achieve the same thing: ensuring your domain is protected from domain impersonation in phishing attacks. However, both protocols have a fundamental weakness that DMARC was designed to solve. DMARC was created 10 years after SPF and DKIM, and is less understood and adopted compared to the other two protocols.
This does not mean, however, that this protocol is less important than the other two. Moreover, while managing and analyzing DMARC reports might be cumbersome, solutions exist to simplify this process for you.