Using DMARC to Fight Email Spam

Posted by Rich Tener on 14 Aug 2014

Posted by Rich Tener on 14 Aug 2014

Since January of this year, we’ve observed spammers launching campaigns using our name. Early versions included links to pharmaceutical sites, but later versions included malicious attachments.

The spammers started by addressing these emails from legitimate, non-Evernote email addresses, but were using a visible name that said “Evernote Service” like the email below:

Screen Shot 2014-08-14 at 3.13.07 PM

It didn’t take long for the spammers to change their methods and start impersonating legitimate addresses in the “From” field. If you were on the spammer’s list of email targets, you started receiving emails that looked like they came from one of our email addresses. We didn’t send them, but there was no obvious way for you to know.

We want you to be confident that emails from Evernote really come from us. We have made positive steps toward ensuring this by publishing an enforcing DMARC policy. Any email sent using a sender address must be cryptographically signed using DKIM and originate from an IP address we publish in our SPF record.

Not all email providers support DMARC, but many large mail service providers do. When they receive an email that tries to impersonate us, they will block it before it hits your inbox.

What is DMARC (and DKIM and SPF)?

DMARC is an email delivery policy that domain owners can publish to instruct mail servers how to handle email security violations for their domain. The action can be “none, quarantine, or reject” and you can set a sampling percentage so that you can ramp up your policy gradually.

To pass a DMARC policy check, the email must first contain a valid DKIM signature. DKIM uses public key cryptography to sign the email message, which allows the receiving server to verify it. The sending mail server signs using a private key and adds that signature as a header. The receiving mail server retrieves the public key from a DNS record and verifies the signature. Next, the receiving mail server verifies that email originates from an IP address listed in that domain’s Sender Policy Framework (SPF) DNS record. If either of these fail, the DMARC check will fail and the receiving server will take the action you specified in your DMARC policy.

The road to a reject policy

We rely on a lot of service providers for business functions like customer service tickets, recruiting, marketing, discussion forums, and corporate email. Tracking all of these down and getting them compliant with DMARC took a significant amount of effort. In some cases, we were unable to get them compliant and had to change our approach and turn off impersonation or route email through a secondary service provider that would DKIM sign on our behalf.

This isn’t meant to be a detailed HOWTO, but the main steps you should follow are:

  1.  Setup your DMARC reports email accounts (rua and ruf)
  2.  Publish a DMARC record with a policy of “none”
  3.  Test each of your service providers for DKIM signing
  4.  Verify each of your service providers is listed in SPF record
  5.  Review the RUA reports to identify service providers you may have missed
  6.  Update your DMARC policy to “quarantine” with a low percentage
  7.  Slowly increase your percentage to 100%
  8.  Change your DMARC policy to “reject”

The result for us is a DMARC record that looks like the following:

$ dig txt +short
“v=DMARC1\; p=reject\; pct=100\;\;\; fo=0:s”

Forwarding breaks deliverability

As a part of this process, we learned that forwarding can break DKIM and SPF and not all mail service providers are doing so in a way that supports DMARC. Let’s start with DMARC and canonicalization.

We were originally signing our service emails with a DKIM canonicalization of “simple/simple”. It turns out that “simple” doesn’t mean flexible and some email services would add blank space or line breaks that would cause the signature check to fail. A mail service provider clued us into this and we switched the canonicalization to “relaxed/relaxed”. That resolved many of the failures we were seeing due to failed message body hashing.

Forwarding also breaks SPF. Let’s take the example of you registering your Evernote account with a university email account (.edu). You want to continue delivering email there, but forward to a different account. If your email provider adheres strictly to RFC 5321, they won’t rewrite the “MAIL FROM” address. Instead it preserves the return-path header as it forwards it along. The destination mail server sees the return-path is an address, but sees the IP address of the .edu, which isn’t in our SPF record. The destination mail server rejects the message.

To address this issue, a number of email service providers have adopted Sender Rewrite Scheme (SRS). They rewrite the return-path to their own domain, validating the SPF check, and resulting in better email deliverability. A significant number of services don’t support this and forwarded emails from our service get rejected. If you are an email service provider and do not support SRS, you should strongly consider implementing it.

View more stories in 'Security'

Comments are closed.