The LuxSci FYI Blog

by Erik Kangas, PhD, CEO

Stopping Forged Email 3: DMARC to the Rescue

Published: March 2nd, 2015

We have recently looked at how hackers and spammers can send forged email and then seen how these forged messages can be almost identical to legitimate messages from the purported senders. In fact, we learned that generally all you can trust in an inbound email message is the internet IP address of the server talking to your inbound email server — as this cannot realistically be forged in any way that would still enable you to receive the message.

In our previous two posts in this series, we examined how SPF and DKIM can be used to help limit forged email messages based on validating if a message was sent by an approved server by looking at the IP address delivering the email message to you and based on digitally signing messages. We found that while SPF and DKIM can work, they has many significant limitations that cause them to fall or be insufficient to stop forgeries in many cases.

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

If you are using both technologies and you have a good amount of control over where your domain’s messages are coming from, then you can step up your game by using DMARC — Domain-based Message Authentication, Reporting and Conformance.

DMARC: A Simple Explanation

When using SPF and DKIM, email filters see if messages pass or fail SPF and DKIM and use the DNS-published “strictness” settings to help them determine “what do do next”. The result of failing SPF and/or DKIM is thus a function of how a particular filter is implemented … and leads to varied and inconsistent results.

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 with DMARC for the sake of clarity.)

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

The message mu`st pass either SPF or DKIM but does not need to pass both.

This resolves the deficiencies of SPF (forwarding) and DKIM (inadvertent message modification) by allowing compensation via the other mechanism

Sender policies can specify exactly what to do with messages that do not pass SPF and DKIM: do nothing, quarantine them, or reject them. There is no longer any implementation-specific ambiguity on what filters should do, when.

Setting up DMARC

With DMARC (as with all anti-fraud solutions for email), it is up to the owner of a domain (e.g. the owner of bankofamerica.com) to setup the DNS settings required for DMARC to be used by the recipients. If they do not do this, then 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 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 actual 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 really does help reduce generic fraudulent email from a domain. E.g. simple forged spam and basic phishing attacks are curtailed more effectively than via use of SPF and DKIM alone, though the DKIM “glue” that 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 that would normally put up weak SPF and DKIM records (e.g. ones that say that SOF and DKIM “don’t have to pass”). DMARC allows them to allow 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 great progress.

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

An interesting side effect, however, is that DMARC use can make a domain more susceptible for 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 an amazing idea and does a great job in general. However, a side effect of this technique, in terms of its susceptibility to determined fraud, is that it requires on only ONE of DKIM or SPF pass .. NOT BOTH. In fact, there is no way to use DMARC to require that BOTH must pass.

Wait … what is the problem?

Since DMARC is happy if either SPF or DKIM passes, then an attacker needs to find a way to generate an email that passes only one, and not both validation checks. 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 its the same or better than using both technologies separately.

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

They can send from a server IP that is 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.

They can send you a message from one of the servers authorized by the DKIM for the domain and 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. E.g. If the attacker signs up with the same email provider as that used by the forged domain and that provider’s servers do not restrict DKIM key usage, then s/he can send an email from those same servers are the legitimate account and have his/her messages properly signed.

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.

Oh wait — there is another way they can easily get past DMARC:

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 nought” … and the forged message will still appear legitimate.

So — 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?

Various standard technologies take better and better stabs at email fraud protection, but none of them are fool proof: SPF and DKIM are implemented inconsistently, and DMARC is not well supported across email filters at this point. DMARC records are also not published for a majority of domains. And many that do publish them, e.g. Bank of America at the time of this writing, have “no nothing” records that are designed to just test the waters and gain telemetry on what messages sent by them are would fail DMARC.

Beyond using these technologies, to the extent that they are available to you, and being vigilant … which is what most people do … there are some final techniques that can be used to further the lock down identities of message senders.

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