5 Common DMARC Challenges Experienced After its Deployment

Deploying DMARC seems like one of the crucial steps taken towards email deliverability and security. While the process of email authentication is pivotal in the journey of safeguarding your brand from impersonation, phishing, and spoofing, the biggest step is actually appointing an expert (or becoming an expert yourself) who can manage and monitor SPF, DKIM, and DMARC records in such a way that there are minimal issues. Moreover, they should possess the capability of troubleshooting problems with minimum downtime. 

Domain owners often give no attention to the maintenance of email authentication protocols once they are deployed because either they have little knowledge about their nature or merely lack an IT resource skilled in this domain. 

This attitude gives hackers the opportunity to compose and dispatch fraudulent messages from your official domain name to manipulate recipients into believing they are coming from trusted sources. This is why receivers end up sharing sensitive information and documents, wiring money, or downloading malware-infected links on their devices. 

Here, we have addressed the 5 common DMARC challenges that you can come across.

5 DMARC Challenges Hindering Your Victory Against Malicious Actors

Not Receiving DMARC Reports

DMARC XML reports help you gain visibility into the email activities to understand how a recipient’s email server perceives your domain and if any threat actor is sending phishing emails. These insights are something that helps you make an informed and result-driven decision about transitioning DMARC policies and keeping checks on their respective percentages for the best compliance. 

The aggregate view of your domain’s traffic improves the effectiveness of DMARC policies while identifying unauthorized sending sources misusing your organization’s name and reputation. There are two types of DMARC reports: RUA and RUF. The former is sent regularly, and the latter is generated when an email fails the authentication check at the receiver’s end. 

To avoid this DMARC challenge, you need to add valid email addresses where you want to receive these XML reports to your domain’s DMARC record. You can also replace the email address with a URL pointing to an email authentication reporting system format.

Transitioning DMARC Policies

Domain owners often confuse monitoring for protection, which means they don’t aim to reach the highest level of email security through DMARC implementation. The none policy doesn’t shield domains from phishing and email spoofing, and hence, you should shift to the quarantine policy within a few weeks of DMARC deployment. 

By regularly monitoring aggregate and DMARC forensic reports, you can gain confidence and strategize the gradual transit to the reject policy, which is the strictest DMARC policy. This subsequently reduces the instances of false positives that hit the email delivery rate by placing a legitimate email in the spam folder of recipients. 

Moreover, administrators come across another DMARC challenge of getting stuck at partial enforcement for a long time. Unless specified, a DMARC policy is applied to 100% of all outgoing emails from a company. However, the use of the percentage tag allows them to apply the selected policy to a pre-defined percentage of messages only. 

EMAIL SECURITY WITH SPF, DKIM, AND DMARC

Ignoring Subdomains

The standard configuration for subdomains is to follow the primary policy form, which is either marking messages as spam or rejecting them. Occasionally, in the pursuit of achieving DMARC enforcement, domain owners prioritize enforcing the primary domain while delaying the necessary actions for enforcing subdomains, often setting a subdomain policy to “sp=none.”

Regrettably, this results in subdomains remaining susceptible to spoofing. While phishing emails sent from message@example.com will be blocked, those sent from message@mail.example.com will still get through. To achieve full enforcement, subdomains must also be safeguarded in a manner similar to the primary organizational domain.

Misconfigured SPF Records

An SPF record is a TXT record published in your domain’s DNS and contains a list of IP addresses and email servers allowed to send messages on behalf of your business. During SPF authentication, any sending source outside of this list is considered illegitimate and unauthorized, thus marking such email sender as spam or rejecting their entry. 

An SPF record is made out of syntax (mechanisms, qualifiers, and modifiers). There are certain rules that need to be followed while adding the SPF record syntax; otherwise, you are liable to a misconfigured SPF record, which is actually one of the most frequently observed DMARC challenges experienced after deployment. 

Also, there is a limit of a maximum of 10 DNS lookups, and exceeding this number makes your SPF DNS record invalid and incapable of conducting the authentication process. 

Mid-and-large-scale enterprises reach this limit quickly as their email infrastructure requires too many lookups. Domain owners and administrators can get around this limitation by flattening SPF records using AutoSPF’s automatic tools. A flattened SPF TXT record explicitly shows IP addresses instead of adding their equivalent DNS lookups. 

Apart from these two SPF-oriented DMARC challenges, the use of a ptr and mx mechanisms, the inclusion of invalid macros, typos, and the existence of multiple SPF records can also create issues. It’s advised to regularly and frequently run your TXT records through their respective record lookup tools to come across existing errors for a platform. Moreover, using a reliable SPF record generator should be your priority.

Mismanaged DKIM Keys

DKIM or DomainKeys Identified Mail is another email authentication protocol on which the DMARC authentication process relies. It includes a pair of public and private cryptography keys to sign email messages. Both the keys are matched at the recipient’s end to validate that the message has been dispatched from the domain that the key is linked with. Moreover, it verifies that nobody altered the email content in transit. 

These keys should be rotated regularly (at least twice an year) to avoid their exploitation. However, administrators avoid doing that, either out of a lack of knowledge or a poor understanding of the importance of email security. If a key gets compromised, a company’s entire infrastructure becomes vulnerable to attacks.

Back in 2012, Zachary Harris, a mathematician, figured out that Google has been using weak DKIM keys that have not been rotated in a while. Out of curiosity and for fun, he cracked the key with a little help from cloud computing and sent a fake email to the co-founder Larry Page from the other co-founder Sergey Brin’s email address.

As stated by Zachary, his intent was just to startle them and not take advantage of their vulnerability. However, had this security loophole come across a hacker, the outcomes could have been devastating.

So, the crux of the story demands your focus on receiving and monitoring RUA and RUF reports to figure out how to make policy transitions. We at DMARC Report help you get insight and gain control over outgoing emails by processing reports and utilizing a tool kit at no additional cost.