You got a DMARC record set up for your domain - so now what? Why did you need DMARC anyway? What are those DMARC reports for, and what do you do with them once you get them?
What is DMARC for again?
DMARC is a mechanism to allow you, as a mail sender, to let mail-receiving entities (like Google or Yahoo Mail) know what you'd like them to do with emails from your domain that don't pass validation checks. It also lets you define how you'd like to receive reports on email handling.
In conjunction with SPF and DKIM, DMARC helps to prevent email forgery. SPF and DKIM together let an email receiver know whether an email is from a legitimate sending source and whether it's been tampered with, but without DMARC, there's no way for the email sender to know how effective SPF and DKIM are.
DMARC reports let you know what is happening to sketchy emails that fail SPF/DKIM authentication, and helps you confirm that emails from your legitimate senders are getting through.
Wait, so you actually have to go read these reports? Doesn't it just send an alert if there's something nefarious?
Not exactly. There are some DMARC reporting services that will send you alerts for failed emails or changes in your records. But the reporting service doesn't have any way to know for sure whether those issues are nefarious.
It's like getting failed login or file change notifications for your website. They COULD be indicators of malicious activity, or they could be legitimate. It's up to you to determine what's going on and what action you need to take.
Types of DMARC reports
There are two types of DMARC reports: aggregate reports and failure reports (sometimes called forensic reports). Aggregate reports are the reports you are most likely to see, as most mailbox providers no longer support failure reports due to privacy concerns.
Aggregate reports contain information such as:
- The number of messages sent on a particular date
- The domain used to send the messages
- The sending IP address and source
- Message authentication data
- The DMARC result and disposition of the message
This information is sent to the email identified in the "rua" tag of your DMARC record. The default interval for reports to be sent is 24 hours, but you can specify a different interval in your DMARC record with the "ri" tag.
As mentioned, these reports are sent in XML format, which can be hard for humans to decipher. Ideally, you'll want these reports sent to an analyzing service, so you can get the information in a more easily digestible format.
You can also ask for failure reports to be sent to the email address specified in your "ruf" tag. Failure reports are basically a text copy of the email, including the email headers, and are generated at the time the email fails SPF or DKIM verification.
Most email providers no longer send failure reports, due to concerns with privacy, since failure reports may include the text of an email which could contain PII. Also, if you had a large number of failure reports, your inbox could quickly be overwhelmed, as these reports are sent for each failure, not aggregated.
Since you're mostly likely to be dealing with DMARC aggregate reports, we'll focus on those.
Do I really have to set up reporting in my DMARC record?
While it's possible to set a DMARC policy WITHOUT reporting, it's not a good idea, especially if you set your DMARC policy to quarantine or reject. Without reporting, you'll have no way of knowing if legitimate emails are being blocked.
I've seen some recommendations to "check the box" for the Google and Yahoo email authentication requirements by creating a DMARC record of: v=dmarc1; p=none;
While this may technically meet the requirement to have a DMARC policy for now, it does nothing to help protect your domain against forgery, and I suspect Google and Yahoo will change to require at least p=quarantine in the future.
How do I read a DMARC report?
If you set up DMARC reporting using your own email address, you may have received emails with XML files, that look something like this:
While you could try combing through all that, you have better things to do. If you already have some XML reports and want to try to decipher them, there are some online services where you can upload an XML report, and the service will analyze it for you.
With MX Toolbox, you'll get a basic table of information. It shows you the sending IP address, the number of emails sent (37), the number that passed SPF and DKIM authentication checks, and the number that passed DMARC. In this instance, all the emails sent for this period of time passed.
EasyDMARC gives you a prettier report with a little more information. This is the same XML report uploaded into EasyDMARC's XML analyzer. Here you can see the source as well as the associated IP, and a visual depiction of the status of SPF, DKIM, and DMARC, along with the disposition of the email (since it passed DMARC, it was delivered).
DMARC Report Analyzer Service
Rather than sifting through XML reports or uploading them one by one, I recommend signing up for a service to monitor and analyze your DMARC reports.
While you can have DMARC reports sent directly to an email address, the XML format those aggregate reports are sent in is really meant to be read by a computer, not a human! A DMARC service will also collate the reports sent from the different email receivers, so you don't have to collect them all yourself.
If you don't send a lot of email, and you don't need alerts or other features, there are some services which will give you the basics for free.
Cloudflare has recently created a DMARC Management service, and Postmark has a service which will send a weekly report for one domain. Valimail also offers a DMARC monitoring service; it was originally meant for Office 365 customers, but now has a free basic service for all.
Here's an example of the report you get from Cloudflare's service. Like MX Toolbox's analyzer, it provides the basic information in tabular format.
If you need particular features, or you send a lot of email, you'll want to invest in a paid service, such as EasyDMARC, DMARC Report, MailHardener, Uriports - there are lots of options. Choose one with the features you need and an interface you like.
Most of the paid services base their pricing on the number of domains you manage as well as the number of emails sent, so make sure you choose one that meets your needs (you may be surprised how many emails are sent when you add up ALL your email sources).
Many of these services have a free tier for personal use or for a single domain with limited emails, and most offer a free trial as well.
Below is an example of a dashboard report from DMARC Report, followed by a drilldown into the listings.
Okay, but what am I supposed to do with these DMARC reports?
Remember the reason for DMARC. No, not just because Google and Yahoo are requiring it; it's a standard to help protect your domain from email spoofing. DMARC reports give you information to help you identify whether your email authentication setup is working correctly.
Essentially, what you want to do with a DMARC report is:
- Check the "senders" to make sure the ones you recognize and know should be sending email are passing DMARC
- Check if any senders you DON'T recognize are getting through when they shouldn't
- Look at the emails failing DMARC and make sure those aren't something that SHOULD be getting through
- Generally check for things out of the ordinary - for example, if you're suddenly getting a significant spike in your overall email sending, or a big increase in DMARC failures. This could indicate your domain is "under attack" or a problem with errors in your SPF or DKIM.
Example of DMARC report with all emails passing
Here is an example of a DMARC report (from the aptly named system DMARCReport) for my domain for the past 7 days.
This tells me that there have been 26 emails sent from my domain name in the past 7 days; all have been DMARC compliant.
The senders are Zoho CRM (my email system), sendingservice.net (the MailPoet sending service, which I included as an example), mtasv.net (which I know is Postmark, the transactional email service I use to send emails from my website), and transmail.net (a system that Zoho uses to send emails from some of their other products).
I recognize all these senders, so I'm not concerned about someone sending emails pretending to be me.
You'll notice that sendingservice.net failed the SPF check. Let's take a closer look at that.
There's a technical explanation for SPF alignment which you can read if you're so inclined. But what it comes down to is that the MailPoet sending service is sending emails "from" my domain, but the return-path or "envelope from" address used by the email service is sendingservice.net. Since these domains don't match, the email will fail SPF alignment.
However, since the email is validated with DKIM, it will pass DMARC. Therefore, I'm not too worried about this - the email should still be getting through.
Conversely, Postmark allows you to set up a custom "return-path" so the emails from your website can pass SPF alignment. I have set up and tested my custom return-path, so the emails my website sends (mtasv.net in this example) pass both SPF and DKIM.
Example of DMARC report with emails failing - as they should
Here is an example of a DMARC report showing emails which failed DMARC checks.
This report shows senders I do NOT recognize. In this example, there is an IP 126.96.36.199, which resolves to jocularity.mammothswipe.com. I have no idea what this domain is, and it's nothing I've authorized.
They have tried to send 3 emails using my domain, but those emails do not pass SPF or DKIM, so fail DMARC, and my DMARC policy of "quarantine" has been applied.
If I saw a large amount of these emails, I might want to warn my customers that someone might be trying to launch phishing attacks with my email. You can't be 100% sure that the receiving email provider is actually quarantining or rejecting these fake emails (think how much spam you get in your inbox). Unfortunately, you don't know who the scammer might be sending emails to in your name, so there's not much you can do about that, but you can warn your customers and contacts. You can also do a WHOIS lookup and try to report these attempts to the "abuse@" email address.
Example of DMARC report with emails failing - potential problem
This is another example of a DMARC report showing emails which failed DMARC checks, but in this case, it could be a problem.
This report shows a large number of emails failing SPF and DKIM alignment, and therefore failing DMARC.
Investigating the senders with the large amounts of failures, e.g. mcdlv.net, we find that they are associated with Mailchimp, an email marketing platform.
In this case, it appears the client is sending emails through Mailchimp, but has not properly set up the SPF and DKIM records. The DMARC policy for this domain is currently set to "none", so the emails may be getting delivered; however, with the recent Google and Yahoo requirements for email authentication, I'd expect they are going to start seeing failures in their email campaigns soon.
There are also some other unknown senders that are using their domain to send email, and those emails may also be getting through - these could be phishing emails or just spam, but it has the potential to damage their reputation. (They really should hire me to fix this issue 😉)
What we should do in this case is set up the appropriate records for the third party that should be allowed to send emails (Mailchimp), then once we've identified and authenticated all the known senders, slowly tighten the DMARC policy until the attempted spoofers get their emails rejected.
Set up DMARC, and actually use it to make things better!
Maybe you never heard of DMARC before the Google and Yahoo requirements, or maybe you decided to set up email authentication as one more layer of cybersecurity for your business. Either way, properly setting up and monitoring DMARC helps to reduce spam and can help protect your domain reputation.
Set up your DMARC record and sign up for an analyzing service to send the reports to. Start with a DMARC policy of p=none, then monitor your reports for a while until you've identified all your legitimate senders.
Once you see that your approved senders are all passing DMARC, move to p=quarantine and eventually p=reject to stop scammers from using your domain. You want to continually monitor your DMARC reports to be sure your legitimate emails continue to get through, and that no spoofers have been able to sneak through your defenses.
Need help with DMARC?
If this really isn't your thing, and you want someone else to handle it for you, or you'd like to offer this service to your clients, get in touch and let's talk about how I can help.