10 Mistakes to Avoid When Setting up DMARC

Estimated reading time: 10 minutes

A DMARC (Domain-based Message Authentication Reporting and Conformance) protocol provides email senders with a powerful tool to protect their email domains from spoofing assaults and ensure the authenticity and integrity of their email communications.

In order DMARC works, it’s important to implement it for a domain properly. This article covers the basic concept of a DMARC configuration and examines the most common mistakes domain owners make when setting up DMARC. 

Why DMARC is Important

The implementation of a DMARC protocol for a domain serves several purposes:

1. Strong email authentication. 

DMARC requires the messages to be aligned either by SPF or DKIM, which proves the authenticity of the sender and eliminates an email spoofing factor. 

2. Domain Visibility.

DMARC allows domain owners to receive the reports containing valuable information about sending sources, sent email volume, and email authentication outcomes. This data helps identify domain spoofing issues, determine SPF and DKIM failures, and get visibility on how the domain is being used.

3. Email Control.

A DMARC mechanism can instruct email receiving servers on how to handle unauthenticated messages with different policies written in a DMARC record. The enforcement policies such as ‘quarantine’ and ‘reject’ make the server instantly send an email to the Quarantine folder or reject it outright without a filter check. This ensures that no spam, spoofed or phishing emails will slip into the recipient’s inbox.

4. BIMI Implementation.

BIMI stands for Brand Indicators for Message Identification. Brands can show their logos next to authorized emails thanks to this email authentication standard. The recipients can easily recognize authentic emails from their favorite senders thanks to this visualization. The BIMI implementation becomes possible when a domain sending emails has DMARC configured with either ‘quarantine’ or ‘reject’ policy.

DMARC Record Structure

The implementation of a DMARC authentication mechanism for a domain requires the publication of a TXT DNS record. Using different tags in the record, domain owners can give instructions to email receiving servers concerning the email validation by DMARC, treatment of unauthenticated emails and emails sent from subdomains, generation of aggregate and forensic reports, and delivery of the reports to domain owners.

When creating a DMARC record, it’s important to be aware of the mandatory and optional tags to be used in the record.

The mandatory tags that cannot be omitted include:

v – this tag represents the version of a DMARC protocol; it always has the value v=DMARC1 and is placed at the beginning of the record value;

p – this tag represents the policy mode. It can have the ‘none’, ‘quarantine’, or ‘reject’ value.

Additionally, a DMARC protocol gives a range of optional tags to customize the DMARC application. The most popular optional tags that are recommended to senders for better DMARC implementation are:

rua –  this tag represents the email addresses where aggregate DMARC reports should be sent to;

ruf –  this tag represents the email addresses where forensic DMARC reports should be sent to;

sp – this tag represents a policy, which must be applied to unauthenticated emails sent from subdomains;

pct – this tag represents the percentage of unauthenticated emails for which the policy will be applied to. If it’s absent, the default value is 100%.

Below are the examples of DMARC records with different structures:

v=DMARC1; p=reject; 

v=DMARC1; p=quarantine; rua=mailto:agg_rep@domain.com;  ruf=mailto:for_rep@domain.com; fo=1;

v=DMARC1; p=reject; rua=mailto:agg_rep@domain.com, mailto:aggregate@example.com;  ruf=mailto:for_rep@domain.com, mailto:forensic@example.com; fo=1;

v=DMARC1; p=quarantine; sp=reject; rua=mailto:agg_rep@domain.com;  ruf=mailto:for_rep@domain.com; fo=1;

v=DMARC1; p=quarantine; rua=mailto:agg_rep@domain.com;  ruf=mailto:for_rep@domain.com; pct=25; fo=1;

How to Set up DMARC

Setting up DMARC for a domain involves two steps:

1. Creating a DMARC Record.

Creating a DMARC record is made easy with DMARC generator tools like GlockApps DMARC Analytics.

Enter your domain name and click ‘Next.’

Choose the parameters for the record:

Policy – choose ‘none’ if you are just starting with the DMARC implementation;

Policy for subdomains – move it On if you want to use a different policy for subdomains and choose a policy;

Advanced options – select the mode for SPF alignment and DKIM alignment; the ‘relaxed’ mode is set by default.

Click ‘Next’ to generate a DMARC record.

2. Publishing a DMARC Record.

Open your DNS management panel and choose the domain to publish a DMARC record for.

Click to add a new record and add a TXT record.

Use _dmarc as the host name and the generated value as the DMARC record value.

Save the changes. It may take up to 24 hours for the changes to propagate.

How to Check a DMARC Record

To check if a domain has a valid DMARC record, you can use a free DMARC checker. 

Enter your domain name and click “DMARC Record Check.”

The tool returns the verification result including the DMARC record value if it exists and the explanation of the tags used in the record. If some tags are formatted incorrectly, you will see warnings and guidelines on how to fix misconfigured tags.

Learn more: Improve Email Deliverability: Insights and Best Practices That Really Work

10 Mistakes to Avoid When Setting up DMARC

While the configuration of a DMARC protocol for a domain seems straightforward, there are the pitfalls that may prevent this mechanism from working correctly or make the functionality of particular tags ineffective.

Here is the list of the most common mistakes to avoid when configuring DMARC for a domain:

1. Adding Multiple DMARC Records on One Domain.

While the same domain can have multiple DKIM records, it cannot have more than one SPF and DMARC record. If you already have one DMARC record on a domain, you need to update the existing record value in case you change the record parameters.

It is possible to publish a DMARC record on each subdomain if you want to apply different policies to different subdomains.

2. Starting with DMARC Enforcement Policy.

It’s highly risky to set the ‘quarantine’ or ‘reject’ DMARC policy if you haven’t used DMARC before. According to these policies, your legitimate messages will be sent to Spam or blocked if they fail DMARC authentication.

It is highly recommended that you start with the ‘none’ DMARC policy if you implement DMARC for the first time. The ‘none’ policy sets the monitoring mode and allows senders to collect reports containing valuable information about email authentication outcomes. 

After analyzing the data in the reports and ensuring that your legitimate sources send DMARC compliant messages, you can move to the next level and apply the enforcement policy.

3. Not Using RUA and RUF Tags.

Although the tags with the email addresses to receive DMARC reports are optional ones, it’s crucial to include them into the record. This enables you to benefit from one of the advantages DMARC provides – getting visibility on your domain activity. 

Without these reports, you don’t receive valuable information about which sources are sending emails on behalf of your domain and you can miss email authentication breaches and domain spoofing attacks. A RUA tag with at least one valid email address to receive aggregate reports is highly recommended.

The use of automatic tools like GlockApps DMARC Analyzer makes the processing of DMARC reports easy and user friendly.

4. Formatting RUA and RUF Tags Incorrectly.

The email addresses used in the RUA and RUF tags must be preceded with mailto:

v=DMARC1; p=quarantine; rua=mailto:agg_rep@domain.com;  ruf=mailto:for_rep@domain.com; pct=25; fo=1;

When mailto: is absent, some reporters may not be able to locate the email addresses to send reports to. Hence, you may miss a great amount of data about your domain.

5. Using More than Two Emails in the RUA and RUF Tags.

Although there is no documented limit on the number of email addresses allowed in these tags, most of the reporters will send the reports to the first two email addresses and skip the others.

6. Not Configuring Third Party Domain to Receive DMARC Reports.

In some scenarios, domain owners want the reports to be sent to the email addresses set up on the domains different from the domain where a DMARC record is published. This allows the owners of the domains that do not operate mail servers to request reports and have them sent to other parties that can receive and process them. 

However, this flexibility opens the opportunity for bad actors who could publish a DMARC record with a third party’s email addresses and send a big volume of the messages. The third party would then be flooded with DMARC reports.

Therefore, a verification of the domains used in the RUA and RUF tags is implemented. The verification is made with a special DMARC record that must be present in DNS of the domain used to receive the reports.

Consider this example.

The sender has the following DMARC record on the mybusiness.com domain

v=DMARC1; p=quarantine; rua=mailto:aggreg@thirdparty.com; ruf=mailto:agg_rep@thirdparty.com; pct=25; fo=1;

In order the email addresses on the thridparty.com domain can receive DMARC reports sent for the mybusiness.com domain, the thirdparty.com domain must have a DNS TXT record as follows

mybusiness.com._report._dmarc.thirdparty.com  TXT v=DMARC1

Without this record, the verification of the thirdparty.com domain for the ability to receive DMARC reports for mybusiness.com will fail. Email receivers will fail to generate and send the reports to the specified emails addresses, too.

7. Setting up Strict Mode for ADKIM or ASPF.

The default value of the adkim and aspf tags is relaxed. This means that it is possible to use a subdomain in ‘Return-Path’ and in a DKIM signature to pass SPF and DKIM alignment. 

When the strict mode is set, the utilization of subdomains becomes impossible as it leads to alignment failures and can lead to DMARC test failure.

Using the relaxed mode for adkim and aspf is a recommended option. 

Senders can choose the strict alignment mode if the domains they use in Header From, Return-Path and d= tag always match.

8. Not Configuring DMARC for Subdomains.

When setting up a DMARC record for a domain, it’s important to understand that the record will also be applied to all of the subdomains unless they have their own DMARC records.

To manage subdomains differently, you can either use the sp= tag in the record published for the main domain and specify a policy for subdomains, or publish their own DMARC records for all the subdomains.

9. Not Configuring DMARC for Domain that Doesn’t Send Emails.

A lot of domain owners believe that a domain without outbound email traffic doesn’t need DMARC configured. However, any domain may be a victim of bad actors. Thus, even if a domain doesn’t send any email messages at all, it’s still highly advised to publish a DMARC record for it. The record may look like this

v=DMARC1 p=reject;

This way, although the reports are not generated and sent, the domain is protected meaning that any message sent on its behalf will be rejected due to the policy.

10. Not Enforcing DMARC Policy to Protect Domain.

Oftentimes, domain owners hesitate to enforce the policy fearing that it will block legitimate messages and keep the policy set to ‘none’ for ages.

However, this defeats the main idea of a DMARC protocol – domain protection. A DMARC mechanism gives senders flexibility and ability to instruct email receivers on how to handle messages. After the beginning phase when you collect the reports and analyze the email authentication outcomes, it is recommended to advance with policy enforcement. 

Using the pct= tag in the DMARC record, you can control the percentage of the emails the policy is applied to. Start with ‘quarantine’ 10% and increase the percentage every two-three weeks to achieve ‘reject’ 100%. If you encounter any breaches, you can always roll back until the fixes are applied.

Conclusion

DMARC provides a strong way of email authentication and domain protection. It ensures the email integrity and the sender’s authenticity by connecting both SPF and DKIM protocols. To take advantage of the capabilities DMARC offers, it is important to implement it for a domain thoughtfully. 

By following the recommendations in this article, you can create a valid DMARC record for your domain and set up DMARC parameters to make the most out of this powerful email authentication mechanism.