Stopping Forged Email 3: DMARC to the Rescue

March 2nd, 2015

DMARCIn 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 by an approved server based on digitally signed messages. We found that while SPF and DKIM can work, they have significant limitations that cause them to be insufficient to stop forgeries in many cases.

However, SPF and DKIM address the forgery problem in different but often complementary ways. For this reason, many organizations use both technologies.

Suppose you are using both technologies and can control where your domain’s messages are coming from. In that case, you can step up your game using DMARC, Domain-based Message Authentication, Reporting, and Conformance.

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 and leads to varied and inconsistent results.

So, what does DMARC do? To quote

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

(Note that in the following discussion, we omit some of the finer, nuanced options and configuration possibilities available for clarity.)

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 exactly what to do with messages that do not pass 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 Domain-based Message Authentication, Reporting, and Conformance

To use DMARC (as with all anti-fraud solutions for email), the domain owner must properly set up the DNS records. If they do not do this, there is no way 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 are not going to spend time on the details of the configuration or setup here. Instead, we will look at the utility of DMARC and where its use can actually make it easier for attackers to forge email.

DMARC – The Good Parts

Once DMARC has been set up, it helps reduce fraudulent emails from a domain. E.g., simple forged spam and basic phishing attacks are curtailed more effectively than by using SPF and DKIM alone. The DKIM “glue” combines them into a more comprehensive check with a consistent, well-defined failure state (e.g., reject or quarantine).

DMARC shines when used by domain owners using weak SPF and DKIM records. DMARC 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 for every email filtering system. However, you have control over all of the sources of messages “from your domain name.”

An interesting side effect, however, is that DMARC can make a domain more susceptible to determined forged email!

DMARC – Its Limitations

This is a surprise if you think about it. 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 terms of 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 a server IP allowed under the forged sender domain’s SPF policy. This can be done by using the same email provider (or approved vendor) 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, then 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 of the 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. Even 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 domain and of the capabilities of the recipient’s systems. The weaker the filters, the easier the attacker’s job can be.

Ok – So What Else Can We Do?

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. And many that publish them have “no nothing” records designed to test the waters and gain telemetry on what messages sent by them would fail DMARC.

Beyond using these technologies and being vigilant, some additional techniques can be used to lockdown the identities of message senders.

In our next, and last, article in this series, we shall see what some of these are.

Read next: Stopping Forged Email 4: Your Last Resorts