DMARC implementation

DMARC stands for Domain-Based Message Authentication Reporting and Conformance (DMARC) and is a mechanism that is intended to counteract so-called email spoofing. Email spoofing is the sending of spam emails with fake domains, mostly on behalf of well-known companies and brands that are not even aware of this abuse. These often lead to high bounce rates, spam trap hits and spam complaints, which are technically attached to the real domain owner and have a negative effect on the reputation of his domain and thus on the mailings sent from it.

DMARC therefore makes a major contribution to protecting the online reputation of your domains and your brand by preventing or at least reducing domain abuse. Participating Internet Service Providers also attribute senders using DMARC a better reputation and thus enable better delivery results. In addition, DMARC is a basic criterion for setting up BIMI (Brand Indicators for Message Identification).

DMARC is supported by the following ISPs (extract): Gmail, Yahoo, AOL, Microsoft, Netease (126.com, 163.com), Tencent (qq.com), Mail.ru, Comcast, AT&T, British Telecom, Virgin Media, Italia Online. 1&1 (GMX, Web.de) is currently implementing DMARC.

The handling of potential spam emails is generally the responsibility of the receiving ISP that works with a variety of security metrics, including Sender Policy Framework (SPF) and DomainKeys Identified Mail (DKIM), to protect its recipient’s mailboxes from spam, scam or phishing emails.

Using DMARC, you as the sender can now independently tell the receiving mailbox provider how they should proceed with emails if they cannot authenticate themselves via SPF and DKIM. DMARC is considered a third layer of protection, which is based on the existing authentication mechanisms SPF and DKIM and supplements them. The implementation of these two authentication standards is required at Optimizely during onboarding or when setting up additional sending domains.

In addition, the DMARC reporting functionality makes cases of domain abuse visible for the first time. This helps you to understand current delivery trends of your emails and to monitor your reputation.

DMARC can generally be set up for the entire primary domain or specifically for an email sending domain. Ideally, DMARC is set for the primary domain to protect the entire domain, all associated subdomains and thus the brand as a whole. The important part for the delivery of your emails is the application of DMARC on the sending domain.

The DMARC record is inherited by the subdomains belonging to the DMARC domain. If it is set on the primary domain, it is automatically applied to all associated subdomains of this domain.

To set DMARC, a subdomain with the name _dmarc must be created for the domain for which DMARC should ultimately be used. The Optimizely recommended entry is as follows:

One of the most important parts of the DMARC is the policy tag. With this, the domain owner specifies how a DMARC-supporting mailbox provider should handle emails that cannot authenticate correctly with SPF and DKIM. The following three policies can be set. Optimizely recommends setting the reject policy.

Using the reject policy, emails that an unauthorized third party tries to send on your behalf as part of a spam attack, would simply be blocked by the ISP.

The following table provides an overview of the possible DMARC tags. The Optimizely DMARC record only contains three of them.

—Table: DMARC tags—

The DMARC check itself is based on the DMARC Identifier Alignment. This requires that at least one of the domains that are authenticated via SPF and DKIM matches the visible sending domain.

In case of the SPF alignment, the technical domain (RFC5321), also called return path or envelope-from, must correspond to the visible sending domain (RFC5322), also called from-domain or header-from, and meet one of the two variants:

In case of the DKIM alignment, the domain that is signed with DKIM and can therefore be found in the d= parameter in the email header must correspond to the visible sending domain and meet one of the two variants:

An additional feature that SPF and DKIM do not offer is the creation of DMARC reports. DMARC reporting notifies you if authentication errors of the SPF and DKIM are detected in emails sent with your domain, which means that your domain is potentially abused.

DMARC reports can help you to understand whether and to what extent domain abuse is taking place. Spam emails that are sent in your name and with your domain ultimately also have a negative effect on your sender reputation and delivery performance. In addition, DMARC reports can provide you with information about the origin of spam attacks and help you to fight them.

Optimizely recommends setting up so-called aggregated reports.

—Image: DMARC report—

Source: DMARC.org

The report contains general information about the sender and the period under review in the <report_metadata> area. Furthermore, in the <policy_published> area, you will see the DMARC policy applied and other tags used such as domain alignment or DMARC percentage. The last and most important section <record> contains the sending IP and domain, which caused an SPF and/or DKIM error. <dkim>fail</dkim> indicates that the domain signature could not be verified, and on the other hand, <spf>fail</spf> indicates that the sending IP was not contained in the SPF record of the sending domain.

In addition to the aggregated report, there is also a second reporting format, the forensic failure report. However, this report contains personal data such as the email addresses of unrelated recipients and is therefore classified as not GDPR-compliant and not recommended to be used.

To implement DMARC, perform the following steps:

Select the domain on which you want to set DMARC. You can

In order for DMARC to have an impact on your deliverability, it must at least be set for the sending domain used with Optimizely. However, it is recommended to set up DMARC on your primary domain to protect the entire domain and brand.

When using a domain that is used for sending with Optimizely, domain alignment and both authentication mechanisms SPF and DKIM are set by default. If you are unsure:

To receive DMARC reports, you need to set an email address. The reporting address should be based on the same primary domain like your DMARC domain. Since you will possibly receive a lot of reports, it makes sense to create a separate mailbox for them.

If you would like to use a domain other than your sending domain or its primary domain, this is possible with an additional DNS configuration.

Example: Your sender or primary domain is example.com, but you want to send your DMARC reports to an email address with the domain otherdomain.com. The reporting domain otherdomain.com must first be authorized to receive DMARC reports, otherwise this address could be misused.

To do this, create an additional domain construct based on the following example for the authorization check: example.com._report._dmarc.otherdomain.com And set the following DNS record for the external reporting domain:

Now your DMARC reports can be sent to the specified reporting address.

If you want to use an official tool for DMARC analysis, you will likely be provided with a reporting email address.

A TXT record with the prefix _dmarc must be created for the domain for which DMARC is ultimately to be used. The Optimizely recommended entry is as follows:

Send a test email and check the email header to see if it authenticates using SPF, DKIM and DMARC. This is particularly easy to see in a Gmail header.

If your domain is abused to send spam emails, you will receive DMARC reports to your specified reporting email address. Ideally, this will allow you to draw conclusions about your current deliverability situation. At the same time, you learn how many potential spam emails were blocked and never reached any recipient.

The following tools can be used for analysis and visualization:

The use of these tools may cause costs. The application of DMARC itself is free of charge.

Optimizely recommends targeting the full application of the reject policy.

If you are unsure whether all your mail streams from your DMARC domain are already authenticated with SPF and DKIM, or whether you are sending further legitimate emails without authentication, you can work with a test phase and evaluate your reports first. If a phased introduction is planned, this can be implemented as follows:

You can find more information on DMARC.org.