It was our most requested feature and simultaneously really simple and really complicated, but it's finally here. DMARC reporting allows you to detect and prevent fraudulent emails being sent that claim to be from your domain when they aren't. DMARC reports are another valuable source of information that you can now easily collect using Report URI.
Domain-based Message Authentication, Reporting and Conformance
Woah, that's a bit of a mouthful! To explain what DMARC is and does we first need a little bit of background into the problem it helps us solve. When you receive an email it tells you who the email came from, or more specifically it tells you the email address it came from. We really need to be able to check that emails actually came from where they claim to have come from if we're going to be able to trust anything in them and for that, we have a couple of mechanisms at our disposal.
SPF
Sender Policy Framework is a simple DNS TXT record that you can create for your domain. In the value of the SPF record you provide details of where you will send emails from, typically by providing the IP address/es of your mail servers. This way, if someone receives an email that claims to be from report-uri.com, you can look at our SPF record and see if the IP address of the server sending the email is one we've listed as allowed to send emails for us.
;QUESTION
report-uri.com. IN TXT
;ANSWER
report-uri.com. 299 IN TXT "v=spf1 include:spf.messagingengine.com include:sendgrid.net ~all"I have a blog in my email security series on SPF so if you'd like to go into more details you should check that out and set it up first.
DKIM
Domain Keys Identified Mail is another DNS based record but with a slightly different purpose to SPF. With DKIM you can add a signature into the headers of outbound emails which the receiving party can then verify. They fetch the public key from your DNS record to validate the signature and this gives us another assurance that the email isn't a fake. You can see one of our DKIM records here:
;QUESTION
fm1._domainkey.report-uri.com. IN TXT
;ANSWER
fm1._domainkey.report-uri.com. 298 IN CNAME fm1.report-uri.com.dkim.fmhosted.com.
fm1.report-uri.com.dkim.fmhosted.com. 3598 IN TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA3AmtGiaApX/8hPt/uJCUf0nSsk94aOxjs+nphrh2L8KUQf8wxV3cd0DLnt0uHeoQRL0cFNchi8nQqoghU4O/YeCapKwWOmgodxLw/hnNtmtbK0Ii0o4/FgIgTaWeVEMBOKISIqWWz3NIPMhG8Xx3wvAxttIWocc0wiqG2Hmz5A42NoOVeBGhq+GL3UWgBe8W7" "WKo5iAcEouGYnXKnxZDx1ylXDWqc2Iz0735Ezn7CyuvEdk9CcC8NLvc2XBwCjkCpYpDSM4FPtWMGdv2dxys1wdXN6rpa7bzmH9x0o/EKFmu3MhoxThAndzuvgmcANJLF8u3Nd4QQh6DOj75hPB3WwIDAQAB"
;AUTHORITYAgain I have a blog on DKIM if you'd like more information and it'd be a good idea to set that up before looking at DMARC too.
What happens with SPF and DKIM?
This is where DMARC comes in. What happens if an email comes from an IP address not whitelisted in your SPF policy? What if the signature in the headers doesn't validate with DKIM? With DMARC you get to specify exactly what happens in these scenarios and enable reporting to see what is happening and how often. My blog post on DMARC will explain all of the different settings and configurations available but this post will focus on the reporting capabilities and how they can help us. Just to demonstrate how powerful this can be though, here's what happens when I send some spoofed emails claiming to be from Report URI when they're not.
These emails were sent from a temporary server that I created and as a result the IP address of the server was not whitelisted in my SPF policy and it also can't sign emails with DKIM either. My DMARC policy requests that emails that fail either SPF or DKIM be marked as spam and not delivered to the inbox of the recipient, which is what happened here as you can see. That's great, it means someone trying to impersonate report-uri.com is already going to have their emails flagged, but we'll demonstrate what else DMARC can do.
DMARC Reports
Enabling DMARC reports is really simple, but you do need to have an SPF and/or DKIM policy in place to actually enforce against. This is what you'd need to add to your DMARC policy to enable reports to be sent to Report URI:
rua=mailto:[email protected]That's it! You need to change the alias in the email address to your own address shown on the Setup page, but that's all there is to enabling DMARC reports. Most mail providers that send DMARC reports tend to send them daily so each day all of the big providers will dispatch a report to that address with information on all activity relating to emails that were sent from your domain. Most of the time the reports should all be good, hopefully you have your SPF/DKIM configurations right and no one is trying to impersonate you via email.
These are the reports for report-uri.com and at a glance there's a lot of information. Each row represents a report from the organisation listed about what happened to your emails that they received. Google are really good at sending DMARC reports and provide reliable information about your activity. The Status column on the left gives you a good idea of what's going on and a green tick indicates that SPF and DKIM passed, a yellow question mark indicates either SPF or DKIM failed and a red cross means that both SPF and DKIM failed. You can also filter on any of those possibilities in the Status drop down field.
The rest of the fields within the UI are self explanatory and you can filter on all of the ones that you need to. Using the example of the spoofed emails earlier, I can go back to the day in question and search for reports on that day, quickly spotting the one about the spoofed emails.
The last thing to point out here is the Raw view for the report and just like other reports we collect, we also provide the raw data for DMARC reports too.
You may notice that DMARC reports are XML and not JSON like other browser based reports and you'd be right. They are also delivered via email as we've seen and not HTTP POST requests like other reports. Both of these factors introduced many new problems for us to deal with in processing these reports, and I will touch on some of them later in the post. For now, though, the last thing to show is of course the Graphs page, keeping in line with other reports.
Report Enrichment
We're pretty new to DMARC but we wanted to kick things off with a little extra and show that just like our other reports, we're not going to be a simple endpoint that aggregates reports for you. Our CSP filtering and tailored UI takes the JSON and does more with it, just like we're going to with the DMARC XML. The first such feature is enriching the XML with some extra metadata. When reports come in they contain the IP address of the server that sent the email. That's a really useful piece of information to have, but at a glance it's really not that helpful. What we've done is scrape the SPF records of the largest email providers out there and if we get a match against one of them we put the company name alongside the IP address for you. What that means is that your XML goes from this:
<source_ip>50.31.63.171</source_ip>To this:
<source_ip>50.31.63.171 (SendGrid)</source_ip>This makes the report far more valuable and tells you something useful right away. If there's no company name there then the email wasn't sent from a large email provider and if there is a name there, you know which one it was. Say your organisation starts sending some new kinds of emails from Sendgrid but you forget to update your SPF or DKIM records. You're going to get hit with a load of DMARC failures and when you start looking at those reports instead of seeing loads of IP addresses, you will see Sendgrid's name popping up all over. That's going to guide you towards the problem, and thus the solution, much faster.
It's a great start for report enrichment and as we're opening up DMARC reporting to all users we'd love to get feedback on other things we can do to make the data better for you. Let me know in the comments below, drop me a tweet or send me an email. I'm going to be covering some of the technical aspects of DMARC reporting in another post for those that may be interested, but let me tell you, the switch from HTTP+JSON to SMTP+XML for reports was not as easy as I'd have hoped! Keep an eye out for that post in the coming days.