Preventing SPAM with SPF, DKIM, and DMARC

by. Robbie Wright

Perfecting email deliverability can sometimes be a black box, a witch’s cauldron, or a unicorn, depending on who you ask. Over the past few years however, a number of new techniques have been deployed to help combat SPAM in a meaningful way. We get lots of questions from clients with issues around deliverability, so we wanted to throw out a quick, allbeit technical, primer for how you can increase your email deliverability.

One option that many people are familiar with is an SPF record. An SPF tells the world where email can come from. For ongoingoperations.com, our SPF record for example (v=spf1 a mx include:servers.mcsv.net ~all) tells the world that we’re using version 1 of SPF and that any of our A records (think website), our MX records (mail servers), and email coming from servers.mcsv.net (MailChimp) can all send email on behalf of OGO. And by “on behalf of”, I mean any email received from any of those IP’s can send an email in ongoingoperations.com domain.

DKIM is a public key encryption methodology that works in conjunction with SPF. Since an SPF record is public, a would-be spammer could find the IP’s you authorize to send mail and simply spoof their mail to come from those IP’s. DKIM helps to prevent that by saying in addition to looking at the SPF record, the originator of the mail also needs this valid encryption key. Many hosted email providers, such as Office365 and Rackspace, do not offer DKIM functionality in their platforms. Intermedia offers it with an additional fee, Office365 is supposed to have it later in 2014, and Rackspace has no plans to implement it yet, but SendGrid, one of their recent purchases, does support DKIM. Currently, OGO and Gmail both support DKIM for free.

A DMARC record explicitly tells the world what it should do with email from ongoingoperations.com in the event that it doesn’t match SPF or DKIM. Normally, a mail system receiving mail will make a decision on its own, based on a number of factors. The DMARC record says, “Hey, my mail only comes from these systems. I want you to do X with it.” In a DMARC record, you can tell the world you want it to do nothing if the records don’t match, you want it to quarantine the email, or you want it to reject the email. You can also specify what % of mail the action should be applied on. IE, quarantine 25% of mail that doesn’t match or reject 100% of it that doesn’t match, which is what AOL has done.

continue reading »