" Domain-based Message Authentication Archives - LuxSci

Posts Tagged ‘Domain-based Message Authentication’

Preventing Email Forgery Part Three: DMARC

Tuesday, December 19th, 2023

In our previous two posts in this series, we examined how SPF and DKIM can help limit forged email messages by looking at the IP address and validating if the message was sent from an approved source based on digitally signed messages. We found that while SPF and DKIM can effectively prevent email fraud and forgery, weak implementations can make them vulnerable to attackers.

That’s where DMARC comes in. When properly implemented, DMARC provides instructions for what email filters should do with messages that fail SPF or DMARC. 

implementing DMARC in DNS

DMARC: A Simple Explanation

When using SPF and DKIM, email filters check if messages pass or fail SPF and DKIM. They use the DNS-published strictness settings to help them determine what to do next. How a particular filter is implemented determines what happens, leading to varied and inconsistent results.

So, what does DMARC do?

A DMARC policy allows a sender to indicate that both SPF and DKIM protect their emails and tells a receiver what to do if neither of those authentication methods passes – such as junk or reject the message. DMARC removes the guesswork from the receiver’s handling of these failed messages, limiting or eliminating the user’s exposure to potentially fraudulent and harmful messages. DMARC also provides a way for the email receiver to report to the sender about messages that pass or fail DMARC evaluation.

In practical terms, with a DMARC policy published in DNS:

  1. The message must pass either SPF or DKIM but does not need to pass both.
  2. This resolves the deficiencies of SPF (forwarding) and DKIM (inadvertent message modification) by allowing compensation via the other mechanism.
  3. Sender policies can specify what to do with messages not passing SPF and DKIM. There are three options: do nothing, quarantine them, or reject them. There is no longer any implementation-specific ambiguity on what filters should do and when.

Setting up DMARC

The domain owner must properly set up the DNS records to use DMARC (as with all anti-fraud solutions for email). If you cannot access the domain settings, you will be unable to update your DNS settings and will not be able to use DMARC.

DMARC is set up by adding special entries to the published DNS settings for the domain. You can use a tool, such as this DMARC Record Assistant, to create the DMARC DNS record for your domain.

We will not spend time on the details of the configuration or setup here. Instead, we will look at the utility of DMARC and its limitations.

The Benefits of DMARC

Once DMARC is set up, it helps reduce fraudulent emails from a domain. Simple forged spam and basic phishing attacks are curtailed more effectively with DMARC than with SPF and DKIM alone. Using DMARC combines them into a more comprehensive check with a consistent, well-defined failure state (e.g., reject or quarantine).

DMARC shines when implemented by domain owners using weak SPF and DKIM records. It allows email servers to accept that one of these validation schemes may fail while still requiring that the other one passes for the message to be considered legitimate. This is excellent progress.

DMARC is recommended for every domain owner and email filtering system. However, you must have control over all of the sources of messages from your domain name.

An interesting side effect is that, in some aspects, DMARC can make a domain more susceptible to determined forged emails!

The Limitations of DMARC

This is counterintuitive. Combining DKIM and SPF into a unified, complementary policy set that allows each to compensate for the other’s weakness is a fantastic idea and does a great job. However, a side effect of this technique in determining fraud is that it requires only one DKIM or SPF record to pass, NOT BOTH. In fact, there is no way to use DMARC to require that both must pass.

How Can Attackers Bypass DMARC?

An attacker only needs to find a way to pass one validation check to bypass DMARC. Note that this is only worse than separate use of SPF and DKIM if your SPF and DKIM rules are both strict (if it doesn’t pass — “drop it”). In most other cases, it’s the same or better than using both technologies separately.

Looking at our previous analyses of SPF and DKIM, an attacker could generate a forged email that passes DMARC if:

  1. They can send from an IP address allowed under the forged sender domain’s SPF policy. This can be done using the same email provider as the sender.
  2. They can send you a message from one of the servers authorized by the DKIM for the domain. If that server does not care who initiated the message but will sign any messages going through it with the proper DKIM keys, then the message will look legitimate. If the attacker signs up with the same email provider used by the forged domain and that provider’s servers do not restrict DKIM key usage, they can send an email from those same servers as the legitimate account and have their messages adequately signed.
  3. The attacker can compromise any sender’s workstations, email servers, or vendor’s email servers.

So, it requires a determined attacker with some knowledge of the sender’s infrastructure and some ingenuity to get past DMARC.

In addition, there is another way they can easily get past DMARC:

  1. If the sender’s domain has DMARC, SPF, and DKIM DNS records, if the recipient’s spam filters do not pay attention to DMARC (or the others), then these settings will be all for naught, and the forged message will still appear legitimate.

A determined attacker will gain knowledge both of the anti-fraud settings of the sender’s domain and of the capabilities of the recipient’s systems. The weaker the filters, the easier the attacker’s job can be.

What Else Can We Do to Prevent Email Forgery and Fraud?

Technologies are getting better and better at preventing email fraud, but none of them are foolproof. SPF and DKIM are implemented inconsistently, and DMARC is not well-supported across email filters. DMARC records are also not published for a majority of domains. Many that publish them have “no nothing” records designed to test the waters and gain telemetry on what messages they sent would fail DMARC.

Beyond using these technologies and being vigilant, some additional techniques can be used to lock down the identities of message senders. In the last article in this series, we shall see what some of these are.

Read next: Stopping Forged Email 4: Your Last Resorts

DMARC: The State of Domain-based Email Authentication – Part 2

Monday, September 11th, 2017

Building a safer email ecosystem with DMARC

In our previous post, we described two techniques for authenticating an email sender:

  • Sender Policy Framework (SPF), IETF RFC 7208, which verifies if the sending MTA is indeed authorized to send mail on behalf of a domain; and
  • DomainKeys Identified Mail (DKIM), IETF RFC 6376, where a domain shows “ownership” of a mail it sends by signing portions of it so that critical aspects cannot be forged by intermediaries.

Like most technologies, these are just individual weapons in the arsenal for fighting phishing and spam. Weapons, like all tools, need to be properly used if they are to be effective. Unfortunately, as we described in the earlier post, both SPF and DKIM are deployed in a manner that reduces their usefulness. With SPF, the validation policy set by the sender is often chosen in a manner that leaves handling authentication failures at the discretion of the recipient. DKIM, on the other hand, does not even have an explicit policy directive set by the sender. Moreover, in a heterogeneous mail environment, some perfectly legitimate MTAs might not be capable of signing messages.

Building a safer email system with DMARC

Thus, receivers in actual deployments tend to “soft fail” any SPF and/or DKIM validation failures as there are reasonable situations when legitimate mail can fail such checks. A common example is forwarded mail (which fails SPF), or mail sent via a mailing list (which fails DKIM). Mail providers consider it better to deliver most mail (even if some are fake or spammy) rather than risk dropping legitimate mail. Thus, neither of these techniques individually or combined provide clear guidance to receivers, and the resulting actions can be inconsistent.

Read the rest of this post »