It happens so often in IT that it’s a cliché. Somebody comments to senior management about a complex, long-term project you’re involved in, saying: “That’s easy, I could do that in an afternoon. What’s taking your people so long?” Or you’ve spent weeks on careful research, building the business case, explaining the cost-benefit trade-offs, and have almost secured the commitment of resources when somebody from outside says: “We looked at that and decided it wasn’t worth the effort. Nobody in our sector is going ahead with that – you shouldn’t either.” Either of these, or similar pronouncements, can be devastating to your DMARC project. But are either of them true?
“All you have to do is put something in DNS – it’s a piece of cake!”
As always, there’s some truth to this statement – but it’s not the whole story.
The first step people recommend with DMARC is almost always very simple – create a DMARC record in DNS and start monitoring a domain. That might be your primary domain, or a carefully selected test domain. But the very reasonable idea is to get some reports and see where email traffic using that domain is coming from. Perhaps you’ll identify some vendors or partners you didn’t realize were sending on your behalf. Perhaps you’ll be surprised to find that there is – or isn’t – a significant volume of fraudulent messages using that domain, and where it’s coming from.
For small organizations this may gloss over the fact that they don’t control, or perhaps even understand, how DNS works – let alone the particulars of DMARC DNS records.
At the other end of the spectrum are large enterprises that have to manage thousands of domains. In those cases, there may be several teams that need to coordinate any DNS change that could conceivably impact production systems. You might have to wait until the next regularly scheduled change window even for a domain that isn’t in production use. And any stakeholder with sensitive production changes might override approvals and cancel your change request simply to avoid any “unknown unknowns.” This has actually happened, pushing deployment of a simple DMARC monitoring record from month, to month, to month.
Publishing a DNS Record is Only Step One
Great, you’ve published that DNS record – unfortunately there’s more work needed to take advantage of it.
Smaller organizations might not be prepared for the number of aggregate reports they receive each day, to say nothing of the volume of failure reports they might receive if they enable that feature. Even if they navigate those hurdles, interpreting the reports can be a challenge for somebody not familiar with the mechanics of email, despite some excellent packages and services that are available. Medium-sized outfits may face a similar issue with having the necessary expertise in-house, or with those experts having the availability for yet another project.
Larger enterprises may once again face larger issues. To the extent that they are better known or consumer-facing brands, they are likely dealing with greater volumes of both legitimate and fraudulent email. This translates into that many more aggregate and failure reports, making the processing and interpretation that much more challenging. The larger the organization, the more likely they are to have multiple internal sources of legitimate email any given messaging or IT group is unaware of, as well as multiple external vendors and partners sending legitimate messages on the firm’s behalf. All of which may require a lot of searching inside the organization to determine who owns the relationships or manages the contracts, which is necessary for the next step.
Implementing or Correcting DKIM and SPF
Publishing initial DNS records only addresses the reporting side of DMARC. You still have to implement DKIM and SPF correctly before you can move towards publishing policies that would reduce fraudulent messages.
Small operations may not have any experience, or any access, to implement DKIM and SPF on their mailstream. They may use a turnkey solution from an vendor that simply doesn’t provide that option, or they may just not know what it is they need to ask for – or be able to educate or influence the vendor they’re currently working with. And if they currently use an all-in-one solution for hosting and messaging, how likely are they to going to be to migrate the messaging function to a more capable, and probably higher cost, solution?
Large enterprises face the aforementioned problems with many different internal stakeholders and external partners. The more complex mix of interdependent products and applications internally, and the number of different vendors with their own feature roadmaps and commitments externally, can make implementing or correcting DKIM across all the legitimate email sources a lengthy process. SPF can cover for this to a degree, but only when there is little or no forwarding in the mailstream in question.
When and Whether to Publish Quarantine or Reject
Moving beyond a “p=none” policy is a decision each organization needs to make on a domain-by-domain, or even a subdomain-by-subdomain basis.
Smaller organizations may find this phase easier since they will generally have fewer domains to address, and they may be more constrained in what they can do with them. First, if you send much email from your domain to mailing lists or other forwarders that will cause a DMARC “fail” result for the message, you may not want to block that portion of your messages from reaching their destination with a quarantine or reject policy. (If you don’t already know whether this is the case, you would find out if your messages are going through such services from the reports mentioned in the previous section.)
Larger organizations again face more complicated situations. Domains – or subdomains – used only for marketing or transactional messages to customers are the prime targets for bad actors because users are used to interacting with these messages. These domains are unlikely to be sending messages to mailing lists, and there may not be many recipients who forward their messages from one mailbox to another. In that case, adopting a quarantine or reject policy is a “no brainer” – and if there are more messages being forwarded than stakeholders are comfortable potentially blocking, customer outreach can explain the need to provide addresses that aren’t forwarded, for example.
Enterprise domains being used for random correspondence by employees typically present more of a challenge. Some employees may be subscribed to mailing lists, others may be interacting with services that forward messages, or recipients that forward one mailbox to another. All of these present a higher chance of legitimate messages failing under a quarantine or reject DMARC policy, which may be an unacceptable impact. It may be possible to remediate this – for example, by having employees sign up for mailing lists under a dedicated subdomain with a different DMARC policy – but this may represent a lot of work with a long lead-time. Then repeat that evaluation and potential remediation with each production domain, and the scale of the effort starts to come into focus.
Wait, What About the “DMARC is Hard” View?
There is just as much potential for upsetting plans when somebody offers the opinion that DMARC itself, or the characteristics of a given company’s messages or domains, or its external relationships – or whatever the details may be – make it too complicated for that organization to deploy DMARC. The range of factors that might be cited is virtually unlimited, however, and it’s a little tougher to pick out examples as we did in the previous section.
Small organizations can make progress even if they aren’t email experts. It may require engaging more or different technical resources than they have previously, or some self-education to be able to take a DIY approach. If their domain is being abused, this frequently makes the investment in resources a lot easier to justify.
With larger organizations, a methodical approach and realistic expectations are the remedy for many of these situations. Because DMARC can be applied at the subdomain level where needed, there is great flexibility in how an organization can tackle each domain. It is true that it can take a long time for external partners and vendors to deploy DKIM when they previously had no plans to do so, and this could require contract changes or additional fees. But the industry has been steadily moving in this direction, as Google and Yahoo have been saying clearly and publicly, and that trend isn’t going to reverse. So if they continue to refuse, their business is going to start to suffer for it in the not-too-distant future.
Is DMARC Ridiculously Easy or Impossibly Hard?
Is DMARC so hard you shouldn’t bother? Of course not. Is DMARC so easy that you should reject any plan that takes more than a month? Of course not.
We’ve seen that there’s some truth behind each of these pronouncements. Given the range of situations and potential solutions outlined in even this article, it shouldn’t be too surprising to hear that there isn’t a simple answer to all of them. Except to say that too often organizations take email for granted, and that may illuminate the way forward for any of these situations.
Email Authentication is Really About Execution and Operations
You may be stunned to learn that email is often not the top priority of any given organization. Email notifications are not the primary function of the sexy new mobile application. Central IT infrastructure is not seen as contributing to the bottom line, and so is not exactly showered with resources – or even badly needed updates. Email has been around for so long, and its imminent death at the hands of the latest hot application so frequently announced, that often organizations simply don’t bother to invest in getting messaging operations right.
But execution is what brings home the win. You have to be on top of how your organization uses email in order to make best use of DMARC, or any aspect of email authentication. It requires an investment in talent and resources, and you need to have good processes in place to keep it running properly or those investments will have to be repeated. And if you can’t convince your stakeholders, partners, and vendors to get with the program, you’ll never be able to deploy a strong DMARC policy.
Maybe that’s just the decision they make, when it comes down to larger business priorities. And that might be fine if you learn from your early monitoring that your domain(s) aren’t being abused – for now.
But as the industry moves forward and email authentication becomes the norm, domains that don’t adopt it are going to become the targets of choice for bad actors simply by process of elimination. So don’t be surprised if those business priorities change, and at least have a plan ready for when the balance tips and you need to give email the attention and protection it requires.