Not yet at DMARC enforcement? Maybe your DMARC solution isn’t cloud-ready
By now, many organizations understand the threat of phishing attacks that impersonate sender identity. More than one million domain owners have started to implement DMARC email authentication to protect themselves from email spoofing.
But it’s another problem entirely to set a DMARC policy that actually protects you. Before you can get to DMARC enforcement, you need to discover the full extent of your email ecosystem: Which cloud services are sending email on behalf of your domain, which attackers might be using your email to launch phishing attacks. Then you need to do something about it, blocking the bad guys and ensuring that the legitimate services are properly authorized.
But sometimes cloud services can get in the way of that process, by making it hard for you to see exactly which services are sending email on your behalf. DMARC enforcement can be harder than it looks, and this is one of the reasons why.
Why you need visibility
Email authentication has always required careful planning to get things right. But doing so was less intimidating before enterprise software and on-premises mail exchanges migrated to cloud platforms.
Many SaaS applications today use email to drive engagement, conversion, and retention, or simply to deliver notifications and updates. Naturally, you can configure them to send email “from” your domain, so it looks like those messages are coming from your company instead of “cloudprovider.com”.
The problem is that the more SaaS applications you use, the more complicated it can be to get to DMARC enforcement.
To move your DMARC policy to p=quarantine or p=reject, you need to be able to identify all the senders who should be able to send email messages using your domain. Then you’ll need to update your SPF record to authorize them, or configure them to use your authorized DKIM key, ensuring that their legitimate messages will get delivered when they reach their destinations.
Moving to enforcement without authorizing every service you actually use means that some of your legitimate senders are going to get blocked.
When you multiply that out by a few dozen or even hundreds of cloud applications, you have a lot of work to do. And keep in mind that some services send email regularly, like Salesforce or Zendesk, but others only send email occasionally.
Partial visibility isn’t enough
Of the thousands of cloud applications in the marketplace, only about two percent of them (currently a little more than 100) are well-known and widely used, accounting for 90 to 98 percent of the email volume sent by a typical enterprise.
But there are thousands of other services out there, each one of which has its own particular configuration requirements for SPF and/or DKIM.
Many DMARC solutions can identify and help you configure the most common 2% of cloud services. But what about the other 98%? How do you find them?
DMARC report analysis is not for the faint at heart
DMARC aggregate reports are large XML data dumps that identify sending services by their IP addresses. To derive value from these reports, you’d have to determine which cloud services the addresses correlate to at the time the report was run.
You’ll then have to make sure your SPF record includes the services you want to permit, without running up against the 10 DNS lookup limit, and without resorting to fragile techniques like SPF flattening (basically, listing all those IP addresses numerically instead of referring to the service with a domain name).
Scaling DMARC to subdomains
Imagine you want to get a very large domain to DMARC enforcement — like a state government domain or a large retail domain with hundreds of subdomains, each with their own administrators, and each with a different set of cloud applications using that subdomain to send email.
Now you have to solve the cloud visibility problem for each of those subdomains, and deal with SPF and DKIM configuration for each of those apps in each subdomain as well.
It’s no wonder the overall DMARC enforcement rate for large enterprises is so low— about 30% for most industries.
DMARC for the cloud
To solve the cloud visibility problem definitively, you must be able to identify every cloud service by name. Instead of parsing through XML DMARC reports and mapping IP addresses to cloud services, it’s much easier if you can actually see what cloud services your domain uses, by name.
And once you have that visibility, it’s easier to create an optimal SPF record, set up DKIM, and apply a DMARC policy across your entire domain and all of its subdomains.
Ideally, you’d also want to enable role-based access control for each subdomain, so each of those administrators can manage their own subdomain.
Imagine never having to touch DNS again. And imagine automating all the steps needed to validate the legitimate email services — checking SPF records, validating DKIM encryption keys for each service, and making the necessary updates to DMARC records in DNS.
That’s the promise of Valimail Enforce, which is used today by some of the world’s biggest enterprises to gain DMARC report visibility and get to DMARC enforcement.
If you’d like to learn more, read the whitepaper, The Guaranteed Path to DMARC Enforcement.
