Written by Giles Bennett
A new tool in ensuring that emails from you reach their recipients' inboxes, and that no-one else can pretend to be sending emails from your domain, has arrived in the form of DMARC records.
This post requires a little bit of knowledge of DKIM and SPF records, as DMARC records build on those - if you don't know what they are, then you can read more about DKIM records here, and more about SPF records in our post here.
Deliverability of emails is a key issue for online stores - you can send out all the order confirmation emails and tracking information emails that you want, but if they're not making it to the customer's inbox, then you're going to have to do more work fending off enquiries by phone and email asking if the order definitely went through okay, when it's going to be arriving, where it is, and so on. Making sure that the customer gets the information is a top priority. Using services like Mandrill can help considerably, but comes with on-going cost implications. Using SPF records and DKIM records can help, and they have low to very low set up costs. Building on that, DMARC records have now been introduced to help even further.
DMARC stands for 'Domain-based Message Authentication, Reporting and Conformance' - thankfully someone came up with the acronym. It seeks to correct a problem inherent in DKIM and SPF, which is that you have no way of knowing if they are working or not - that, in turn, means that emails are more secure, and the chances of emailing phishing attacks, spoofing or other nefarious activities are reduced.
DMARC makes it simpler for those who are sending and receiving emails to figure out (a) if an email is actually coming from the person it says it's coming from, and (b) what to do with the email if it's not. It builds on SPF records and DKIM records, so requires that they've already been implemented.
SPF records identify the relevant domains and IP addresses which are authorised to send emails on behalf of a particular domain - so, for HummingbirdUK, if an email doesn't come from our main site's IP address, from whatever IP addresses Google Apps are using, and whatever IP addresses Mailchimp are using, then the chances are that it's not actually from us, and should be treated accordingly.
DKIM records go one step further - outgoing emails from our servers, from Google Apps and from Mailchimp (when sent on our behalf) are digitally signed with an electronic signature. That signature can be decoded and compared to a public key which is accessible to all and sundry. If the signature matches then it's likely to be a genuine email from us, if not, then it's not, and the DKIM record will go on to specify what should happen to such an email (mark it as spam, reject it, deliver it anyway, and so on).
The problem is that as the sender, we have no way of knowing if emails are being treated as they should, because the various systems work independently of each other, and there's no feedback. DMARC aims to counteract that - a DMARC record, which is a TXT DNS record requires that SPF and DKIM are set up on the domain already, then specifies a number of options. Our DMARC record looks like this :
"v=DMARC1;p=none;pct=100;rua=mailto:postreports@hummingbirduk.com"Breaking that down, the first part indicates the 'version' number of the DMARC protocol. The second indicates the 'policy' for the domain, which is what to do with the email if it fails - in our case we have no policy specified, as we're using it only for reporting purposes, but other options include 'quarantine' (set it aside to be dealt with how the incoming mail server's systems specify) or 'reject' (self-explanatory, really). The third, 'pct', indicates the percentage of messages that should be subject to checking against the DMARC records - we've set it to 100%. The fourth, 'rua', specifies an email address to which reports are sent so that we can see how it's all going.
The report is the really useful side of it - it's emailed as a zip file, which contains an XML file, which aggregates all incoming emails to a domain over a specified period of time and tells you information about each one along these lines :
<record>
<row>
<source_ip>2a00:1450:4010:c04::231</source_ip>
<count>1</count>
<policy_evaluated>
<disposition>none</disposition>
<dkim>pass</dkim>
<spf>pass</spf>
</policy_evaluated>
</row>
<identifiers>
<header_from>hummingbirduk.com</header_from>
</identifiers>
<auth_results>
<dkim>
<domain>hummingbirduk.com</domain>
<result>pass</result>
</dkim>
<spf>
<domain>hummingbirduk.com</domain>
<result>pass</result>
</spf>
</auth_results>
</record>The information includes the originating IP address of the email, as well as the results of checks against our DKIM and SPF records. Since our policy is set to 'none', nothing adverse would have happened if these results had failed, but this is where DMARC's benefit come in to play. As we review these incoming reports (either manually or automatically) we can check that all our DKIM and SPF records are working correctly, and then change our DMARC record to tell recipients to mark as suspicious, or bin, any emails which fail them. It provides a coherent approach.
So, for the sake of a little bit of work, you can greatly increase the chances not only that your email makes it to the recipient okay, but also that no-one else's emails get passed off as your own. If you'd like any pointers on how to go about implementing SPF, DKIM or DMARC records, then feel free to get in touch.
