emailmarketing.net

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

What DMARC does and doesn't do, how it builds on SPF and DKIM, domain alignment, the DNS record, and choosing a handling policy.

Operationalesp-operatorsender

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 that the use of the RFC5322.From domain (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: large mailbox providers (notably Google and Yahoo) have put policies in place requiring bulk-sending domains to participate in DMARC in order to have their mail considered for acceptance and delivery.

This article covers DMARC's key concepts and general setup steps; it is not a full how-to guide.

Standard status

DMARC was first defined in RFC 7489 (2015, Informational). As of May 2026 it is a published Proposed Standard, "DMARCbis," split across RFC 9989 (core protocol), RFC 9990 (aggregate reporting), and RFC 9991 (failure reporting), which together obsolete RFC 7489 (and RFC 9091). Everything in this plain-language introduction still holds; the handful of RFC 7489-era details that changed are flagged below. For the record-tag registry and the DNS Tree Walk that replaces the Public Suffix List, see the DMARC standard reference; for the operational rollout in depth (subdomain policy, the new np/t tags, report processing) see DMARC deployment in depth.

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 the domain's usage as the RFC5322.From domain in email messages
  • Allow a domain owner to request specific treatment for messages that use the domain as the RFC5322.From domain and fail DMARC authentication checks

What DMARC does NOT do

  • DMARC validation does not, by itself, mean a 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 lookalike domains. If "example.com" is configured for DMARC, that does not stop abuse using an RFC5322.From domain like "ex4mple.com".

  • DMARC does not prevent display-name attacks, where the "Friendly From" display name is meant to fool the recipient:

    From: "Your Bank" <attacker@some-unrelated-domain.example>

A quick primer on SPF and DKIM

SPF is a path-based authentication protocol. A domain owner publishes a DNS record announcing which servers and networks are authorized to use its domain as the RFC5321.MailFrom domain of a message (also called the "Envelope From"). This domain appears in the Return-Path header, is not typically seen by the recipient, and is used by the servers that exchange email on the internet.

DKIM is a content-based authentication protocol. A domain takes responsibility for a message by inserting a DKIM-Signature header containing two cryptographic hashes of the message, plus enough information for the receiving site to validate them. This is "DKIM-signing the message," and the header includes the signing domain — the "DKIM d= domain." If the hashes validate, the receiver is assured that the signed parts of the message were not altered in transit after signing.

Other terminology to know

DMARC introduces two important concepts:

  • Organizational Domain — the domain a company, brand, or other entity registers to establish an internet presence (e.g., "example.com").
  • Domain Alignment — 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". But "sales.example.com" and "example.net" are not in alignment, even if they appear to belong to the same organization.

DMARC basics

A message passes DMARC validation under either of these conditions:

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

DMARC does not require both DKIM and SPF to pass with alignment — one of the two suffices. That said, best practice is to achieve an aligned pass with both protocols. If pursuing only one, note that mailbox providers increasingly favor DKIM over SPF — both for DMARC and for enrollment in feedback loops and other sender services.

The DMARC DNS record

A domain participates in DMARC by publishing a specially formatted TXT record in DNS (originally defined in RFC 7489, now the standards-track RFC 9989). The record contains semicolon-separated key-value pairs; three are required or strongly recommended:

Key Meaning
v= The DMARC version. Currently only one valid value (DMARC1). Must be the first pair in the record: v=DMARC1;
p= The requested handling policy for messages that fail DMARC: none (don't let the DMARC failure affect handling), quarantine (route to the spam folder), or reject (do not accept the message). Unless the domain is brand new or not used for email, the first DMARC record for a domain should always be p=none; — tighten later as appropriate.
rua= A mailbox to receive DMARC aggregate reports, e.g. rua=mailto:dmarc-reports@example.com. Aggregate reports are usually generated daily by providers performing DMARC checks. They contain statistical data on observed usage of the domain as the RFC5322.From domain, grouped by source IP, validation results, and other criteria. They are XML documents meant to be machine-parsed, so use a dedicated mailbox for them.

DMARC handling policy choices

Starting with p=none is the right choice in most circumstances. However, domain owners who want the best spoofing protection — and/or who want to participate in BIMI someday — will eventually migrate to p=quarantine or p=reject (both known as Enforcement), so that messages making unauthorized use of the domain don't reach recipients' inboxes.

Base the decision on when to move to Enforcement on the aggregate report data: the reports show whether all authorized email sources for the domain are properly authenticating with DKIM and/or SPF. When they are, that's the time to tighten the policy.

DIY or hire someone?

A technically savvy domain owner can do all the work required to adopt DMARC, but engaging a third party can be easier. dmarcvendors.com lists DMARC service providers and educational material.

Related

#authentication#dmarc#spf#dkim#dns#spoofing#alignment#bimi

Sources