DMARC: a new tool to detect genuine emails

As LinkedIn grows, our name and reputation are used in phishing attacks with increasing frequency. Members and non-members alike have trouble distinguishing a genuine LinkedIn email from one of the many scam email trying to direct users to illicit websites.

LinkedIn is not the only company to face these challenges, so we teamed up with a number of other organizations - including email providers (AOL, Comcast, Gmail, Hotmail, Netease, Yahoo! Mail), service providers (Bank of America, Fidelity Investments, JP Morgan Chase, Paypal), social media sites (American Greetings, Facebook), and email security solutions providers (Agari, Cloudmark, Return Path and Trusted Domain Project) - to create and implement DMARC:

Domain-based Message Authentication, Reporting & Conformance

We are participating in the DMARC working group to define an open and public specification for all to adopt and use. The specification will be submitted to the Internet Engineering Task Force (IETF), a standard-setting body for technologies used on the Internet. We are promoting a couple of useful open source tools to help encourage the adoption of DMARC:

dmarc-msys: a set of Lua scripts that implement DMARC checking and reporting.
openDMARC milter: a mail filter which works with popular mail servers like sendmail and postfix.

Read on to learn how DMARC works and how it can help prevent email-based abuse.

Previous solutions

Fighting spam and phishing emails is tricky, since the site under attack generally does not receive the emails directly. In the past, we had to rely on our members to report them, and even then, it was difficult to stop the spammers, as they could be located anywhere in the world.

An effective way to fight phishing to date has been to report the links found in the emails to various blocking lists, such as Google safe browsing or SURBL. While effective, this approach is not ideal: an attack must already be under way to be detected. In addition, using a reactive strategy means there is no way to determine the size of a phishing campaign or prevent malicious emails from reaching the mailbox in the first place.

To be more proactive about fighting spammers, we looked into solutions that can tell the receiver when an email is genuine or not. We evaluated a number of authentication mechanisms, including DKIM, SPF, and ADSP. Each mechanism had some weaknesses, such as poor handling of forwards, not properly projecting a policy to the receiver, or not giving the sender feedback on what emails got rejected. Private agreements alleviated some of the problems, but they were not scalable and they could not protect all of our users.

What DMARC brings to the table

DMARC builds upon Domain Keys Identified Mail (DKIM) and the Sender Policy Framework (SPF). The protection starts by signing all our emails with DKIM and keeping our SPF records up to date. Experience has shown that SPF does not work well when an email is forwarded, and DKIM – while surviving forwarding better than SPF – is not 100% reliable, due to the complex signature algorithm. By utilizing both, the strengths of each minimize their weaknesses.

After signing the messages, DMARC adds the concept of identifier alignment. The most visible identifier for the end user is the email address in the From: header of the email. This header is required as per the RFC5322 section 3.6 email standard. A DMARC filter can check that the domain in the From: header aligns with the identifier of a valid SPF check (the envelope’s mail-from domain) and the identifier of a valid DKIM signature (the value of d=).

If any of these identifiers are "aligned" with the domain in the From: header, then the email is deemed to have passed the DMARC test. By "aligned", we mean that all the identifiers are either identical or a subdomain of the organization domain found in the From: email header (note: this is an over-simplification).

Image courtesy of DMARC.org

How do you use DMARC?

To enable DMARC, a domain publishes a DMARC record in the DNS. The email receiver will check if the domain in the From: header or the organization domain correspond to a published DMARC record in DNS. If so, the receiver will perform the DMARC test.

For example, imagine we want to protect an email with the following header:

From: joe@mail.example.com

We can publish the following record in the DNS:

_dmarc.example.com IN TXT “v=DMARC1; p=none”

Here, the organizational domain of mail.example.com is example.com. This is the simplest DMARC record you can use. We call it monitor mode. All it does is tell the receiver to perform the DMARC test and log it.

Here's a more useful version:

_dmarc.example.com IN TXT “v=DMARC1; p=none; rua=mailto:dmarc-rua@example.com”

This time, we are telling the DMARC-compliant email receivers to send a daily aggregate report of all the DMARC tests for this domain. Mail delivery is unaffected: all emails are delivered as if the DMARC record didn't exist.

Aggregate reports

Here's an example report from the DMARC FAQ:

<?xml version="1.0" encoding="UTF-8" ?>
<feedback>
  <report_metadata>
    <org_name>acme.com</org_name>
    <email>noreply-dmarc-support@acme.com</email>
    <extra_contact_info>http://acme.com/dmarc/support</extra_contact_info>
    <report_id>9391651994964116463</report_id>
    <date_range>
      <begin>1335571200</begin>
      <end>1335657599</end>
    </date_range>
  </report_metadata>
  <policy_published>
    <domain>example.com</domain>
    <adkim>r</adkim>
    <aspf>r</aspf>
    <p>none</p>
    <sp>none</sp>
    <pct>100</pct>
  </policy_published>
  <record>
    <row>
      <source_ip>72.150.241.94</source_ip>
      <count>2</count>
      <policy_evaluated>
        <disposition>none</disposition>
        <dkim>fail</dkim>
        <spf>pass</spf>
      </policy_evaluated>
    </row>
    <identifiers>
      <header_from>example.com</header_from>
    </identifiers>
    <auth_results>
      <dkim>
        <domain>example.com</domain>
        <result>fail</result>
        <human_result></human_result>
      </dkim>
      <dkim>
        <domain>example.net</domain>
        <result>pass</result>
        <human_result></human_result>
      </dkim>
      <spf>
        <domain>example.com</domain>
        <result>pass</result>
      </spf>
    </auth_results>
  </record>
</feedback>

The aggregate reports indicate how many emails were received, what IPs they came from, and how many passed or failed the DMARC test and for what reason. This gives us a good idea of which emails were sent by the mail servers of example.com and which ones were not. Moreover, for the ones sent by the mail servers of example.com, we can see the messages that would have been rejected and for what reason.

This is a good way to test your email infrastructure and track down possible errors, such as forgotting to add a mail server in the SPF record, or to DKIM sign some emails. For instance, the most common error is to not DKIM sign Non-Delivery Reports (bounces).

Identifying spammers

Using an aggregate report, you can identify phishing problems and fraudulent use of your emails: look for emails not coming from your IPs (SPF not aligned) and with no aligned DKIM. You may also find useful data in a forensic report, though not all receivers will send these. Forensic reports usually contain redacted versions of the actual emails that were rejected.

Using this data, you can proactively estimate the volume of a specific phishing campaign, the machines involved, and which links should be reported first. In our case, DMARC does not solve all the phishing problems, but it forces the phisher to use a non linkedin.com domain in the From: header. This makes it much easier for email operators, anti-spam vendors, and end users to spot fake messages. It is an arms race, but by providing tools that simplify the detection of such emails, we can ensure you receive the quality and security you expect from your contacts.

Useful tools

The first implementation of DMARC as a filter for incoming emails was on Gmail. Now, Yahoo, AOL, XSN4LL, Netease (the biggest ISP in China), Facebook, and LinkedIn all filter incoming emails using DMARC and send aggregate reports. This protects millions of mailboxes, but there are still many more mailboxes to protect, especially in corporations.

To encourage the adoption of DMARC, we are promoting a couple of useful open source tools:

• dmarc-msys: a set of Lua scripts that implement DMARC checking and reporting.
• openDMARC milter: a mail filter which works with popular mail servers like sendmail and postfix.

Moving to reject mode

Once you've got your monitoring set up and are receiving aggregate reports, you're in a position to take action. Check out the next post to learn how to move from monitor to reject mode using DMARC.