Many organizations are aware of the dangers of phishing attacks that impersonate sender identities. As a result, more than 1 million domain owners have installed DMARC email authentication to protect themselves from email spoofing.
It is a different matter to create DMARC policies that protect you. It would help if you first got enforcement of DMARC. You can understand the extent of your email ecosystem. Which cloud services are sending emails on your behalf? What attackers could be using your email address to launch phishing attacks? Then, you can do something about it. First, stop the bad guys. Then, make sure that legitimate services are authorized.
Cloud services can sometimes get in the way. For example, it isn’t easy to see which services are sending you an email. DMARC enforcement can be harder than it looks, and this is one of the reasons why.

Why visibility is important

Getting email authentication right has required careful planning. It was easier to do before enterprise software, and on-premises mail servers were migrated to the cloud.
Email is used by many SaaS applications to increase engagement, retention, conversion, or send notifications and updates. You can set them up to send emails “from” your domain so that it appears like they are coming from your company and not “cloudprovider.com”.
Partially visible is not enough.
There are thousands of cloud apps on the market, but only two per cent (a little over 100 currently) are known and widely used. Nevertheless, it accounts for 90–98 per cent of all email volume sent by an average enterprise.
There are many other services available, and each has its configuration requirements for SPF or DKIM.
Many DMARC solutions are capable of identifying and helping you to configure cloud services that makeup 2%. What about the 98%? What can you do to find them?

Analysis of DMARC reports is not for the weak at heart.

DMARC aggregate reports, which are large XML dumps, identify sending services by their IP addresses. These reports are valuable if you can identify which cloud services the addresses corresponded to when they were run.
The next step is to ensure that your SPF record contains the services you wish to allow without exceeding the 10 DNS lookup limit and without resorting to fragile techniques such as SPF flattening. It means listing all the IP addresses numerically instead of referring to the service with a name.

Scaling DMARC to Subdomains

Imagine that you are trying to obtain a large domain for DMARC enforcement. For example, this could be a domain belonging to a state or a large retailer. Each subdomain has its administrator and has its own set of cloud applications.
You now need to resolve the cloud visibility issue for each subdomain and deal with DKIM and SPF configurations for each app in each subdomain.
It’s no wonder the overall DMARC enforcement rate for large enterprises is so low — about 30% for most industries.

DMARC for cloud

You must be able to identify each cloud service by its name to solve the cloud visibility issue. It’s easier to identify the cloud services your domain uses by name than just looking through XML DMARC reports.
Once you have this visibility, it is easier to create the optimal SPF record, establish DKIM and apply a DMARC rule across your entire domain and all its subdomains.
You should also enable role-based access control on each subdomain so that each administrator can manage their subdomain.
Imagine never again having to touch DNS. Instead, imagine automating all steps required to validate legitimate email services, including checking SPF records, validating DKIM encryption key for each service and updating DNS DMARC records.

EmailAuth is a tool that promises to deliver this promise. It’s used by some of the largest enterprises in the world to get DMARC reporting visibility and enforce DMARC.
If you’d like to learn more, read the whitepaper, The Guaranteed Path to DMARC Enforcement.

Source: https://medium.com/@rawatnimisha/not-yet-at-dmarc-enforcement-maybe...