Categories
Dmarc as a Service

DMARC Deployment Challenges: 7 Common Mistakes

Learn about the most common types of DMARC deployment mistakes and what your business can do to proactively avoid and remedy these issues.

Interest in Domain-based Message Authentication, Reporting, and Conformance (DMARC) is growing exponentially, but most of the organizations that deploy DMARC don’t actually achieve its full anti-spoofing benefits.

While interest in DMARC is high, implementation isn’t. This is reflected in the fact that less than 20% of domains have their DMARC policy at the correct level of enforcement to protect them from spoofing.

DMARC enforcement: Implementation of the DMARC policy that instructs email receivers to reject or quarantine unauthenticated emails.

If you have published a DMARC record but haven’t reached DMARC enforcement yet, don’t worry. It’s not your fault. This project can be very challenging, even for the world’s biggest email security experts.

Fortunately, we’re here to help you get past the challenges and start reaping the true rewards of DMARC. Here are 7 common mistakes that domain owners make with setting up DMARC records and configuring underlying email authentication standards.

7 common DMARC implementation mistakes

While this is by no means a comprehensive list of mistakes or troubleshooting, it does highlight the most typical issues we see. Avoid these problems, and you’ll be on the right path to DMARC enforcement.

If you keep hitting obstacles on this journey, we have an eBook that will help you along this journey.

1. Confusing monitoring for protection

We’ve run across accounts where companies believe their domain is protected, but the DMARC record is left at p=none — for years.

The policy p=none puts the domain into monitoring mode so that DMARC-compliant receiving gateways send reports back to the domain owner about messages that passed and failed authentication.

But mail gateways only send data—they continue to deliver all email normally, even if it fails to authenticate. Monitoring is both useful and a required first step in the DMARC journey, but it does nothing to protect against spoofing.

Here are your options when configuring DMARC:

  • p=none: Monitor mode; no specific action is taken on emails that fail DMARC checks.
  • p=quarantine: Emails that fail DMARC checks are treated as suspicious and typically placed in the spam/junk folder.
  • p=reject: Emails that fail DMARC checks are rejected and not delivered to the recipient.

You’ll need to implement a policy of p=quarantine or p=reject to start protecting your email domains.

dmarc-policy-graphic

2. Believing in the myth of “partial enforcement”

By default, a DMARC policy applies to 100% of all mail unless a percentage is specified with a pct= tag. Unfortunately, if you are at p=quarantine and set a percentage less than 100, that means that some spoofed messages will still be delivered.

There is no such thing as “partial” DMARC enforcement.

While there are ways to use percentages usefully, don’t fall into the trap of thinking you’re fully protected if your pct= tag specifies anything less than 100%.

When in doubt, set it to 100%.

3. Forgetting about subdomains

The default setting for subdomains is to obey the main policy (e.g. p=reject). Sometimes in the process of getting to DMARC enforcement, domain owners focus on getting their main domain to enforcement while postponing the work needed to bring subdomains into enforcement by setting a subdomain policy of “sp=none.”

Unfortunately, this means that those subdomains can still be spoofed.

Phishing emails sent from:

whatever@example.com

won’t get through, but this email will:

whatever@mail.example.com

To be at enforcement, subdomains need to be protected, just like the main organizational domain.

4. Out of order records

We’ve seen many records that are not using the correct DMARC syntax.

An example: a DMARC record that places the policy, such as p=reject, behind another statement instead of directly following the v=DMARC1 statement.

Putting these tags in the wrong order can cause problems, making DMARC authentication fail or causing mail gateways to skip the DMARC check altogether.

5. Omitting a reporting address

One of the most important aspects of DMARC is that it provides domain owners with feedback about email authentication status, including passes as well as failures, via aggregate data reports.

But if you omit a reporting address (via a rua= tag), you will not get this data—and you’ll learn nothing about authentication failures and possible domain impersonation (spoofing) attacks.

The reporting address makes it possible for the DMARC record to specify how to report these failures.

6. Misconfiguring SPF records

The SPF record is a text record published in DNS that contains a list of IP addresses of permitted senders, rules pointing to other types of DNS records, and directives that reference SPF records of other domains.

While there are many ways to misconfigure an SPF record, one of the most common mistakes is building a record that requires the receiving domain to do more than 10 domain lookups for each message it receives. If a domain’s SPF record requires too many lookups, some or all emails sent from that domain may not authenticate successfully.

To get around this limitation in the standard, some domain owners “flatten” their SPF record by pulling all the IP addresses of approved sending services forward into the primary SPF record. A flattened SPF record lists a bunch of IP addresses explicitly rather than including equivalent DNS lookups.

But that introduces a new problem: The need to continually maintain the flattened list of IP addresses in case an email-sending service you’re using adds or removes IP addresses.

7. Mismanaging DKIM keys

DomainKeys Identified Mail (DKIM) uses public/private key cryptography to sign email messages, which validates that the email came from the domain that the DKIM key is associated with—and that the email has not been modified in transit.

DKIM keys are long strings of seemingly random data and are easy to get wrong in DNS. Even a simple copy/paste issue can cause errors, leading legitimate email messages to fail DKIM.

Experts recommend rotating DKIM keys at least every six months to prevent attackers from stealing or compromising the keys.

Many organizations have no method for managing and rotating keys; some even use the same DKIM key for each email service they use. If that one key gets compromised, every service is vulnerable to attack.

Avoid DMARC mistakes with Valimail

Mistakes #6 and #7 are the most critical to fix because, without properly configured SPF and DKIM, DMARC enforcement will never happen.

DMARC requires that the message pass either SPF or DKIM authentication, and it also requires alignment (a match) between the visible From: address in the email message with either the Return-Path found in the SPF record or the domain in the DKIM signature. So you’ve got to get these fundamental email authentication protocols right before you can protect your domain with DMARC at enforcement.

Worried that you’re making these mistakes but don’t want to go through the nitty-gritty troubleshooting and setup process? We get it. That’s why we offer Valimail Enforce, an automated path to continuous DMARC enforcement.

how valimail helps with dmarc

Valimail Enforce streamlines the DMARC implementation process with world-class automation tools to get you to continuous enforcement—all without any manual SPF and DKIM configuration.