DMARC: connecting authentication to the visible sender

A message can pass SPF for one domain and DKIM for another while displaying a third domain in From. DMARC asks whether at least one passing authentication method also aligns with that visible author domain.

This article uses RFC 9989, published in May 2026, which obsoletes RFC 7489 and RFC 9091. Aggregate reporting is specified separately in RFC 9990. Older receivers and provider guides can still reflect the earlier standard, so verify support when deploying newer fields.

Alignment connects the identities

For SPF, DMARC uses the MAIL FROM identity, including SPF’s defined HELO-derived identity when the reverse-path is null. A standalone HELO pass for a non-null MAIL FROM does not independently satisfy DMARC. For DKIM, it uses the d= domain of a passing signature. If any passing DKIM signature aligns, that path can satisfy DMARC even when another signature fails.

Strict alignment requires identical domain names, compared case-insensitively. Relaxed alignment requires a shared Organizational Domain. RFC 9989 determines that boundary through its DNS tree-walk algorithm and policy records; this is not “take the last two labels.” Public suffix boundaries and the psd declaration matter. Earlier RFC 7489 used a public suffix list approach, so do not assume both versions always discover the same boundary.

The fictional matrix below assumes the tree walk identifies example.org and example.net as distinct Organizational Domains. Every visible From is news.example.org; modes apply to both methods for simplicity.

These are authentication outcomes, not inbox outcomes. A pass still leaves spam filtering and local policy decisions.

Discover and publish a policy deliberately

A receiver first looks for the relevant _dmarc TXT record and follows the standard’s bounded DNS tree walk when needed. The algorithm also establishes Organizational Domains for alignment, with rules for public suffix and organizational boundary declarations. Use an implementation supporting RFC 9989 rather than hand-writing suffix comparison.

Illustrative initial policy for a reader-controlled domain:

_dmarc.example.org. TXT "v=DMARC1; p=none; rua=mailto:dmarc-reports@example.org; adkim=r; aspf=r"

v must come first and remain DMARC1. p=none requests no special DMARC failure treatment; it does not disable other filtering. quarantine requests suspicious handling for failures; reject requests rejection. Receivers retain discretion, so requested policy and actual disposition can differ.

For an inventoried, working sender set, a later record might be:

_dmarc.example.org. TXT "v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc-reports@example.org"

sp specifies handling for existing subdomains under the applicable organizational policy; np covers non-existent subdomains. The standard defines inheritance and precedence, so test the exact author domains you use. psd=y is for a public suffix operator, not a routine tag to copy onto an application domain.

RFC 9989 removes the old pct rollout field. Its t=y test mode requests one policy level below the declared policy: reject becomes quarantine, quarantine becomes none. t=n is the default. This isn’t a percentage-based rollout, and older receivers may ignore t. Do not append pct=10 and assume the new standard will sample enforcement.

Reports help inventory senders

Aggregate reports summarize observed traffic: source IPs, counts, evaluated dispositions, alignment outcomes and authentication identities. This fictional, abbreviated record illustrates one group, not a complete report:

<record>
  <row>
    <source_ip>192.0.2.10</source_ip>
    <count>8</count>
    <policy_evaluated>
      <disposition>none</disposition>
      <dkim>pass</dkim><spf>fail</spf>
    </policy_evaluated>
  </row>
  <identifiers><header_from>news.example.org</header_from></identifiers>
  <auth_results>
    <dkim><domain>news.example.org</domain><selector>welcome2026</selector><result>pass</result></dkim>
    <spf><domain>sender.example.net</domain><scope>mfrom</scope><result>pass</result></spf>
  </auth_results>
</record>

The policy-evaluated SPF failure reflects lack of alignment even though the raw SPF check passed. DKIM supplies the aligned pass. Counts describe what the reporting receiver observed, not every message sent worldwide. Reports don’t reveal inbox placement or reading, and lack of a report doesn’t prove lack of abuse. Cross-domain reporting destinations require the authorization process described in RFC 9990.

Inventory applications, marketing systems, support platforms and forwarding paths first. Start monitoring, reconcile reports with known senders, fix DKIM signing and MAIL FROM alignment, then test quarantine and reject. Verify newer-field support and account for legacy receivers before relying on test mode. Keep a rollback path for legitimate senders accidentally excluded by policy.

References

• RFC 9989 — alignment, tree walk, policy tags and changes from RFC 7489.
• RFC 9990 — aggregate reporting and external destination authorization.
• RFC 7208 and RFC 6376 — authenticated SPF and DKIM identities.
• AWS SES: DMARC compliance — provider configuration; check its standard-version assumptions.