DMARC is a widely supported, standards-based approach to email security. However, that statement can often cause confusion as it suggests that organizations just get it by default. In this post, we look at what it really means to 'have' DMARC.
Firstly, what is DMARC?
DMARC is a widely-adopted security standard that provides protocol-level security. When correctly configured at a policy of p=reject, it stops hackers and bad actors from being able to spoof your domain (i.e. pretend to be you) to send phishing emails to your employees, customers, and wider supply chain.
But what does that all mean for your business? Do you automatically have it? Maybe you've heard that Microsoft, Google, or your Cisco appliance supports DMARC. So do you - as a business - need to do anything? Don’t you just ‘have’ DMARC? Well, unfortunately not quite.
There are two parts to DMARC
The DMARC standard has two parts, one for receivers and another for senders. The widely supported part is the receivers, practically all email receivers such as Microsoft, Google, Yahoo, etc implement this part of it.
You can think about this part in terms of HTTPS, like the little green security lock that you see on all good web properties. Your browser supports it, but if your bank doesn't enable it, it provides no benefit when you use your browser to access your account details.
To 'turn DMARC on' for your organization (the sender), you first need to advertise that you are ready for it on your DNS. This is what all the mail receivers around the world are checking today. So you find a DMARC generator online, follow the recommendations, and modify your DNS with the appropriate incantations. Now you have a magic piece of text that looks a little like this:
v=DMARC1; p=none; rua=mailto:me@mydomain.com; ruf=mailto:me@mydomain.com; sp=none; ri=86400
And just like that, you're advertising to the world that you have adopted DMARC. Surely you have it now? Well, not quite.
What is a DMARC policy, and why do I need one?
Your inbox will now be spammed by servers all around the world with email traffic reports for your domain (www.example.com), yet you haven't actually asked recipient servers to do much with the emails coming from your domain. All the attacks that DMARC is supposed to protect against are still going through, and your domain is still vulnerable to impersonation. This is because you're currently advertising a policy of p=none.
This is a fairly common situation. Your DMARC policy is essentially the instruction you give to receiving servers, telling them what to do with emails that come from your domain. Essentially, having a DMARC policy of p=none is like having a firewall that allows all traffic in and out but gives you a log of the activity. The three DMARC policies are:
To really benefit from all the internet infrastructure that already exists around you, you need to move to an enforcing policy i.e. p=quarantine or ideally p=reject. While you could try to turn it on with a simple edit to the policy, most likely your email will just stop working and you'll rapidly jump back to p-none.
This is because all those delivery problems you've probably heard about (marketing emails that get low deliverability scores, proposals that have gone to spam etc) now suddenly become hard failures. In your post-DMARC existence, there is no leeway, and all those emails go nowhere.
Correctly implementing DMARC is the hard part
This is the real task at hand, and an inbox full of difficult-to-interpret XML attachments won't get you very far. Hidden amongst millions of DMARC data points, any one of these reports could contain a critical piece of your infrastructure that is failing to authenticate and not getting through. But without the right tools to interpret the data, it's like trying to find a needle in a haystack.
There are also unfortunate limitations in the standard that make deployments challenging, such as the limits of the foundational DNS based authentication technologies.
AI-based DMARC tool OnDMARC does the hard work
This is why we created our award-winning product OnDMARC, helping organizations of any scale successfully implement and maintain their global email authentication layer. Next generation solutions such as OnDMARC solve these problems so you can successfully deploy DMARC irrespective of your level of infrastructure complexity or IT experience.
As well as the obvious security improvements, a happy benefit of DMARC-authenticated email is that deliverability goes up as receiving servers can now trust the emails your domain sends. Google has been recommending this for some time, and as we move to a more hostile landscape, email authentication via DMARC is a big part of the fight back.
So, in summary:
- DMARC is protocol-level protection but that does not mean it is turned on for you by default.
- Turning it on will involve more than a single DNS change, and you want to be using the best tool available for your needs.
- If your email is not DMARC-enabled, then your organisation is not enjoying the level of visibility, security, and deliverability that it should be.
It's worth mentioning that while all serious email security solutions implement DMARC there are a few holdouts. Gartner required DMARC support in 2016 to rate providers leaders in their sector but legacy providers still exist. If your company is using outdated technology in this fast-moving landscape, you are exposing yourself to unnecessary risk. Talk to us and we can provide you with more information given your specific infrastructure.
Quickly check your current SPF, DKIM, and DMARC setup using our free tool
To get started on your DMARC journey, you'll first want to see what your current email security setup looks like. To do this, you can use our quick and easy investigate tool to check your current SPF, DKIM, and DMARC setup in seconds. Try it below!
