DMARC Technical Reference (RFC 7489)

What This Reference Covers

RFC 7489 defines DMARC — Domain-based Message Authentication, Reporting, and Conformance. DMARC ties together SPF and DKIM into a unified policy framework: it tells receiving servers what to do when a message fails both SPF and DKIM alignment, and it gives domain owners visibility into who is sending email as their domain.

This page walks through the sections most relevant to email administrators configuring, auditing, or troubleshooting DMARC. Use the mxio DMARC Checker to verify your record is correctly published.

DMARC Overview (§3)

DMARC operates on a simple principle: the domain in the From: header is the identity being protected. SPF and DKIM each authenticate different identifiers (envelope sender and signing domain, respectively). DMARC checks whether either of those identifiers aligns with the From: domain.

"DMARC allows Domain Owners and receivers to collaborate by expressing domain-level messaging authentication policy, providing feedback about message authentication to the Domain Owner." — RFC 7489 §2

The DMARC Evaluation Flow

1. Receiving server gets a message and checks the From: domain
2. Queries DNS for _dmarc.{from-domain} TXT record
3. Evaluates SPF — does the envelope sender domain align with the From: domain?
4. Evaluates DKIM — does any valid DKIM signature's d= domain align with the From: domain?
5. If either passes with alignment, DMARC passes
6. If both fail, applies the domain's DMARC policy (p= tag)
7. Sends aggregate report to the rua= address (if configured)

The critical word is "either." DMARC passes if SPF passes with alignment or DKIM passes with alignment. Both do not need to pass — one aligned authentication is sufficient.

Record Tags (§6.2)

A DMARC record is a DNS TXT record at _dmarc.{domain} with semicolon-delimited tags:

Example

_dmarc.example.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

This record says: reject messages that fail both SPF and DKIM alignment, and send daily aggregate reports to dmarc@example.com.

Policy (§6.3)

The p= tag defines what receiving servers should do with messages that fail DMARC:

"Policy applies to the domain queried and to subdomains, unless subdomain policy is explicitly described using the 'sp' tag." — RFC 7489 §6.3

If you are still at p=none, see DMARC Policy Set to None for the deployment path to enforcement. For the full phased approach, see the DMARC Deployment Guide.

The pct= Tag

The pct= tag applies the policy to a percentage of failing messages. Setting pct=25 means 25% of messages that fail DMARC get the p= policy applied; the remaining 75% are treated as p=none.

This is useful for gradual rollout: move from p=none to p=quarantine; pct=10, then increase the percentage as you confirm no legitimate senders are affected.

"The 'pct' tag controls the percentage of messages to which the DMARC mechanism is applied." — RFC 7489 §6.3

The DMARC Checker flags pct values below 100 as a warning — they indicate an incomplete deployment.

Subdomain Policy (sp=)

The sp= tag sets a separate policy for subdomains. If omitted, subdomains inherit the p= policy. Common pattern:

v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc@example.com

This ensures subdomains like mail.example.com or app.example.com are also protected. Without sp=reject, an attacker could spoof anything.example.com even if the root domain rejects.

Alignment (§4.2)

Alignment is the mechanism that connects SPF and DKIM to the From: domain. Without alignment, an attacker could pass SPF with their own domain in the envelope sender while spoofing your domain in the From: header.

SPF Alignment

SPF alignment compares the domain in the MAIL FROM (envelope sender) to the domain in the From: header.

• Relaxed (aspf=r): Organizational domains must match. bounce.example.com aligns with example.com.
• Strict (aspf=s): Exact domain match required. bounce.example.com does not align with example.com.

DKIM Alignment

DKIM alignment compares the d= domain in a valid DKIM signature to the domain in the From: header.

• Relaxed (adkim=r): Organizational domains must match. A signature with d=mail.example.com aligns with From: user@example.com.
• Strict (adkim=s): Exact domain match required.

Relaxed vs. Strict

"In relaxed mode, the Organizational Domains of both the DKIM-authenticated identifier and the RFC5322.From domain must be equal." — RFC 7489 §3.1.1

Relaxed mode is the default and is recommended for most domains. Strict mode is appropriate only when you need to prevent subdomain-level spoofing and you are certain all your senders sign with the exact From: domain.

If DMARC is failing due to alignment issues, see DMARC Alignment Failure for diagnosis and fixes.

Aggregate Reporting (§7)

The rua= tag configures daily aggregate reports — XML files that summarize DMARC results for all messages claiming to be from your domain. These reports are the foundation of DMARC deployment: they show you who is sending as your domain, whether they pass SPF/DKIM, and whether alignment succeeds.

What Aggregate Reports Contain

Each report includes:

• Reporting organization — who generated the report (e.g., Google, Microsoft, Yahoo)
• Date range — the reporting period
• Domain policy — your published DMARC record at the time
• Per-source-IP records — for each sending IP:
  • Message count
  • SPF result and alignment
  • DKIM result and alignment
  • DMARC disposition (none, quarantine, reject)

Report Format

Reports follow the XML schema defined in RFC 7489 Appendix C. They are typically delivered as gzip-compressed XML attachments.

<record>
  <row>
    <source_ip>203.0.113.1</source_ip>
    <count>42</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim>
      <spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers>
    <header_from>example.com</header_from>
  </identifiers>
  <auth_results>
    <dkim>
      <domain>example.com</domain>
      <result>pass</result>
      <selector>selector1</selector>
    </dkim>
    <spf>
      <domain>bounce.example.com</domain>
      <result>pass</result>
    </spf>
  </auth_results>
</record>

This record shows 42 messages from IP 203.0.113.1: DKIM passed and aligned, SPF passed but the domain (bounce.example.com) differed from the From: domain. DMARC passed because DKIM alignment succeeded.

External Report Verification (§6.6.1)

When your rua= address is at a different domain than the domain being monitored, receivers must verify that the report destination has opted in to receiving those reports. This prevents abuse — without verification, an attacker could publish rua=mailto:victim@otherdomain.com to flood a third party with reports.

"If the set of URIs is not empty, the Mail Receiver SHOULD attempt to retrieve a DMARC record from the DNS for the domain within the URI." — RFC 7489 §7.1

How It Works

If your domain is example.com and your rua= points to mailto:dmarc@reports.com, the receiver checks for a TXT record at:

example.com._report._dmarc.reports.com

That record must contain v=DMARC1 to confirm that reports.com consents to receiving DMARC reports for example.com.

This is one of the most commonly missed DMARC configurations. If you use a third-party DMARC reporting service, they typically handle this DNS record for you. If you are sending reports to a different domain you control, you must publish the authorization record yourself.

Forensic Reports (§6.5)

The ruf= tag requests forensic (failure) reports — individual message-level reports sent when DMARC fails. Unlike aggregate reports (daily summaries), forensic reports are generated per-message and can include message headers or even full message content.

Privacy Concerns

Forensic reports raise significant privacy concerns:

"Forensic reports can contain message header data, which may include personally identifiable information (PII)." — RFC 7489 §7.2

In practice, most large receivers (Gmail, Microsoft, Yahoo) do not send forensic reports, or send heavily redacted versions. Do not rely on forensic reports for DMARC monitoring — aggregate reports are the reliable data source.

The fo= Tag

The fo= tag controls when forensic reports are generated:

Security Considerations (§10)

DMARC Does Not Prevent All Spoofing

DMARC protects the From: header domain. It does not protect:

• Display names — An attacker can set From: "Your CEO" <attacker@evil.com>. The display name says "Your CEO" but the domain is not yours. DMARC does not check display names.
• Look-alike domains — examp1e.com (with a numeral 1) is a different domain. DMARC for example.com has no authority over it.
• Cousin domains — example-support.com is outside your DMARC policy.

DMARC Breaks Mailing Lists

Mailing lists that modify messages (adding footers, changing Subject lines) break DKIM signatures. If the list also does not rewrite the From: header, SPF alignment fails too (the list server's IP is not in the original domain's SPF). Result: DMARC fails.

"Use of DMARC is incompatible with some existing mail practices, particularly mailing lists." — RFC 7489 §10.2

ARC (RFC 8617) was developed to address this problem by preserving authentication results across intermediaries. Many large receivers now support ARC as a DMARC override for trusted intermediaries.

The Organizational Domain Problem

DMARC uses the "organizational domain" (essentially the registrable domain — example.com from mail.example.com) for relaxed alignment. The RFC acknowledges this is imperfect:

"Determining the Organizational Domain ... is currently done using a public suffix list, which may not be complete or accurate." — RFC 7489 §3.2

The Public Suffix List is community-maintained. Edge cases exist with certain TLDs and multi-level domains (e.g., .co.uk, .com.au). In practice, this rarely causes problems for standard domain configurations.

Quick Reference

---

This reference covers RFC 7489 — Domain-based Message Authentication, Reporting, and Conformance (DMARC), authored by M. Kucherawy and E. Zwicky. Supplementary RFCs referenced: RFC 8617 (Authenticated Received Chain). Content on this page is an editorial interpretation; see the original RFC for normative text. RFC content is subject to the IETF Trust's Legal Provisions.