{"id":15986,"date":"2018-04-09T18:10:53","date_gmt":"2018-04-09T18:10:53","guid":{"rendered":"https:\/\/easydmarc.com\/blog\/?p=15986"},"modified":"2026-03-18T14:04:44","modified_gmt":"2026-03-18T14:04:44","slug":"dmarc-is-easy","status":"publish","type":"post","link":"https:\/\/easydmarc.com\/blog\/dmarc-is-easy\/","title":{"rendered":"DMARC is easy! Implementation of SPF, DKIM, and DMARC Explained"},"content":{"rendered":"
\n

The following happens in IT so often that it\u2019s a clich\u00e9.<\/p>\n

Somebody comments to senior management about a complex, long-term project you\u2019re involved in, saying: \u201cThat\u2019s easy. I could do that in an afternoon. What\u2019s taking your people so long?\u201d\u00a0<\/em> Or you\u2019ve 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: \u201cWe looked at that and decided it wasn\u2019t worth the effort. Nobody in our sector is going ahead with that \u2013 you shouldn\u2019t either.\u201d<\/em> Either of these or similar expressions, can be devastating to your DMARC project. But are either of them true?<\/span><\/p>\n

But is DMARC easy or is it one of “those projects” that get rejected?<\/p>\n

Some say \u201cAll you have to do is put something in DNS \u2013 it\u2019s a piece of cake!\u201d<\/p>\n

As always, there\u2019s some truth to this statement \u2013 but it\u2019s not the whole story.<\/p>\n

Having email\u00a0DMARC explained<\/strong> to the decision-makers in your company can be hard, but bear with us. Having SPF, DMARC, and DKIM explained<\/strong> could take even longer. But bear with us: we have some hints that might make it easier for you.<\/p>\n

What Are the Recommended DMARC Steps?<\/h2>\n

The first step people recommend with DMARC<\/a> is almost always very simple \u2013 create a DMARC record<\/a> in DNS using a dmarc record creator<\/a> and start monitoring a domain. That might be your primary domain or a carefully selected test one. But the very reasonable idea is to get some reports and see where the email traffic of that domain is coming from.<\/p>\n

Perhaps you\u2019ll identify some vendors or partners you didn\u2019t realize were sending on your behalf. Perhaps you\u2019ll be surprised to find that there is \u2013 or isn\u2019t \u2013 a significant volume of fraudulent messages using that domain.<\/p>\n

For small organizations this may gloss over the fact that they don\u2019t control, or perhaps even understand, how DNS works \u2013 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.<\/p>\n

You might have to wait until the next regularly scheduled change window even for a domain that isn\u2019t in production use.\u00a0 And any stakeholder with sensitive production changes might override approvals and cancel your change request simply to avoid any \u201cunknown unknowns.\u201d This has actually happened, pushing deployment of a simple DMARC monitoring record from month, to month, to month.<\/p>\n

Publishing a DNS Record is Only Step One<\/h2>\n

Great, you\u2019ve published that DNS record \u2013 unfortunately, there\u2019s more work needed to take advantage of it.<\/p>\n

Smaller organizations might not be prepared for the number of aggregate reports<\/a> they receive each day, to say nothing of the volume of failure reports<\/a> 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<\/a> 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.<\/p>\n

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\u2019s 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.<\/p>\n

Implementing or Correcting DKIM and SPF<\/h2>\n

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.<\/p>\n

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\u2019t provide that option, or they may just not know what it is they need to ask for \u2013 or be able to educate or influence the vendor they\u2019re currently working with or use some open source solution<\/a>. 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?<\/p>\n

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\u00a0 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.<\/p>\n

When and Whether to Publish Quarantine or Reject Policies<\/h2>\n

Moving beyond a \u201cp=none\u201d policy is a decision each organization needs to make on a domain-by-domain, or even a subdomain-by-subdomain basis.<\/p>\n

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 \u201cfail\u201d<\/a> result for the message, you may not want to block that portion of your messages from reaching their destination with a quarantine<\/em> or reject<\/em> policy. (If you don\u2019t 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.)<\/p>\n

Larger organizations again face more complicated situations. Domains \u2013 or subdomains \u2013 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<\/em> or reject<\/em> policy is a \u201cno brainer,\u201d \u2013 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\u2019t forwarded for example.<\/p>\n

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 quarantine<\/em> or reject<\/em> DMARC policy, which may be an unacceptable impact. It may be possible to remediate this \u2013 for example, by having employees sign up for mailing lists under a dedicated subdomain with a different DMARC policy<\/a> \u2013 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.<\/p>\n

What About the \u201cDMARC is Hard\u201d View?<\/h2>\n

There is just as much potential for upsetting plans when somebody offers the opinion that DMARC<\/a> itself, or the characteristics of a given company\u2019s messages or domains, or its external relationships \u2013 or whatever the details may be \u2013 make it too complicated for that organization to deploy DMARC. The range of factors that might be cited is virtually unlimited, however, and it\u2019s a little tougher to pick out examples as we did in the previous section.<\/p>\n

Small organizations can make progress even if they aren\u2019t 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 makes the investment in resources a lot easier to justify.<\/p>\n

In larger organizations, a methodical approach and realistic expectations are the remedies 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<\/a>, and that trend isn\u2019t 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.<\/p>\n

Is DMARC Ridiculously Easy or Impossibly Hard?<\/h3>\n

Is DMARC so hard you shouldn\u2019t bother? Of course not. Is DMARC so easy that you should reject any plan that takes more than a month? Of course not.<\/p>\n

We\u2019ve seen that there\u2019s some truth behind each of these pronouncements. Given the range of situations and potential solutions outlined in even this article, it shouldn\u2019t be too surprising to hear that there isn\u2019t 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.<\/p>\n

Email Authentication is Really About Execution and Operations<\/h4>\n

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. Email has been around for so long. It is imminent death at the hands of the latest hot application so frequently announced. Often organizations simply don\u2019t bother to invest in getting messaging operations right.<\/p>\n

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. It requires an investment in talent and resources, and you need to have good processes in place to keep it running properly. And if you can\u2019t convince your stakeholders, partners, and vendors to get with the program, you\u2019ll never be able to deploy a strong DMARC policy.<\/p>\n

Maybe that\u2019s 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\u2019t being abused \u2013 for now.<\/p>\n

But as the industry moves forward and email authentication becomes the norm, domains that don\u2019t adopt it are going to become the targets of choice for bad actors simply by process of elimination. So don\u2019t 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.<\/p>\n

\n<\/p><\/div>\n