After a month of reading DMARC reports I find I’m still asking myself – What is the next step? How does this help me (and in turn you)? I’ll hopefully have better answers later this week after my meeting with a couple of DMARC data experts. Remember I’m running in reporting only mode at the moment and just trying to grasp how bad the spoofing issues for email addresses @emailkarma.net are… Sadly Pharmacy Bots send more email as EmailKarma.net than I do on a daily basis 🙁
While I don’t have currently any answers about what to do with reports, I do have a few significant notes about DMARC to consider based on my observations:
- May Not Be For Everyone: DMARC is probably less useful for a hobby domains where there is typically very little out bound email traffic unless you are heavily spoofed in spam. However I have found that tracking these reports and understanding the patterns of spam bots faking users at my domains has become quite enlightening.
I’m hoping to learn more in the upcoming weeks as I get more in touch with the data and the options available for my domains. - Mailing List Issues: DMARC may fail when participating on discussion lists as some fail to authenticate the sender appropriately. Yahoo Groups seems to fail both SPF and DKIM tests for messages I have posted to a few lists. This could be an issue for some users if policy rules are implemented incorrectly or too aggressively.
- Information Overload: Seeing the number of forensic reports, individual reports for each message evaluated by the receiving domain, that are being generated for messages (both pass and fail). The number of messages reports could be excessive for large domains, domains that mail frequently or domains frequently attacked by spammers.
This problem is exponential as more domains check DMARC records and begin sending reports on the messages they are processing. - Reporting Data: Seeing all the links in spoofed emails could be very useful to commonly phished services by reducing the time to receive notifications of the attack (and shorten take down time) during spam runs. Also I could see services like the URIBL being utilized to quickly list spam sources. This would need to be automated as it can be a lot of data to review.
- Automation is Key: You will never be able to process these reports manually, building a solution or partnering with a reporting service that is already DMARC capable will be key to making use of it.
More on these solutions later
So far it’s been an interesting learning experience for me on this and I hope that these learning points will help you build your policies and encourage you to test DMARC against your email domains. If you are testing DMARC I’d love to hear your experiences either in the comments or send me an email: contact at emailkarma.net.
Great post, Matt. I’d like to pass along a couple of suggestions:
– For forensic reporting, I would suggest that people first publish a DMARC record without an “ruf” tag, which specifies where to send forensic reports to. It’s not required. Start with just an “rua” tag, which specifies aggregate reports to get a feel for how much forensic traffic you are likely to receive. The aggregate reports can be enough to consume without the added burden of trying to figure out forensic reports at the same time.
– I’d also say that DMARC reporting can be for everyone, but policy enforcement is not. Use technologies like DMARC to get a feel for whether or not your domain has a phishing/spoofing problem. If it doesn’t, then policy enforcement may not make sense for you. You won’t know that for sure though unless you setup reporting first.
My 2 cents.
Hi Sam,
I absolutely agree with the forensic reporting comment, even with just the daily aggregate reports, there is a lot to go through and understand. Forensic reports are great if you have a provider or an automated solution in place to make sense of them or have need to use them for security/auditing purposes.
Good note about the policy vs reporting features of DMARC, I would note that the average hobby domain owner would likely be very confused by just the reporting features of DMARC though, but you are right it “could” be for everyone but I think that day is a long way off… it would likely be better if hosting companies offered this as a service to their clients and had trained staff behind the reports to make it more user friendly and affordable to the common users.
Thanks for the comments.
Maybe I should clarify my “for everyone” comment a bit. I was referring primarily to domains who have a brand that they care about. This is generally going to be businesses, not necessarily personal vanity domains. I have a DMARC record for my own personal domain and I would guess that other email geeks like ourselves do as well, but in general most people with vanity domains aren’t going to care about DMARC.
Agreed, non-techies will not make use of this… but I still think hosting providers could use this to somehow make things safer for their users.