{"slug": "dmarc-is-now-a-proper-internet-standard-what-changed-in-rfc-9989-9990-9991", "title": "DMARC Is Now a Proper Internet Standard: What Changed in RFC 9989/9990/9991", "summary": "Here is a factual summary of the article:\n\nDMARC has been elevated from an Informational RFC to a full Standards Track specification with the release of RFCs 9989, 9990, and 9991, replacing the original RFC 7489. The most significant architectural change is the replacement of the Public Suffix List with a DNS Tree Walk algorithm for determining organizational domain boundaries, alongside the addition of new tags like `t` (test mode), `np` (non-existent subdomain policy), and `psd` (public suffix domain). The update also removes the deprecated `pct` and `rf` tags, makes DKIM selectors mandatory in reports, and requires rate limiting for failure reports to prevent DoS amplification.", "body_md": "DMARC has been an Informational RFC since 2015. That changed this month.\n\n[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) replaces RFC 7489 and elevates DMARC to **Standards Track**, reflecting over a decade of deployment experience and near-universal adoption across the email ecosystem. The spec was also split into three separate documents:\n\n-\n— core DMARC protocol[RFC 9989](https://www.rfc-editor.org/rfc/rfc9989.html) -\n— aggregate reporting (RUA)[RFC 9990](https://www.rfc-editor.org/rfc/rfc9990.html) -\n— failure reporting (RUF)[RFC 9991](https://www.rfc-editor.org/rfc/rfc9991.html)\n\nSplitting them allows each component to evolve independently. Here's what changed.\n\n## The DNS Tree Walk Replaces the Public Suffix List\n\nThis is the most significant architectural change.\n\nRFC 7489 used the [Public Suffix List](https://publicsuffix.org/) to determine organizational domain boundaries. To find the org domain for `mail.example.co.uk`\n\n, you'd look up `co.uk`\n\nin the PSL, then take one label to the left. It works, but the problems are real: external dependency, manual maintenance, potential staleness, no support for non-obvious namespace boundaries.\n\nRFC 9989 introduces the**DNS Tree Walk** as the alternative. The algorithm walks up the DNS tree looking for `_dmarc`\n\nTXT records, starting from the sending domain and moving toward the root. It caps at eight queries to prevent DoS amplification.\n\nFor most domains this changes nothing operationally. For complex organizations with deep subdomain hierarchies, or operators running public suffix domains that want their own DMARC policies, it's a meaningful improvement.\n\nThe new `psd`\n\ntag lets a domain declare itself as a Public Suffix Domain, enabling DMARC policy coverage at that level.\n\n## New Tags\n\n### `t`\n\n— Test Mode\n\nReplaces the behavioral role of `pct`\n\n. Where `pct=0`\n\nmeant \"apply policy to 0% of failing messages,\" `t=y`\n\nexplicitly signals that the policy is in test mode and shouldn't be enforced.\n\nThe distinction between \"policy exists but is being staged\" and \"policy is active against a subset of traffic\" is now unambiguous.\n\n```\nv=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com\n```\n\n### `np`\n\n— Non-Existent Subdomain Policy\n\nAllows separate policy handling for subdomains that have no DNS records at all. Previously, `sp`\n\napplied to all subdomains. Now you can distinguish between legitimate configured subdomains (`sp`\n\n) and mail claiming to originate from subdomains that don't exist in DNS (`np`\n\n).\n\nNon-existent subdomains sending mail are almost always spoofing, so `np=reject`\n\nis often the right default.\n\n### `psd`\n\n— Public Suffix Domain\n\nMarks the domain as a Public Suffix Domain for the DNS Tree Walk algorithm.\n\n## Removed Tags\n\n### `pct`\n\n— Gone\n\nPercentage-based partial enforcement has been removed. Use `t=y`\n\nfor test mode instead.\n\n### `rf`\n\n— Report Format\n\nRemoved. Only AFRF format was ever widely implemented. The tag was vestigial.\n\n### `ri`\n\n— Report Interval\n\nRemoved. Aggregate reports are daily. The tag existed, receivers rarely honored it, and the spec now reflects reality.\n\n## Aggregate Reporting Changes (RFC 9990)\n\nThe aggregate reporting spec was extracted from RFC 7489 into its own document. The format remains XML with several refinements.**DKIM selector is now mandatory in reports.** Previously optional, it's required for understanding which DKIM key configuration is producing results — which matters for key rotation debugging.**New discovery method field** indicates whether the receiver used `psl`\n\nor `treewalk`\n\nto find the organizational domain. Useful for diagnosing alignment issues during the transition period.**Extension framework** allows future XML schema additions within defined namespaces without breaking existing parsers.\n\nThe schema changes are backward-compatible. Well-formed RFC 7489 reports will still parse. If you're running your own DMARC report parser, the new fields are additive.\n\n## Failure Reporting Changes (RFC 9991)\n\nThe changes here are more significant for implementors.** Identity-Alignment is now a mandatory ARF header.**Failure reports must include this field listing which authentication mechanisms failed to produce an aligned pass, or\n\n`none`\n\nif all passed. This was absent from the original spec, leading to inconsistent implementations.**Rate limiting is now required.** RFC 9991 explicitly mandates that report generators implement rate limits. This closes a known gap: failure reports can be triggered by an attacker sending large volumes of spoofed mail, making an unrated reporting system a DoS amplification vector.** dmarc is now a formal ARF authentication failure type.**The\n\n`Authentication-Failure`\n\nARF header now includes `dmarc`\n\nas a valid type value alongside the existing `dkim`\n\nand `spf`\n\ntypes.**Privacy guidance is significantly expanded.** The document adds detailed guidance on PII redaction, URI validation, and secure transport for failure reports. If you're forwarding RUF reports to a third-party reporting service, the privacy section of RFC 9991 is worth reading before you do.\n\n## What You Actually Need to Do\n\nFor most domain owners, nothing changes immediately. RFC 9989 is backward-compatible with RFC 7489 and your existing DMARC record continues to work.\n\nThe practical checklist:\n\n-**Remove** from your DMARC records. Receiver behavior around deprecated tags will vary as implementations update.`pct`\n\ntags -**If you're using**, move to`pct=0`\n\nfor staged rollouts`t=y`\n\nto signal test mode explicitly. -**If you're operating mail infrastructure**(MTAs, DMARC reporting tools, monitoring systems), the`Identity-Alignment`\n\nrequirement in RFC 9991 and the`psd`\n\n/treewalk changes in RFC 9989 require implementation updates. -**Public Suffix Domain operators** should evaluate adding`psd=y`\n\nonce receiver support is established.\n\nThe Standards Track designation matters for enterprise and government procurement environments where \"Informational RFC\" raised compliance questions. DMARC is now a proper internet standard, not a proposal.", "url": "https://wpnews.pro/news/dmarc-is-now-a-proper-internet-standard-what-changed-in-rfc-9989-9990-9991", "canonical_source": "https://dev.to/mikepultz/dmarc-is-now-a-proper-internet-standard-what-changed-in-rfc-998999909991-pj6", "published_at": "2026-05-22 21:46:45+00:00", "updated_at": "2026-05-22 22:01:12.132953+00:00", "lang": "en", "topics": ["cybersecurity", "policy-regulation", "research"], "entities": ["DMARC", "RFC 9989", "RFC 9990", "RFC 9991", "RFC 7489", "Public Suffix List", "DNS Tree Walk"], "alternates": {"html": "https://wpnews.pro/news/dmarc-is-now-a-proper-internet-standard-what-changed-in-rfc-9989-9990-9991", "markdown": "https://wpnews.pro/news/dmarc-is-now-a-proper-internet-standard-what-changed-in-rfc-9989-9990-9991.md", "text": "https://wpnews.pro/news/dmarc-is-now-a-proper-internet-standard-what-changed-in-rfc-9989-9990-9991.txt", "jsonld": "https://wpnews.pro/news/dmarc-is-now-a-proper-internet-standard-what-changed-in-rfc-9989-9990-9991.jsonld"}}