DMARC now what? Part 1

Recently EmailKarma.net email addresses started to see a lot of bounced email for messages that we didn’t send, this is common from viruses and bots that forge the sender and have bounces generated to an unsuspecting third party. Being that we are already SPF and DKIM compliant I decided to publish our DMARC records to see how bad the spoofing problem really is. As a result of this I’ve also decided to share this experience here in hopes that it will inspire you to review your existing email authentication strategies and take the plunge with DMARC.

Lets start at the beginning shall we…

What is DMARC?
Lets go straight to the source for this answer:

“DMARC, which stands for “Domain-based Message Authentication, Reporting & Conformance”, is a technical specification created by a group of organizations that want to help reduce the potential for email-based abuse by solving a couple of long-standing operational, deployment, and reporting issues related to email authentication protocols.

DMARC standardizes how email receivers perform email authentication using the well-known SPF and DKIM mechanisms. This means that senders will experience consistent authentication results for their messages at AOL, Gmail, Hotmail, Yahoo! and any other email receiver implementing DMARC. We hope this will encourage senders to more broadly authenticate their outbound email which can make email a more reliable way to communicate.” ~ DMARC.org

Confused yet? In short DMARC is a new tool that organizations sending email can deploy to track the source of email that is being sent without their approval and apply policies for the recipients network on how they should treat mail that fails their authentication test.

Why do we need another Authentication Tool?

Unlike the other forms of Authentication that have been deployed previously, DMARC allows the sender to set clear policies AND receive feedback from the ISPs actually receiving email classified under these policies.

What do I need to do?

Setting up your DMARC records is actually quite simple, that is if you already have SPF and DKIM running. If not go do this first as it might take a while to get them right and they are required for DMARC.

An example record for basic reporting, like the one I’ve published, which generates only the daily reports for domains looks like this in your DNS:

_dmarc.YOURDOMAIN.com IN TXT “v=DMARC1\; p=none\; rua=mailto:postmaster@YOURDOMAIN.com”

This will have ISPs supporting DMARC email your postmaster with reports of the email messages that they receive claiming to be from your domain, and any action that they have taken based on your policy – this policy is just a report (a great place to start). I have created a custom email address to receive these reports, and many organizations may want these to be sent to their security teams (or a third party security vendor) for review or actioning – the important peace is to have someone available to review the incoming data and consider the actions you want to take on these messages.

Where can I get more info?

Google has a great set of examples and policy notes you can review here Understanding DMARC and Creating a DMARC record to help you build the policy that works best for your organization. Of course DMARC.org is the central location for up-to-date information on DMARC and lists several great tools available to creating, testing and reviewing DMARC related reports.

Next time I’ll talk about the reports and what you can learn from them.