What is DMARC?
Domain-based Message Authentication, Reporting & Conformance, or DMARC, is an email authentication standard introduced in 2012 to determine how unauthenticated email should be handled. It adds a third layer upon SPF and DKIM to create a holistic email confidence system. So, what does that mean? First, let's back up a bit.
Whenever anyone sends an email from a certain domain, SPF and DKIM records need to be set up on the domain's DNS server—it’s a way for email servers to say “it’s OK that this service (whether that's your office email, Marketo, a web server, etc.) is emailing with an address that has my domain: they’re with me.”
The best way to think of SPF and DKIM is to think of SPF as the “envelope” (the original piece of data being sent over) and DKIM as the signature (the letter inside—is it forged or original?) SPF is a public declaration given by a domain; DKIM requires both a public and private key. The two work in tandem to prove an email is legitimate. DMARC builds upon this system by giving mail servers instructions on what to do when it finds emails that don't have correct SPF and/or DKIM records: should it let them through, quarantine them, or reject them? Additionally, DMARC is set up so the servers you email to will provide you a report on what emails are being sent with your domain—and if there's anyone sending rogue emails with your domain (say, for phishing purposes.)
While this is exciting stuff for IT, why should marketing care? Simply put, more and more email providers are now checking to make sure you have a DMARC policy to determine whether your email is considered spam—even if you have SPF and DKIM records defined! At DemandLab, we have seen examples of AOL, Yahoo and private email firewalls now rejecting emails due to a lack of a DMARC record. Defining a record is a win-win: your marketing messages are considered more trustworthy, and your users have the security of knowing anything coming from your email domain is legitimate.
How do I set up DMARC for my email domain?
You can check if your email domain currently has a DMARC policy by visiting http://mxtoolbox.com/dmarc.aspx. If your company doesn't have any record on file, we recommend a five-step approach to make sure your implementation goes smoothly:
1. Take an inventory of your emailing systems
Your company's technology stack probably has more things sending out email than you'd think—there's more to consider than just your office email and marketing automation! Consider transactional emails, emails sent from internal programs, emails from other SaaS platforms, and more. We recommend working with your IT team to look across your entire technology stack to make sure you have everything covered.
2. Check that all the systems you identified have SPF/DKIM definitions
For many marketers, the process of setting up SPF and DKIM when you first purchase your marketing automation platform is the first (and last!) time they ever think about these records, but it's important to consider how all other outgoing email is defined with SPF and DKIM records.
Make sure you have all IPs and/or record types defined with your SPF setup. It's important to remember that the SPF standard can only handle 10 lookups, so if you have more than 10 different places sending emails with your domain, you may want to consider consolidating your email sources or purchasing a separate domain for certain types of emails.
From there, you need to ensure you have DKIM records set up for each of your mailing platforms—your IT team should be able to help you see which TXT records have different DKIM signatures on them and what you may be lacking. Because some administrators aren't as familiar with DKIM setup, there's a very real possibility not all of your mailing systems are covered. Included below are setup instructions for setting up DKIM on some of the most common email systems:
Salesforce: https://help.salesforce.com/htviewhelpdoc?id=emailadmin_create_dkim_key.htm
Office 365: http://blogs.msdn.com/b/tzink/archive/2015/10/08/manually-hooking-up-dkim-signing-in-office-365.aspx
Google Apps: https://support.google.com/a/answer/174124?hl=en
Linux servers (Postfix): https://www.digitalocean.com/community/tutorials/how-to-install-and-configure-dkim-with-postfix-on-d...
3. Create an email account for receiving DMARC reports
DMARC requires an email address to send its authentication reports to; most commonly this address is either abuse@domain.com or postmaster@domain.com (which I strongly recommend for your own DMARC setup over custom options, since many feedback loop systems prefer these names.) Make sure you have a valid email inbox for these records that go to both IT and marketing. Do note that if you use Google Apps the process is a little different than most email providers.
4. Define what you want your DMARC policy to be
DMARC gives domains a few different options on how to handle emails that don't pass authentication (those interested in learning all potential configurations should check out this helpful overview of all DMARC tags and values.) For simplicity's sake, we'll define three main options: take no action, quarantine, or reject.
A very basic example of a DMARC record where servers are instructed to take no action would be:
v=DMARC1; p=none; rua=mailto:postmaster@domain.com; ruf=mailto:postmaster@domain.com
Generally, we recommend a phased approach where your DMARC policy over time where your policy (defined above as none via p=none) is slowly changed over time to be increasingly more restrictive—changing your record over time to have 10% quarantine, 25% quarantine, 50% quarantine, 75% quarantine and an eventual p=reject policy (where any emails that don't have SPF/DKIM authentication should be discarded altogether.) However, it's usually best to do an analysis of your DMARC reports before implementing stricter measures.
5. Set your DMARC policy (and monitor your reports!)
Once you've determined what your DMARC record should be, have your IT team place it as a TXT record in your domain's DNS manager. After applying this record, you should start to receive daily emails to the email address you chose that look similar to the following:
Attached to each of these emails will be an XML report that details what that particular email provider has experienced. By breaking down the the XML tags included in each of these reports, you can get a better idea
In this particular report from Yahoo, we can see the following:
- The policy for this domain is to take no action (<policy_published> tag with <p> inside set to none)
- 19 emails were sent to Yahoo’s servers on this day (<count> tag)
- Emails sent from an IP passed SPF/DKIM (<record> tag)
- Emails from domain.com passed DKIM (first <domain> tag inside <auth_results>)
- Emails from mail.domain.com passed SPF (second <domain> tag inside <auth_results>)
This is an example of a healthy DMARC setup, but how do you know when something's wrong? By looking at the recent results report of a company that has a 20 percent quarantine policy, we can learn what to watch out for: a record that has failed authentication, yet is still being delivered.
Failed but not quarantined
<row>
<source_ip>178.235.116.88</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
<reason>
<type>sampled_out</type>
<comment></comment>
</reason>
</policy_evaluated>
</row>
Since both <dkim> and <spf> tags say fail, we know that this particular IP did not meet DMARC policy. Additionally, when we look at this record, the <type>sampled_out</type> tag lets us know that even though this record was flagged for not passing DKIM or SPF, this one email was allowed to still be sent since it was not part of the 20 percent quarantine.
If you look up the IP 178.235.116.88, you'll find it's actually a Polish spammer on many blacklists already. Therefore, in this case this spam bot is sending emails out of its system using this company's domain as an email address! Because this and several other similar records showed up for this company, they should probably consider moving to a higher percentage of quarantining more quickly. You'll know when these emails aren't delivering when you see your <policy_evaluated> tag looking like this:
<policy_evaluated>
<disposition>quarantine</disposition>
<dkim>fail</dkim>
<spf>fail</spf>
</policy_evaluated>
With this in mind, be sure to watch your reports over the next few weeks and check that you do not see any <result>fail</result> messages, which would point to a specific domain or IP failing that you want your emails to be sent from—and make sure that you don't see any records of senders you don't want sending messages getting through.
DMARC is not just an IT responsibility, especially when your email deliverability is hanging in the balance. Marketers should be involved throughout the entire DMARC setup and implementation process. Together with the IT team, marketers must do periodic checkups on the reports to ensure that your email continues to deliver as it should, and you can enjoy knowing that your email is safer, more deliverable, and unspoofable.
2 Comments
.png)