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”.
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 blog, What’s the easiest path to DMARC enforcement?