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 sender 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 Stands for "internet service provider" (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.

Functionality and requirements

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 record

DMARC can generally be set up for the entire organizational domain or specifically for a subdomain used for email sending. Ideally, DMARC is set for the organizational 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 sender domain.

The DMARC record is inherited by the subdomains belonging to the DMARC domain. If it is set on the organizational 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:

Example domain. example.com
DMARC domain. _dmarc.example.com
Record type. TXT
DMARC record. v=DMARC1; p=reject; rua=mailto:[email protected];

DMARC policies

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.

p=reject. Instructs the receiver to reject an email that cannot authenticate with SPF and DKIM.
p=quarantine. Instructs the receiver to deliver an email to the spam folder that cannot authenticate with SPF and DKIM.
p=none. Instructs the receiver not to apply any special policy to an email that cannot authenticate with SPF and DKIM.

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.

DMARC tags

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

—Table: DMARC tags—

Tag	Definition	Recommendation
v	Version	The version must be set with v=DMARC1.
p	Policy	The DMARC policy must also be set. Optimizely recommends setting the strongest policy p=reject to reject spam emails from your domain.
sp	Subdomain Policy	If another DMARC policy is to apply to your subdomains, this can be specified with the sp tag, such as sp=quarantine. This setting is optional.
rua	Aggregate Report	Optimizely recommends specifying a reporting address for receiving aggregated DMARC reports, such as rua=mailto:[email protected].
ruf	(Forensic) Failure Report	Optimizely recommends not using forensic reports. They contain email addresses of spam recipients and are therefore possibly not GDPR-compliant.
adkim	DKIM Alignment	No separate tag is necessary, so the default setting applies: adkim=r (Relaxed).
aspf	SPF Alignment	No separate tag is necessary, so the default setting applies: aspf=r (Relaxed).
rf	Reporting Format	No separate tag is necessary, so the default setting applies: rf=afrf.
ri	Report Interval	No separate tag is necessary, so the default setting applies: ri=86400 (1 Tag).
pct	Percentage	No separate tag is necessary, so the default setting applies: pct=100.
fo	Failure Reporting Options	No separate tag is necessary, so the default setting applies: fo=0. The following options generally exist: fo=0. A report should be sent if the SPF and DKIM check fail at the same time. fo=1. A report should be sent if either the SPF or the DKIM check fails. fo=d. A report should be sent if only the DKIM check fails. fo=s. A report should be sent if only the SPF check fails.

DMARC Identifier Alignment

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 sender domain.

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

Relaxed SPF Alignment. The technical and the visible domain have the same organizational domain.
Strict SPF Alignment. The technical and the visible domain have the same subdomain.

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 sender domain and meet one of the two variants:

Relaxed DKIM Alignment. The DKIM domain and the visible domain have the same organizational domain.
Strict DKIM Alignment. The DKIM domain and the visible domain have the same subdomain.

DMARC Identifier Alignment is set up by default with Optimizely Campaign.

DMARC reporting

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.

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.

Implementing DMARC

To implement DMARC, perform the following steps:

Selecting the domain
Checking the domain
Selecting an email address
Setting up the DMARC record
Analyzing the results

Selecting the domain

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

set DMARC on a domain that is solely used for sending with Optimizely. This is usually a subdomain.
set DMARC on your organizational domain. This may or may not be the sending domain set up at Optimizely.

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 organizational domain to protect the entire domain and brand.

DMARC is inherited on all subdomains of the DMARC domain.

Checking the domain

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:

Send test emails and check in the email header whether your sending domain corresponds to the returnpath domain or the DKIM domain, listed under the d= header, at least at the level of the organizational domain.
Check in the email header whether your email authenticates with SPF and DKIM. If you cannot find a warning about an incorrect DNS setup in your Campaign account, the emails are most likely correctly authenticated.

For the implementation of DMARC on the organizational domain, other mail streams such as emails via your own infrastructure or other email service providers must be taken into account and domain alignment, SPF and DKIM must be implemented correctly for all of them. Otherwise DMARC can lead to unwanted blocking of these emails.

Selecting an email address

To receive DMARC reports, you need to set an email address. The reporting address should be based on the same organizational 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 want to use an official tool for DMARC analysis, you will likely be provided with a reporting email address.

Setting up the DMARC record

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:

Example domain. example.com
DMARC domain. _dmarc.example.com
Record type. TXT
DMARC record. v=DMARC1; p=reject; rua=mailto:[email protected];

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.

Analyzing the results

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.

Options for gradual implementation

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:

Policy level. Start with a none policy so DMARC will not affect sending. Once you have verified that the functionality works as intended, change the policy tag to quarantine and finally to reject.
Percentage level. Implement the reject policy but apply DMARC to a limited percentage of the sending volume, such as 10%. The percentage can be slowly increased over time.

You can find more information on DMARC.org.