DMARC (Domain-based Message Authentication, Reporting, and Conformance)

• Table of Contents
• Introduction
• What DMARC Does
• What DMARC Does NOT Do
• A Quick Primer on SPF and DKIM
• Other Terminology to Know
• DMARC Basics
• The DMARC DNS Record
• DMARC Handling Policy Choices
• DIY or Hire Someone?

Introduction

DMARC is an email authentication mechanism that relies on the email authentication protocols SPF (Sender Policy Framework) and DKIM (DomainKeys Identified Mail) to ensure the use of the RFC5322.From domain (also sometimes called the “Friendly From” domain) in an email message has been authorized by the domain’s owner.

DMARC is increasingly moving from optional to must-have for domains sending at scale, as larger mailbox providers are putting policies in place which require a domain participate in DMARC in order to have its mail considered for acceptance and delivery.

This article will briefly discuss DMARC’s key concepts and general steps for setup, but it is not meant to be a how-to guide.

What DMARC Does

DMARC is designed to do three things:

• Protect against unauthorized usage (e.g., spoofing) of the RFC5322.From domain in an email message
• Allow a domain owner to request reports from mailbox providers about a domain’s usage as the RFC5322.From domain in email messages
• Allow a domain owner to request specific treatment for email messages which use the domain as the RFC5322.From domain and do not pass DMARC authentication checks.

What DMARC Does NOT Do

While DMARC is a powerful tool against spoofing, it is important to understand what DMARC cannot do, including:

• DMARC validation does not, by itself, mean a given message is not spam. It only means the RFC5322.From domain’s use in that message was authorized by the domain owner.
• DMARC does not guard against abuse using “lookalike” domains. If the domain “example.com” is configured for DMARC, that will not stop attempted abuse by actors using an RFC5322.From domain like “ex4mple.com”

• DMARC does not prevent “display name” attacks, where the “Friendly From” is intended to fool the recipient, such as in this example:

  From: “Your Bank” <[email protected]>

A Quick Primer on SPF and DKIM

SPF is what’s known as a path-based authentication protocol. A domain owner publishes a DNS record that announces which servers and networks are authorized to use its domain as the RFC5321.MailFrom domain of an email message, also sometimes called the “Envelope From”. This domain appears in the Return-Path header of the message, and is not typically seen by the email recipient, but is instead used by the servers that exchange email messages on the internet.

DKIM, on the other hand, is what’s known as a content-based authentication protocol. A domain takes responsibility for a message by inserting a header (the DKIM-Signature header) containing two cryptographic hashes of the message, along with enough other information to allow the receiving site to validate the hashes. This process is known as “DKIM-signing the message”, and the information in the header includes the domain that signed the message, a.k.a., the “DKIM d= domain”. If the hashes can be validated by the receiving site, then the site can be assured the parts of the message that were used in signing the message were not altered in transit after the message was DKIM-signed.

Other Terminology to Know

DMARC introduces two important concepts to email authentication:

• The “Organizational Domain”, which is the term for the domain that a company, brand, or other entity registers to establish an internet presence. “greenarrowemail.com” is our Organizational Domain, and “example.com” is one we’ll use throughout this document.
• “Domain Alignment”, which is the term for two domains having the same Organizational Domain. “billing.example.com” and “sales.example.com” are “in alignment”, as are “billing.example.com” and “example.com”. However, “sales.example.com” and “example.net” are not “in alignment”; even though they might appear to belong to the same organization, they do not have the same Organizational Domain.

DMARC Basics

A message passes DMARC validation checks under the following conditions:

• There is a DMARC record in DNS for the RFC5322.From domain of the email message, the message passes DKIM checks, and the DKIM d= domain on a passing signature and the RFC5322.From domain are in alignment, OR
• There is a DMARC record in DNS for the RFC5322.From domain of the email message, the message passes SPF checks, and the RFC5321.MailFrom domain and the RFC5322.From domain are in alignment.

DMARC does not require both DKIM and SPF to pass and to be in alignment, only that one of the two does; that said, it’s best practice for domains to try to achieve an aligned pass with both protocols. For those domains choosing to only pursue an aligned pass with one protocol, mailbox providers are increasingly favoring DKIM over SPF, not only to support DMARC but also for enrollment in feedback loops and other services they make available to senders.

The DMARC DNS Record

A domain participates in DMARC by publishing a specially formatted record of type “TXT” in the DNS. The definition of a DMARC record can be found in the DMARC specification and it can contain a number of “key-value” pairs, each separated by semi-colons, but there are only three that are either required or at the least STRONGLY RECOMMENDED.

Those three keys are:

v=	The version of DMARC. At present, there is only one valid value (DMARC1). This key-value pair must be first in the record (“v=DMARC1;”)
p=	The requested handling policy for messages that fail DMARC. Possible values are “none” (meaning don’t let the DMARC failure affect the handling decision), “quarantine” (meaning route the message to the spam folder), and “reject” (meaning do not accept the message). Unless the domain in question is brand new, or the domain is not used for email, the first DMARC record for a domain should always have “p=none;” as the requested handling policy, and the domain owner can make changes later as appropriate.
rua=	A mailbox to which mailbox providers should send DMARC aggregate reports, e.g., “rua=mailto:[email protected]”. DMARC aggregate reports are usually generated once per day by mailbox providers that perform DMARC validation checks. They contain statistical data about observed usage of a domain as the RFC5322.From domain in email messages, and this data is grouped by source IP address, validation results, and other criteria. DMARC aggregate reports are XML documents, and are meant to be machine-parsed, rather than read by a human, so best practice dictates having a dedicated mailbox for receiving them.

DMARC Handling Policy Choices

As mentioned above, starting with “p=none” is the right choice in most circumstances. However, domain owners who want to best protect their domain from spoofing and/or someday participate in BIMI will want to eventually migrate from “p=none” to “p=quarantine” or “p=reject” (both of these latter states are known as “Enforcement”) as their requested handling policy to ensure that messages making unauthorized use of their domain don’t end up in recipients’ inboxes.

The decision on when to move to Enforcement should be based on the data shown in the DMARC aggregate reports. These reports will tell the domain owner whether or not all authorized sources of email for their domain are properly authenticating with DKIM and/or SPF, and when they are, that will be the time to move to the stricter Enforcement policy.

DIY or Hire Someone?

While it’s possible for a technically-savvy domain owner to do all the work required to adopt DMARC, it can be easier to engage the services of a third party. This website contains a host of DMARC resources, including not only DMARC service providers but also educational material to help you better understand DMARC.