Domain-based Message Authentication, Reporting, and Conformance (DMARC) has reporting right there in the specification’s name, but reporting is actually an optional part of the protocol. And it’s possible to enable DMARC without configuring it to protect your email domain from phishing and spoofing.
Here’s why you should make sure that you’re set up to receive DMARC reports and learn from the data they can provide. You also need to be careful not to just assume that everything is good and done, regardless of your DMARC policy.
Avoid DMARC policy shortcuts
The world of deliverability often moves fast and furiously, trying to implement as much deliverability-improving technology as possible for as many clients as quickly as possible.
That can mean taking shortcuts or only partially implementing various specifications. It’s certainly something I’ve been guilty of in the past – for my own domains and for client subdomains. Implementing p=none as a policy and moving on (because it’s “good enough”) or implementing p=reject for a subdomain, but without reporting in place.
Putting the R in DMARC
Based on my DMARC domain data, in late April, more than 77,000 domains had implemented a p=reject enforcement policy but didn’t have an aggregate reporting address (rua=) specified. Hopefully, these are domains that send little or no mail, but surely some of them do send email messages.
When running a restrictive DMARC policy, it’s really important to have reporting in place, so you can catch and identify:
- When something goes wrong with existing authentication settings
- A colleague at a company implements a new shadow IT solution, setting up a new email-sending service without knowing to properly configure email authentication first
In these cases, DMARC reporting is what helps you figure out that something’s wrong and guides you toward addressing it.
Subdomains are another problem area. There are thousands of subdomains out there that publish a p=reject policy but similarly have no reporting in place. A company might receive some reporting back if DMARC is implemented at the top/organizational level of the domain (assuming that implementation has reporting specified).
But you can’t rely on that alone; it will have gaps when it comes to the subdomain.
This is really common for subdomains configured for various email marketing automation platforms. In general, everything works well for those subdomains because they have very specific uses (usually, the subdomain is dedicated to a particular sending platform, which takes care of all email authentication settings, etc.). However, the lack of reporting means that if something goes wrong – such as broken DNS causing authentication failures – you will miss out on the chance to receive strong notifications of that fact through DMARC reporting.
Remember that none does not mean done
We know that bad actors are on the hunt for domains with weak DMARC policies. A policy of p=none means that, while you’ve started to implement DMARC, your domain is not actually protected.
DMARC has three possible policies that instruct mailbox providers on what to do when it comes to mail that fails authentication checks. From a policy of none (do nothing) to quarantine (filter or move to a folder) to reject (do not accept and do not deliver), you’ve got a series of steps that start with no protection and move up from there.
Right now, the focus in the news is North Korea, looking to phish its way into stealing data and intel from experts in East Asian affairs. If that’s not your business’s personal area of expertise, then why care? Well, because they’re not the only bad actors out there. They’re just the ones in the news at this exact moment. Not only are there other bad actors out there right now trying to figure out who else they can steal data or money from, but there will be new bad actors in the future who will be wondering how to apply this same type of exploit to different industries and companies.
In short, don’t wait until somebody decides to target you. Learn from this, and know that it’s possible to protect yourself from this risk before the bad guys ever get around to targeting you.
Don’t let the complexity of DNS and the nuances of DMARC policies deter you from securing your email ecosystem. Valimail empowers you to move beyond the vulnerabilities of a p=none policy, offering clarity, support, and the technological prowess needed to implement a reject or quarantine policy efficiently.
We’re building the future of trusted email inboxes. To learn how you can take advantage of these benefits:
Al Iverson is Valimail’s Industry Research and Community Engagement Lead, bringing over 25 years of experience in email marketing, technology, and deliverability. He’s committed to helping people learn more about DMARC and adopt it beyond just the minimum requirements while also helping good people send email and get their mail delivered.
