DNS DMARC Record

DMARC (Domain-based Message Authentication, Reporting and Conformance)
is a technical specification created by a group of organisations aimed at reducing the abusive use of emails, such as spam and phishing, by offering a deployment and monitoring solution for issues related to email authentication and their content.

DMARC is a protocol for email authentication, messaging policy, and reporting to better secure the internet and communications. Setting up a DMARC record requires the prior implementation of SPF and DKIM records.

 

The DMARC record enables SPF and DKIM entries by stating a clear policy that must be used for both, and allows defining an address that can be used to send reports on the email statistics collected on the specific domain by recipients and receivers.

Creating a DMARC record for your domain ensures that legitimate emails authenticate correctly against established DKIM and SPF standards, and that fraudulent activities appearing to come from domains under a brand's control are properly blocked.

 

In practice, DMARC standardises how email recipients perform authentication of received messages using the mechanisms of SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail). This means that the sender of the message will receive the results of the authentication of their messages by various email services (Gmail, Hotmail, Yahoo!, etc.) and any other recipient implementing DMARC.

A DMARC authentication policy allows the sender to indicate that their emails are protected by SPF and/or DKIM, and specifies to the recipient what to do if these two authentication methods (SPF and DKIM) fail (e.g., reject all emails without DKIM and notify an email address). DMARC removes the assertions/assumptions that the recipient must make about how to handle these failing messages, limiting or eliminating the user's exposure to potentially fraudulent or dangerous messages. DMARC also provides a way for recipients to report back to the message sender whether it passed or failed the DMARC evaluation performed upon receipt.

 
Tips for setting up a DMARC record:
  • DMARC.org provides the necessary information to understand and create a DMARC record.
  • Set the policy (p=) to “p=none” to receive reports when first creating DMARC. If the policy is set to “p=reject” before analysing reports, the sender will likely encounter email delivery or receipt issues. Do not change your policy to “quarantine” or “reject” before gaining experience by understanding the effects on your email programme.
  • A guide to creating a DMARC policy can be found here.
 
 

DMARC and the email authentication process

DMARC is designed to integrate into an organisation’s existing incoming email authentication process. How it works is by helping email recipients determine if the purported message “matches” what the recipient knows about the sender and manages to authenticate the message. Otherwise, DMARC includes guidance on how to handle “non-aligned” messages. For example, assuming a receiver deploys SPF and DKIM, as well as their own anti-spam filters, the flow might look like this:

 

DMARC_author-to-recipient_flow.jpg

 

In the example above, the alignment test according to DMARC is applied at the same point where ADSP (Author Domain Signing Practices) would be applied in the flow. All other tests remain unchanged.

 

DMARC-flow.jpg

 

At a high level, DMARC is designed to meet the following requirements:

  • Minimise false positives.
  • Provide robust authentication reports.
  • Assert the sender’s policy to recipients.
  • Reduce successful phishing delivery.
  • Work at global Internet scale.
  • Minimise complexity.

It is important to note that DMARC relies on both the DomainKeys Identified Mail (DKIM) and Sender Policy Framework (SPF) specifications, which are currently under development within the IETF (Internet Engineering Task Force). DMARC is designed to replace ADSP (Author Domain Signing Practices) by adding support for:

  • Wildcard or subdomain rules,
  • Non-existent subdomains,
  • Gradual deployment (e.g., percentage experiments),
  • SPF record,
  • Quarantined mail.
 
 

Structure and format of a DMARC record in the DNS

DMARC policies are published in the DNS as text records (TXT type) and announce what the recipient of an email should do with non-aligned mail they receive.

Let’s take an example of a DMARC TXT record for the domain “sender.dmarcdomain.com” which reads as follows:

v=DMARC1;p=reject;pct=100;rua=mailto:postmaster@dmarcdomain.com

In the example above, the sender requests that the recipient outright rejects all non-aligned messages and sends a report, in a specified aggregation format, on the rejections to a specified address. If the sender were testing their setup, they might replace “reject” with “quarantine”, which would indicate to the recipient that they should not necessarily reject the message but consider quarantining it.
 

DMARC records follow the extensible “tag - value” syntax for DNS-based key records defined in DKIM. The following chart illustrates some of the available tags:

TAG NAME PURPOSE VALUE
v Protocol version v=DMARC1
PCT This DMARC tag specifies the percentage of emails subjected to filtering. For example, pct=25 means that a quarter of your organisation’s emails will be filtered by the recipient. pct=20
ruf This tag is optional. It directs the addresses to which message-specific forensic information should be reported. ruf=mailto: authfail@example.com
rua This optional tag is designed to report URI(s) for aggregated data. rua=mailto: aggrep@example.com
p The required p tag illustrates the domain policy (or requested handling policy). It asks the recipient to report, quarantine, or reject emails that fail authentication checks. Policy options are: 1) None 2) Quarantine or 3) Reject. p=quarantine
sp This tag represents the requested handling policy for subdomains. sp=reject
adkim The optional adkim tag is the alignment mode of the DKIM protocol. An example tag is adkim=r. adkim=s
aspf The aspf tag represents the alignment mode for SPF. An optional tag, aspf=r is a common example of its configuration. aspf=r

 

NOTE: The examples in this table are for illustration only and should not be used in place of the specification. Please refer to the specification page for the most recent and accurate version.

 
 

How senders deploy DMARC in 5 easy steps

DMARC was designed based on real-world experience by some of the world’s largest senders and receivers of email deploying SPF and DKIM. The specification recognises that it is almost impossible for an organisation to flip a switch in production. There are a number of built-in methods to “limit” DMARC processing so that all parties can facilitate full deployment over time.

  1. Deploy DKIM and SPF. You must first cover the basics.
  2. Ensure your senders correctly align the appropriate identifiers.
  3. Publish a DMARC record with the “none” flag set for policies, which requests data reports.
  4. Analyse the data and adjust your mail flows as needed.
  5. Change your DMARC policy flags from “none” to “quarantine” to “reject” as you gain experience.

Source:  https://dmarc.org/overview/

 

If you want to create a simple DMARC record without any policy:

v=DMARC1; p=none
 
This gives us the following record:

 
_dmarc.domain.com  33200 TXT   "v=DMARC1; p=none"

 

If you want to create a DMARC record as part of a defensive action on emails:

_dmarc.domain.com  33200 TXT   "v=DMARC1; p=reject; sp=reject; pct=100; adkim=s; aspf=s"


The values of the SPF and DKIM records to be associated:

domain.com 3600 TXT  "v=spf1 -all"
*._domainkey.domain.com 3600 TXT  "v=DKIM1; p="


The value of the MX record to be associated:

domain.com 3600 IN MX 0 .


More information on creating a defensive DNS zone.

 

 

DNS Configuration

Creating TXT-type DNS records for SPF, DKIM, and DMARC:
 

RECORD DOMAIN TYPE VALUE
SPF <DOMAIN> TXT « v=SPF1 a mx ip4:<EXTERNAL_IPv4> ip6:<EXTERNAL_IPv6> -all »
DKIM <TOKEN>._domainkey.<DOMAIN> TXT « v=DKIM1; k=rsa; p=<DKIM_PUBLIC_KEY> »
DMARC _dmarc.<DOMAIN> TXT « v=DMARC1; p=none »



 

Example with the domain example.com:
 

RECORD DOMAIN TYPE VALUE
SPF example.com TXT « v=SPF1 a mx ip4:XX.XXX.XX.XX ip6:XXXX:XXX:XXXX:XXXX:XXXX:XXXX:XXXX:XXXX -all »
DKIM default_domainkey.example.com TXT « v=DKIM1; k=rsa; p=MIGfMA0… »
DMARC _dmarc.example.com TXT « v=DMARC1; p=none »

 

 

DMARC is described in more detail in RFC 7489.


For more information, to create, deploy, and test your DMARC record, here are some useful links and online tools:

https://dmarc.org/

https://dmarc.org/resources/deployment-tools/

https://dmarc.org/resources/deployment-tools/

https://dmarcflow.com/en (Secure Your Domain with Powerful, AI Based DMARC Protection)

https://www.proofpoint.com/us/solutions/email-authentication-with-dmarc (Deploying DMARC is difficult. Proofpoint can help)

https://www.proofpoint.com/fr/threat-reference/dmarc

https://www.globalcyberalliance.org/dmarc/

https://www.globalcyberalliance.org/dmarc-implementation-guides/

https://www.dmarcanalyzer.com/dmarc/dmarc-record-check/

https://dmarcly.com/tools/dmarc-checker

https://www.kitterman.com/dmarc/assistant.html

https://dmarcian.com/

https://dmarcian.com/what-is-external-destination-verification/