Introduction
As people have grown comfortable with e-commerce and email correspondence, the techniques of scammers have become increasingly sophisticated and hard to detect. Many of us have heard of phishing attacks, in which bad actors coerce people into handing over sensitive information. These are usually carried out by impersonating a trusted third party – and overwhelmingly through email (Deloitte, 2020). While the threat of phishing may often be understated (considering how often phishing emails appear in our inboxes), a successful attack can have a devastating impact on a business, with more than $2.7 billion lost due to business email compromise in 2022 alone (FBI, 2022).
With the threat of phishing likely to worsen over the coming years (Proofpoint, 2023), it is imperative that business leaders educate their workforce about phishing and how to recognize fraudulent email. In addition to user education, technical solutions can be applied to email infrastructure. One important tool in the fight against phishing is DMARC, a protocol that works with existing technologies to help domain owners protect their brand as well as their customers. Here, we discuss the role that DMARC plays in email authentication, and why it should be a key component of your email security solution.
The problem
Email is inherently vulnerable. Many vulnerabilities arise from the fact that each email contains two ‘from’ addresses: the Envelope From (RFC5321.MailFrom as per RFC 5321), located on the envelope, and the Header From (RFC5322.From as per RFC 5322), located within the message itself. Much like regular mail, the Header From denotes the author of the message, while the Envelope From indicates the message sender and is used by mail servers for routing. Usually, the two addresses are identical, but in some cases (e.g., when distributing an email newsletter), the Envelope From may be altered to indicate a different sender. While existing email authentication protocols are able to stop some kinds of abuse, neither of these authenticate the Header From address, the one usually displayed to the recipient. This allows scammers to impersonate trusted parties by forging the Header From address.
Imagine that Alice, a scammer, has just sent an email to Bob, purporting to be from Stapler King, his favorite stationery supplier (Fig. 1). Let’s see what happens without DMARC.
Figure 1. A spoofed email featuring the domains used in sender authentication. Without proper countermeasures, Alice can use the sking.onmicrosoft.com domain to send an email on behalf of a staplerking.net Header From address (usually the only address displayed by email clients).
Without DMARC
When Bob’s mail server receives this email, it first checks the email header to determine whether it conforms to the SPF (RFC 7208) and DKIM (RFC 6376) standards. SPF is used to specify the hosts that are allowed to send email on behalf of a domain. DKIM makes use of cryptographic signatures to determine whether the email was modified during transit. The configuration of these email security protocols (including DMARC) is published by domain owners to DNS as TXT records, such that they can be retrieved by any mail server worldwide. In our case, the domain of the Envelope From address will be used to retrieve the SPF record, and the domain of the DKIM signature will be used to retrieve the DKIM record.
The problem with using SPF and DKIM in isolation is that neither protocol cares about the Header From domain. Assuming Alice is in control of the sking.onmicrosoft.com domain, the spoofed email will pass both authentication tests and reach Bob’s inbox, where he may be lulled into a phishing attack. Further, even if an email fails either test, there is no way to know how the receiving mail server will handle the failure. Some mail servers may discard the email or mark it as spam, but others may disregard the authentication results entirely and simply deliver the message – a worst case scenario!
With DMARC
DMARC (RFC 7489) addresses this last issue by allowing administrators to specify how to handle authentication failures, either by (i) delivering them, (ii) marking them as spam, or (iii) discarding them outright. The first option offers no protection but is useful in first-time deployments when used in conjunction with DMARC’s reporting features, which allow security teams to periodically review the effectiveness of their implementation. In particular, these reports can be used by email administrators to monitor authentication statistics and delivery rates, as well as how often (and by which hosts) domains are spoofed.
Aside from the enforcement of authentication policy, DMARC tests for domain alignment, such that at least one of the domains used to validate SPF and DKIM matches the Header From domain. This means that an email will pass DMARC if either (i) SPF passes and there is alignment with the Envelope From domain, or (ii) DKIM passes and there is alignment with the DKIM domain. As long as Bob’s email provider has implemented DMARC properly, Bob will never have to deal with the Stapler King forgery (and many others), leaving him more time to nurture his extensive stapler collection.
Using DMARC
To illustrate how DMARC works, we will step through some example scenarios (Fig. 2) and explore how a maturing security program may be reflected by DMARC policy. Continuing with our hypothetical situation, the administrator for Stapler King, Joe, has just set up SPF and is now deploying DMARC for the staplerking.net domain.
Figure 2. Example scenarios and corresponding DMARC records for the staplerking.net domain. Highlighted tag-values indicate configuration parameters (blue: DMARC policy, yellow: destination URIs for aggregate reports, white: percentage of authentication failures on which to apply policy). Third-party authorization records (purple rectangle) are published by a third-party entity (in this case, the owner of the mailliege.com domain) to authorize the delivery of reporting emails.
A DMARC record is specified using tag-value pairs and separated by semicolons. Records must always start with the version pair, v=DMARC1, and be immediately followed by the policy pair. Once Joe is satisfied with his record changes, he publishes them to DNS as TXT records under the name _dmarc.staplerking.net.
Scenario 1: passthrough policy
Since Joe is setting up DMARC for the first time, he wants to make sure that the configuration is working properly, without inadvertently blocking legitimate mail. He does this by setting up a passthrough policy (i.e., when the policy tag-value pair is specified as p=none) that allows him to monitor the results of authentication without actually acting upon the results.
A policy of ‘none’ means that no email coming from the domain will be affected by authentication failure. The rua tag indicates the URI of the mailbox (almost always a mailto link) to which aggregate statistics about authentication failures will be sent. An alternative reporting tag, ruf, can be used to request detailed forensic authentication reports, although the volume of information provided can be overwhelming for teams that are unprepared to deal with them.
Scenario 2: limited enforcement
After Joe becomes more confident in his implementation, he shifts to an active policy (where p=quarantine or p=reject) that acts on a subset of illegitimate emails from his domain. This record tells mail servers to apply the ‘quarantine’ policy to 10% of all staplerking.net emails that fail DMARC. Such emails, while not discarded, will be forwarded to a spam or junk folder, or otherwise marked to indicate the authentication failure to the recipient.
Care should be taken with the pct tag. As long as it specifies a value less than 100, some emails that are confirmed to be fraudulent will end up being delivered!
Scenario 3: full enforcement
Joe eventually decides that the configuration is reliable enough to instruct mail servers to act on all authentication failures, which is done by either removing the pct tag-value or by setting pct=100. Administrators that have full confidence in their implementation can opt to discard authentication failures outright, which is done by setting the policy to ‘reject’.
As the business grows larger, Joe’s thoughts turn towards outsourcing his email security. The following two scenarios discuss the possible changes to the record that may be brought on by (not going forward with) this decision.
Scenario 4A: third-party security
Joe commissions MailLiege (a hypothetical third-party provider) to implement SPF, DKIM and DMARC on behalf of Stapler King. Since mailliege.com is a third-party domain, MailLiege needs to publish an authorization record, an additional DNS TXT record that authorizes receiving servers to direct reports to the specified URI. This authorization record (set to v=DMARC1;) is retrieved from DNS with the record name staplerking.net._report._dmarc.mailliege.com.
Scenario 4B: full enforcement, no reporting
In this scenario, Joe decides not to outsource his email security. After an extensive monitoring phase, Joe has concluded that DMARC and SPF have substantially mitigated all commonplace spoofing attacks against the domain and has now forgone reporting entirely.
Analyzing DMARC
In this section, we take a look at how DMARC is deployed in the wild.
Adoption
As with many security protocols, adoption has been slow. Today, just over half of popular domains observed from passively-collected DNS responses could be associated with a DMARC record (Fig. 3), with this figure jumping to 79% for highly popular domains (Fig. 3).
Figure 3. DMARC prevalence in passively-collected DNS responses for (a) the top 1,000,000 domains (mean: 49,462 per month) and (b) the top 1,000 domains (mean: 454 domains per month). Popularity was assessed in June, 2023 using the Tranco list.
Policy versus popularity
In practice, we find the records of more popular domains tend to use the reject policy, while owners of less popular domains are more likely not to act on authentication failures (Fig. 4). This makes sense, as popular domains tend to have greater brand recognition and more value as a spoofing target. On the other hand, there may be less pressure on relatively unknown companies to go out of their way to implement domain security.
Figure 4. DMARC policy versus domain popularity (tier 1: most popular) for actively-collected records from August, 2023. Popularity is defined using the Tranco list ranks such that tier 1 includes the top 100 ranked domains, tier 2: ranks 101-1,000, tier 3: ranks 1,001-10,000, etc. Domain counts for each tier are indicated in parentheses.
Common DMARC issues
There are many ways to misspecify a DMARC record. By far, the most common issue is a bad “preamble”, where the record does not start with valid version and policy tag-value pairs (Fig. 5). Other issues include specifying multiple records under a single DNS TXT name, missing mailto from reporting URIs and invalid reporting URI separators. Administrators can avoid some pain by using online tools (such as this one from EasyDMARC) to validate their records before going live.
Figure 5. Issue prevalence for invalid DMARC records for actively-collected records from August, 2023 (Bitsight). Records that do not start with v=DMARC1; p= are said to have a bad “preamble”. Other issues include the incidence of multiple records for a single domain, and invalid reporting URIs.
Securing SPF and DKIM
To be useful, DMARC needs to be deployed in tandem with SPF or DKIM. In spite of this, at present, only a third of passively-observed domains could be associated with the requisite authentication protocols (blue shading in Fig. 6). While this fraction appears to be improving over time, the reality is that many domains are ripe targets for abuse by bad actors.
Figure 6. Prevalence of email authentication protocols collected from passively-collected DNS responses for the top 1,000,000 Tranco domains (mean: 49,462 per month). Grey shading indicates ineffective protocol combinations.
It stands to reason that SPF and DKIM must themselves be configured properly. While SPF appears to be the most widely used email authentication protocol, recent investigations have found that SPF records are often compromised by vulnerable configurations (CanIPhish, 2022; URIports, 2022) that in some cases offer no protection at all. Domain owners would do well to follow security best practices for both protocols (URIports, 2023), which include using the softfail mechanism (~all) and avoiding deprecated mechanisms for SPF, and using strong public keys for DKIM (at least 2048-bit key length).
Beyond DMARC
Aside from deploying SPF, DKIM and DMARC, there are other measures that businesses can take to improve their domain security. While the aforementioned work together to prevent abuse of an actual domain, such as staplerking.net, they do not protect against other forms of spoofing in which slight variations of the domain (e.g., stap1erking.net) are used to deceive recipients. Companies can register common misspellings of their domain to prevent typosquatting, the practice of registering these domain variants with an eye towards illegitimate future activity, shielding their customers from social engineering attacks.
A key issue with DMARC concerns the underlying assumption that a legitimate email will not change during transit. The Authenticated Received Chain (ARC) protocol was introduced to handle cases where legitimate changes made to emails in transit by mail servers would cause authentication failures. For example, a forwarding service may cause SPF to fail by sending messages from a different IP address, while messages sent through a mailing list may have their subject modified, resulting in DKIM failure. ARC preserves the authentication results from prior mail servers such that a receiving mail server can choose to accept an altered (and therefore “illegitimate”) email, so long as the alterations were made by trusted entities.
To encourage greater DMARC adoption, a working group consisting of Google, Verizon, Yahoo and others devised the Brand Indicators for Message Identification (BIMI) specification. Through BIMI, companies who have properly implemented DMARC will be able to display their logo alongside emails addressed to their customers. Aside from an improved user experience, customers would be provided with a visible indication that the company takes their email security seriously – much like what the SSL padlock icon does for URLs in the browser.
Conclusion
DMARC helps site administrators protect their domains from domain spoofing, but adoption has been slow. Companies may be apprehensive about deploying DMARC for several reasons – the effort required may be burdensome for businesses with complicated infrastructure, or perhaps leadership do not appreciate the risks that spoofing attacks pose to the business. In any case, any apprehension would likely seem short-sighted in the aftermath of a well-coordinated spoofing attack.
The DMARC standard has been designed to allow businesses to roll out domain protection at their own pace. Using just three configuration parameters (p,rua,pct), administrators can monitor the status of their deployment and choose to act on authentication failures when confident in their solution. Today, companies can use DMARC to all but eliminate one of the most common phishing attack vectors, protecting their brand from impersonation and making it harder for scammers to operate.
How secure is your domain?