RFC 7489: The DMARC Specification Explained in Plain English

If you have ever dug deep enough into DMARC documentation, you have probably seen references to "RFC 7489." It is the official specification that defines how DMARC works — published by the Internet Engineering Task Force (IETF) in March 2015. The document is thorough, precise, and written for protocol engineers. Which means it is also dense and difficult to read if you are not one.

This guide translates the key parts of RFC 7489 into plain English. You will understand what the specification covers, what it says about policy and alignment, what it intentionally leaves out, and what has changed since it was published.

What Is RFC 7489?

RFC stands for "Request for Comments," which is the standard format used by the IETF to publish internet specifications. Despite the modest name, RFCs are the official standards that define how the internet works. HTTP, DNS, SMTP, and TLS are all defined in RFCs.

RFC 7489, titled "Domain-based Message Authentication, Reporting, and Conformance (DMARC)," was published in March 2015 as an "Informational" RFC. This means it was not published on the formal Standards Track but was widely adopted anyway. DMARC was already in use by major providers like Google, Yahoo, and Microsoft before the RFC was finalized — the specification documented an existing practice rather than proposing a new one.

The document is 73 pages long. Most of it describes protocol mechanics, edge cases, and interoperability considerations. The sections below cover the parts that matter most for understanding how DMARC works in practice.

The Purpose of DMARC (Section 1)

The specification opens by describing the problem DMARC solves. Before DMARC, SPF and DKIM could authenticate email, but there was no standard way for domain owners to:

• Publish a policy about what to do when authentication fails
• Receive feedback about how their domain was being used (or abused) for email
• Signal to receivers that SPF and DKIM were deliberately configured and should be trusted

DMARC fills all three gaps. It gives domain owners a way to declare policy, receive reports, and build a trust relationship with receiving mail servers — all through a single DNS TXT record.

The specification explicitly notes that DMARC is designed to be deployed incrementally. Domain owners can start with monitoring (p=none) and move toward enforcement at their own pace. This incremental approach is baked into the protocol's design, not just a best practice layered on top.

Key Terminology (Section 3)

The specification defines several terms that are used throughout DMARC documentation. Here are the most important ones in plain language.

Organizational Domain. This is your registered domain — the part you bought from a registrar. For mail.shop.example.com, the organizational domain is example.com. DMARC policies are published at the organizational domain level and can apply to all subdomains.

Identifier Alignment. This is DMARC's core concept. It means that the domain used in SPF or DKIM authentication must match (or be related to) the domain in the "From" header that the recipient sees. Alignment is what prevents an attacker from authenticating with their own domain while spoofing yours in the "From" address.

Relaxed vs Strict Alignment. The specification defines two alignment modes. Relaxed alignment requires the authenticated domain and the "From" domain to share the same organizational domain — so mail.example.com aligns with example.com. Strict alignment requires an exact match. Relaxed is the default and what most domains use.

Aggregate Reports. XML-formatted reports sent by mail receivers to the domain owner's rua address. They contain authentication results for messages using the domain, grouped by source IP and result.

Failure Reports. More detailed reports about individual messages that failed DMARC, sent to the ruf address. These are less commonly supported due to privacy concerns.

Policy Discovery (Section 6.6)

When a receiving mail server gets a message, it needs to find the sender's DMARC policy. The specification defines a precise lookup process.

First, the receiver extracts the domain from the "From" header. It then performs a DNS TXT query for _dmarc. followed by that domain. For example, if the "From" address is user@shop.example.com, the receiver queries _dmarc.shop.example.com.

If no record is found at the subdomain, the receiver falls back to the organizational domain and queries _dmarc.example.com. This fallback is what allows a single DMARC record on your main domain to cover all subdomains automatically.

The specification requires that only one DMARC record exist at any given domain. If multiple records are found, the result is undefined — which in practice means receivers may ignore your policy entirely. This is a common misconfiguration and why you should check your DMARC record after making changes.

Authentication Mechanisms (Section 4)

The specification describes how DMARC evaluates authentication results from SPF and DKIM.

For SPF, DMARC checks whether the SPF evaluation returned a "pass" result and whether the domain used in the SPF check (the RFC5321.MailFrom domain, also known as the Return-Path or envelope sender) aligns with the "From" domain.

For DKIM, DMARC checks whether a valid DKIM signature exists and whether the signing domain (the d= value in the DKIM signature) aligns with the "From" domain.

A message passes DMARC if at least one of SPF or DKIM passes with alignment. Both do not need to succeed. This "or" logic is intentional — it gives messages two independent paths to authentication, which provides resilience when one mechanism fails (such as SPF failing during email forwarding). For a practical comparison of how these protocols differ, see SPF vs DKIM vs DMARC.

The DMARC Record Tags (Section 6.3)

The specification defines the tags that make up a DMARC record. Here is what each one means.

For a detailed walkthrough of each tag and how to use it, see our DMARC record syntax guide.

Reporting (Sections 7.1 and 7.2)

The reporting mechanism is one of DMARC's most valuable features, and the specification devotes significant attention to it.

Aggregate reports are the primary feedback mechanism. Mail receivers send periodic XML reports to the address specified in the rua tag. These reports contain counts of messages received, grouped by sending source (IP address), authentication results (SPF and DKIM pass/fail), alignment results, and the policy that was applied.

Aggregate reports are designed to be processed by machines, not read by humans. The raw XML is structured but not friendly. This is why most organizations use a tool to parse and visualize their DMARC reports — reading them manually is possible but tedious. Our guide on how to read DMARC reports helps you make sense of the data.

Failure reports (also called forensic reports) provide details about individual messages that failed DMARC. They are sent to the ruf address and can include redacted copies of the message headers. However, many mail providers do not send failure reports due to privacy and volume concerns. The specification acknowledges this limitation and treats failure reports as optional.

What the Specification Does Not Cover

RFC 7489 is specifically about DMARC. Several related standards are defined in their own separate specifications.

BIMI (Brand Indicators for Message Identification) is not part of RFC 7489. BIMI builds on DMARC enforcement but is defined in its own specification. It requires DMARC at p=quarantine or p=reject as a prerequisite but is a separate protocol with its own DNS records and requirements. See our DMARC and BIMI guide.

ARC (Authenticated Received Chain) is defined in RFC 8617. It addresses the forwarding problem where SPF breaks when messages are relayed through intermediary servers. ARC allows intermediaries to preserve original authentication results. See our DMARC and ARC guide.

SPF is defined in RFC 7208, and DKIM is defined in RFC 6376. DMARC depends on both but does not redefine them.

Updates Since 2015

The original RFC 7489 was published as an Informational document. Since then, the IETF has been working on updates through the DMARC working group. Key developments include discussions around moving DMARC to the Standards Track (giving it more formal status), refining the handling of pct tag behavior and how policies interact with subdomain inheritance, clarifying alignment rules for complex multi-domain setups, and addressing the interplay between DMARC and mailing lists, which remain a source of authentication friction.

The core protocol remains the same. The tags, the policy levels, the alignment model, and the reporting mechanisms described in RFC 7489 are what every mail provider implements today. Any updates build on this foundation rather than replacing it.

Why This Matters for Your DMARC Setup

Understanding the specification helps you make better configuration decisions. For example, knowing that alignment defaults to "relaxed" means you do not need to set adkim or aspf unless you specifically want strict matching. Knowing that pct defaults to 100 means omitting it applies your policy to all messages. Knowing that subdomain policy falls back to the parent domain's p value means you only need an sp tag if you want subdomains treated differently.

You do not need to memorize the RFC. But having a working understanding of what it says helps you configure DMARC with confidence and troubleshoot issues when they arise. Those running self-hosted email servers benefit most from understanding the specification, since they are implementing both the sending and receiving sides of the protocol.

If you want to read the full specification yourself, it is available at datatracker.ietf.org/doc/html/rfc7489.

Monitor Your Email Authentication

You've set up your email authentication — now make sure it keeps working. The Email Deliverability Suite watches your SPF, DKIM, DMARC, and MX records daily and alerts you when something breaks.