At a high level, implementation of the Domain-based Message Authentication, Reporting and Conformance (DMARC) standard can be done simply and easily for outgoing mail by adding a text file to an organization’s DNS record. However, in practice, the messiness of modern organizations can complicate the process significantly and require an iterative approach to ensure no legitimate email senders suddenly become flagged as SPAM.
The basic steps are:
- Publish a DMARC record with the DNS provider
- Monitor DMARC reports to capture legitimate senders that fail DMARC
- Modify SPF, DKIM, and DMARC as necessary to ensure legitimate source pass
- Tighten DMARC restrictions
- Monitor DMARC reports for legitimate sources that fail and for potentially malicious sources attempting to impersonate the organization
Of course, these basic steps often require some additional details to execute, so this article will cover the following in more detail:
- How to Set up a DMARC Record
- DMARC Record Tags in Detail
- DMARC Testing and Implementation
- Bottom Line: Implement Effective DMARC Setup to Enjoy Benefits
For those that might need a refresher on DMARC, consider reading What Is DMARC? Definitions, Pros, Cons, and More first.
How to Set Up a DMARC Record
Creation of a DMARC record can be straightforward; however, it is a standard that is dependent on other email authentication standards. Setting up a DMARC record requires first establishing those dependent standards and then publishing the DMARC record.
Dependent Email Authentication Standards
DMARC depends upon the successful establishment of the Sender Policy Framework (SPF) and the DomainKeys Identified Mail (DKIM) authentication standards. It is possible to define a DMARC policy in a DNS record without first setting up SPF and DKIM, but it won’t be able to do anything. DMARC policies define how SPF and DKIM records should be handled by email servers.
It’s important to test configuration for SPF, DKIM and DMARC to make sure that the defined policies work as intended and don’t end up blocking legitimate email. Although covered in more detail below under DMARC Testing and Implementation, this testing explains why starting with relaxed and quarantine options is recommended.
Publish DMARC
To set up DMARC, an organization publishes a text file, called a DMARC record, with the organization’s DNS registrars. DMARC records may be published at no charge and the company can modify their text file as frequently as they want. The DMARC record is a simple one line entry and for many organizations, they will be able to publish a record by:
- Logging into their domain registrar
- Clicking on the option to manage or configure DNS settings
- Clicking the ‘Add a New Record’ option and choosing a ‘TXT’ record
- Copy-pasting the DMARC record text into the record field
In many host configurations, the domain name will automatically be added to the file name. If not, the record will need to be manually named:
- Syntax: _dmarc.<domain or subdomain>
- Subdomain Example: _dmarc.mailservers.ExampleDomain.com
- Domain Example: _dmarc.NonProfitHealthcareExample.org
Different DNS providers may have different requirements or procedures, so an organization should investigate their options carefully with their specific provider. DMARC policies can be established separately for subdomains, but a subdomain without a DMARC policy will inherit the parent domain’s DMARC policy.
Of course, while the DMARC record can be published easily and is only a text file, some will underestimate how easy it can be to make a mistake. To avoid issues, we need to understand the DMARC record tags in detail.
DMARC Record Tags in Detail
To understand the DMARC record, we start with an example record and then explore the detailed options for each tag.
v=DMARC1;p=none;rua=mailto:dmarc@dxampledomain.com;ruf=mailto:dmarc@exampledomain.com;rf=afrf;pct
=100Of these fields, only the first two, ‘v’ and ‘p,’ are required and must be listed first and in order. Other variables are optional, but most are recommended and can be in any order as long as ‘v’ comes first followed by ‘p.’
Tags are separated by semicolons ( ; ) with no extra spaces. When using the rua tag to email DMARC reports, one must add the mailto: prefix before each email address. While only the ‘v’ tag is case sensitive, best practice is to only use lowercase letters for all tags except for the ‘v’ tag.
v=DMARC1
The ‘v’ tag stands for the version identifier which will always read “DMARC1.” A receiving server looks for this when scanning the DNS record for the domain that sent the message. If the domain doesn’t contain a text record beginning with “v=DMARC1,” the receiving server won’t run a DMARC check. The ‘v’ tag is the only case-sensitive option and DMARC1 must be in all capital letters.
p=none
The ‘p’ tag stands for policy and instructs the participating recipient email server what to do with mail that doesn’t pass the SPF or DKIM tests and yet claims to be from your domain. In this case, the policy will be “none.”
The three policy options are:
- p=none: The most forgiving setting, ‘none’ instructs the receiving email server not to perform any actions against unqualified mail
- p=quarantine: This slightly more strict command tells the receiving email server to isolate unqualified mail, typically by sending them to the spam folder
- p=reject: The strictest setting, “reject” instructs the receiving email server to deny all unqualified mail intended for the domain; only mail verified as signed by your domain can attempt to reach the recipient’s inbox and all other mail gets discarded to mitigate any false positives.
Note that DMARC instructions may be ignored or modified by the receiving email server. For example, Microsoft Office 365 treats both reject and quarantine the same and delivers DMARC fail emails to the spam folder.
rua=mailto:dmarc@exampledomain.com
A critically important element of DMARC policy is that it also provides a reporting mechanism so domain administrators can identify if email is failing or if an attacker is attempting to spoof a given domain.
The “rua=mailto:” and the email address that follows the tag defines the email address to which aggregate reports of DMARC failures should be sent. These reports contain high-level information on DMARC failures without details.
ruf=mailto:dmarc@exampledomain.com
Similar to the other email tag, “ruf=mailto:” defines the email address to be used for detailed forensic reports on DMARC failures. These forensic reports contain extensive details concerning each failure and email receiving servers send these files in real time as they occur.
In our example, both “rua” and “ruf” use the same email address, but organizations have the flexibility to select different recipients. However, organizations should be aware that unlike with the “rua” tag, the “mailto:” email address for “ruf” must be from the domain the DMARC record that published it.
rf=afrf
The “rf” or reporting format defaults to “afrf” or “aggregate failure reporting format.”
pct=100
The “pct” or percentage variable tells the receiving email server what percent of incoming mail must conform to the DMARC policy’s specifications as a percentage value from 1–100. In our example, “pct=100” requires that 100% of all mail that fails the DMARC check gets rejected. However, if it had been set to 5%, then only 5% of failing mail would be rejected.
sp
This sp tag, for subdomain policy, declares whether the email receiving server should apply the DMARC policy to the organization’s subdomains.
aspf=r
The “aspf” or SPF Alignment tag defines if a MailFROM domain and the “From” in the header (also checked against SPF) must be exact matches or can be a parent/child match. Using “r” for the tag value means relaxed (or parent/child match permitted) and using “s” or a strict match requires an exact match.
For example:
| From Domain | SPF Domain | Relaxed Check | Strict Check |
|---|---|---|---|
| Example.org | Example.org | Pass | Pass |
| Example.org | Mail.Example.org | Pass | Fail |
| Mail.Example.org | Mail.Example.org | Pass | Pass |
| Mail.Example.org | Example.org | Pass | Fail |
| Example.Mail.org | Example.org | Fail | Fail |
adkim
The “adkim” or DKIM Alignment tag can be either “s” for strict or “r” for relaxed. The strict setting ensures DKIM will only pass if the “d=” field in the signature matches the “from” domain exactly. The relaxed setting will pass DKIM in all cases where the “d=” field matches the root domain of the “from” address.
fo
The “fo” or failure reporting option defaults to ‘0;’ however, an organization can manually select one of the following options:
- 0 = DMARC failure or forensic report is sent if the email fails both SPF and DKIM alignment
- 1 = a DMARC failure or forensic report is sent if the email fails either SPF or DKIM alignment
- d = a DKIM failure report is sent if the email fails DKIM validation (whether aligned or not aligned)
- s = a SPF failure report is sent if the email fails SPF validation (whether aligned or not aligned)
ri
The “ri” tag defaults to ‘86400’ and defines the time interval between two consecutive aggregate reports.
DMARC Testing and Implementation
Publishing the DMARC record establishes DMARC for a given domain. However, simply setting up DMARC is only the beginning of the DMARC journey. An organization must test the records for accuracy, monitor for unexpected results, fix issues, and escalate the DMARC settings to start blocking unauthorized emails.
Note: DNS can take some time to propagate, so some of this testing should take place several days after the DNS update.
SPF, DKIM, and DMARC Testing
A Google Search for SPF testing, DKIM testing, and DMARC testing will provide a list of sources for online tools that can provide checks for formatting issues and improper variable usage. These tests should be performed first to catch the easy errors.
However, these tests cannot catch typographical errors for domains, email addresses, or IP addresses. Instead, the organization will need to send test emails to check for these types of issues. For more detailed insight into troubleshooting and common errors, read Why DMARC is Failing: 3 Critical Issues with DMARC Deployment.
DMARC Monitoring
When initially setting up DMARC, an organization should set ‘p=none’ and observe the reports for unexpected results. For example, an organization may discover a third-party mailing service or unexpected mail server sending emails that had been overlooked in SPF or DKIM setup. Additionally, while the organization can often identify most marketing providers, support systems, inbox services, and drip email services in advance, other regularly overlooked sources of email include alerts from servers and administrative tools.
Typical organizations take several weeks to several months to monitor the DMARC results and update SPF and DKIM with additional email servers.
Convert Known Email Sources to Align DMARK, DKIM and SPF
As new email sources are identified, the IT team will need to add those sources to DKIM and SPF files to ensure alignment for DMARC. Identifying each source can be tricky. One way to make this easier is to create a list of each source in the organization known to send emails.
As new sources come in the reports, the organization can try to match them to the known sources such as email providers, ecommerce systems, and marketing services. Common examples include Google Apps (Gmail), Salesforce, Intercom, Campaign Monitor, Mailchimp, and Microsoft 365.
Reports can be difficult to understand without using third-party tools that help organize and highlight important data. For example, some report analyzers add helpful information such as resolving the source IP address for email servers to show the location and owner of the IP address. This information can be critical to determining the legitimacy of the email source.
Services like Zendesk, Campaign Monitor, Google Apps, and Rackspace have articles on what SPF or DKIM records to add to your DNS. In some cases, the difficulty of managing inhouse server requirements may lead some organizations to migrate email to a service that can also manage the DKIM and SPF setup.
Some failing source domains/IPs that won’t make sense. Often, these will consist of legitimate messages forwarded by users that filed to preserve SPF and DKIM headers. Minor email sources with fewer than 10 emails sent in a given time period can generally be ignored.
Escalate DMARC Policy Tags
After adding all of the email sources captured by monitoring to SPF and DKIM, the organization needs to escalate the policy tag to “quarantine” or “reject.” Until this final adjustment is made, spoofers and spammers trying to impersonate the organization’s brand will not be stopped.
Bottom Line: Implement Effective DMARC Setup to Enjoy Benefits
Implementing an effective DMARC policy can improve email marketing campaign delivery by 5–10%, improve domain reputation, and dramatically reduce spam and spoofing emails attempting to impersonate an organization’s brand. These powerful benefits only can be enjoyed when an organization properly sets up their DMARC record, but they’re worth the investment in time and effort.
This article was originally written and published by Sean Michael Kerner on January 24, 2018 and updated by Chad Kime on June 1, 2023.
