{"id":8177,"date":"2026-07-17T19:45:07","date_gmt":"2026-07-17T19:45:07","guid":{"rendered":"https:\/\/www.warmy.io\/blog\/?p=8177"},"modified":"2026-07-17T19:47:33","modified_gmt":"2026-07-17T19:47:33","slug":"dmarcbis-what-changed","status":"publish","type":"post","link":"https:\/\/www.warmy.io\/blog\/email-best-practices\/dmarcbis-what-changed\/","title":{"rendered":"DMARCbis (RFC 9989): What Changed and What You Do Now"},"content":{"rendered":"\n<p><strong>TL;DR<\/strong><\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>DMARCbis is now official as RFC 9989, 9990, and 9991, published May 2026.<\/li>\n\n\n\n<li>Your existing v=DMARC1 record keeps working. No rebuild is required.<\/li>\n\n\n\n<li>Clean up the deprecated tags in your record: pct, rf, and ri.<\/li>\n\n\n\n<li>The new tags (np, psd, t) are optional and safe to add when you need them.<\/li>\n<\/ul>\n\n\n\n<p>In May 2026 the IETF published RFC 9989, 9990, and 9991, the first substantive update to the DMARC specification since the original landed in 2015. DMARC is finally a Standards Track protocol instead of an informational one.<\/p>\n\n\n\n<p>If you run <a href=\"https:\/\/www.warmy.io\/blog\/best-cold-email-outreach-agencies\/\" data-type=\"post\" data-id=\"4330\" target=\"_blank\" rel=\"noopener noreferrer\">cold outreach <\/a>or manage deliverability for a growing domain, you have probably seen a dozen vendor posts calling this a milestone without saying what to do about it. The compliance-heavy coverage buries the one question that matters to senders.<\/p>\n\n\n\n<p>That question is simple: does your current <a href=\"https:\/\/www.warmy.io\/free-tools\/dmarc-generator\/\" target=\"_blank\" rel=\"noopener noreferrer\">DMARC record<\/a> still work, or do you need to rebuild it? Here is the plain-English answer, plus the tags worth cleaning up before your next DNS change.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What just happened with DMARC<\/strong><\/h2>\n\n\n\n<p>The IETF published three documents that together replace the original DMARC specification from 2015. RFC 9989 is the core protocol. RFC 9990 covers aggregate reporting, the daily XML data you get back from mailbox providers. RFC 9991 covers failure reporting. The old single spec, RFC 7489, is now obsolete, along with RFC 9091, the earlier experimental extension for public suffix domains.<\/p>\n\n\n\n<p>The headline change is status. The 2015 DMARC spec was an Informational document published outside the IETF standards process. RFC 9989 is a Proposed Standard on the IETF Standards Track. For the first time, DMARC has formal IETF endorsement, which gives auditors and procurement teams a real standard to cite.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>From one informational spec to three standards-track RFCs<\/strong><\/h2>\n\n\n\n<p>Splitting the protocol into three documents was a deliberate design choice. Under RFC 7489, any fix to reporting meant reopening the entire specification. Now the protocol and its two reporting formats can each evolve on their own timeline without touching the others.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Why DMARCbis is really just the new DMARC<\/strong><\/h2>\n\n\n\n<p>There is no \u201cDMARC2.\u201d The record version tag stays as v=DMARC1, and it is still the only valid value. Your published records did not become invalid the day RFC 9989 landed. If you understand DMARC today, you already understand most of what has changed.<\/p>\n\n\n\n<p><em>There is no DMARC2. Records still begin with v=DMARC1, and every deployment already in the wild keeps working.<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Why this matters if you send cold email<\/strong><\/h2>\n\n\n\n<p>DMARC is already part of your deliverability baseline if you run outbound at any volume.<a href=\"https:\/\/www.warmy.io\/blog\/email-deliverability\/gmail-bulk-sender-requirements-explained\/\" data-type=\"post\" data-id=\"7095\" target=\"_blank\" rel=\"noopener noreferrer\"> Google and Yahoo have required it for bulk senders<\/a> above 5,000 messages a day since early 2024, and frameworks like PCI DSS 4.0 and NIS2 in the EU reference it directly. A spec update to something this load-bearing is worth ten minutes of your attention even when nothing breaks.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What auditors and mailbox providers can now point to<\/strong><\/h2>\n\n\n\n<p>The move to Standards Track carries real weight in a regulated environment. An \u201cInformational RFC\u201d raised questions in enterprise and government procurement, where teams want to cite a recognized standard. A Proposed Standard removes that friction and gives your compliance reviewers a cleaner reference.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Where old ambiguities cost inbox placement<\/strong><\/h2>\n\n\n\n<p>Plenty of DMARC problems trace back to mismatched assumptions. A domain owner expects a policy to apply to one domain, while a receiver calculates the organizational domain a different way, and the reporting data becomes hard to read. RFC 9989 tightens the definitions and adds explicit examples and a conformance section, which shrinks the gray areas that quietly work against your placement.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>What actually changed at the protocol level<\/strong><\/h2>\n\n\n\n<p>Most of the update is clarification rather than new mechanics. A few changes are worth understanding in detail, because they affect how receivers read your record and which tags you should keep.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The DNS Tree Walk replaces the Public Suffix List<\/strong><\/h2>\n\n\n\n<p>The old spec relied on the Public Suffix List, a third-party file, to figure out the organizational domain. RFC 9989 replaces that with a DNS Tree Walk. The receiver starts at the sending domain and walks up the DNS tree looking for a _dmarc record at each level, capped at eight lookups to prevent abuse. For most senders this changes nothing you can feel. For organizations with deep subdomain trees, a receiver on the new spec can sometimes resolve a different organizational domain than one still running RFC 7489.<\/p>\n\n\n\n<p><em>If you run a complex subdomain hierarchy, publish an explicit DMARC record at every domain you actually send from. That removes the ambiguity between old and new receivers.<\/em><\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Tags removed: pct, rf, and ri<\/strong><\/h2>\n\n\n\n<p>pct (percentage), rf (report format), and ri (report interval) are deprecated and no longer belong in a current record. They were rarely used well, and leaving them in adds noise. Plan to remove them on your next DNS edit.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Tags added: np, psd, and t<\/strong><\/h2>\n\n\n\n<p>RFC 9989 introduces three new tags, all optional:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li><strong>np<\/strong> sets a policy for non-existent subdomains, the ones that return NXDOMAIN. It closes a subdomain-spoofing gap that sp did not cover, since sp only applies to subdomains that actually exist.<\/li>\n\n\n\n<li><strong>psd<\/strong> flags a domain as a Public Suffix Domain, such as a country-code or sector registry. Most sending domains never touch this.<\/li>\n\n\n\n<li><strong>t<\/strong> signals test mode explicitly. It takes over the staging role that people used to approximate with pct=0, so \u201cthis policy is being staged\u201d is now unambiguous.<\/li>\n<\/ul>\n\n\n\n<p>An example record using the new tags looks like this:<\/p>\n\n\n\n<p>v=DMARC1; p=reject; np=quarantine; psd=n; t=y; rua=mailto:reports@yourdomain.com<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>New guidance on p=reject for mailbox domains<\/strong><\/h2>\n\n\n\n<p>One behavioral shift matters for anyone whose users post to mailing lists. RFC 9989 discourages p=reject for domains that host general user mailboxes, unless you have measured the risk and have controls in place. Forwarding and mailing lists still break the SPF or DKIM alignment DMARC expects, and an aggressive reject policy can bounce legitimate mail before it ever reaches the inbox.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Do you need to redo your DMARC setup?<\/strong><\/h2>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>The one-line answer<\/strong><\/h2>\n\n\n\n<p>No. Your current record still works, and the new tags are additive. The work here is a short cleanup of what you already have.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>A five-point record audit you can run in ten minutes<\/strong><\/h2>\n\n\n\n<p>Pull your current record and check it against the new spec:<\/p>\n\n\n\n<ul class=\"wp-block-list\">\n<li>Confirm the record still starts with v=DMARC1. It should, and nothing else is valid.<\/li>\n\n\n\n<li>Remove pct, rf, and ri if any of them are present.<\/li>\n\n\n\n<li>If you manage subdomains, evaluate np, and start with np=quarantine rather than np=reject so you do not block undocumented but legitimate hosts.<\/li>\n\n\n\n<li>Publish an explicit DMARC record at every subdomain you send from, so the DNS Tree Walk resolves the same policy for every receiver.<\/li>\n\n\n\n<li>Review your rua and ruf reporting addresses, and confirm your monitoring tool can parse the RFC 9990 and 9991 report formats.<\/li>\n<\/ul>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Mistakes senders are making with the new spec<\/strong><\/h2>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Chasing tags you don\u2019t need<\/strong><\/h2>\n\n\n\n<p>The new tags help in specific situations. They are not universal upgrades. Adding psd to an ordinary sending domain does nothing for you, and jumping straight to np=reject can block real mail from hostnames nobody documented. Adopt a tag when you can name the exact problem it solves for your domain.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Reading Standards Track as a new mandate<\/strong><\/h2>\n\n\n\n<p>The promotion to Proposed Standard does not create new sending requirements on its own. Google and Yahoo\u2019s thresholds did not move because of it. Treat RFC 9989 as a prompt to tidy your record and confirm your tooling is current, not as a deadline to scramble against.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\"><strong>Get your record standards-ready<\/strong><\/h2>\n\n\n\n<p>The spec reads more clearly now, and mailbox providers are already evaluating mail against it. A ten-minute audit keeps your outbound aligned with how receivers discover your policy and score your sends.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Generate a compliant DMARC record in minutes<\/h2>\n\n\n\n<figure class=\"wp-block-image size-full\"><img loading=\"lazy\" decoding=\"async\" width=\"774\" height=\"532\" src=\"https:\/\/www.warmy.io\/blog\/wp-content\/uploads\/2026\/03\/DMARC-Record-Generator-1.png\" alt=\"\" class=\"wp-image-5151\" title=\"\" srcset=\"https:\/\/www.warmy.io\/blog\/wp-content\/uploads\/2026\/03\/DMARC-Record-Generator-1.png 774w, https:\/\/www.warmy.io\/blog\/wp-content\/uploads\/2026\/03\/DMARC-Record-Generator-1-300x206.png 300w, https:\/\/www.warmy.io\/blog\/wp-content\/uploads\/2026\/03\/DMARC-Record-Generator-1-768x528.png 768w\" sizes=\"auto, (max-width: 774px) 100vw, 774px\" \/><\/figure>\n\n\n\n<p>Manually assembling a DMARC record means getting the syntax, tag order, and reporting addresses right on the first try. Warmy&#8217;s <a href=\"https:\/\/www.warmy.io\/free-tools\/dmarc-generator\/\" target=\"_blank\" rel=\"noopener noreferrer\">free DMARC generator<\/a> walks you through each field, including the reporting and policy tags covered above, and outputs a record you can paste straight into your DNS. It&#8217;s a fast way to confirm your setup lines up with the current spec before you make any changes.<\/p>\n\n\n\n<h2 class=\"wp-block-heading\">Further reading<\/h2>\n\n\n\n<p>For the full technical detail behind the changes discussed here, the primary sources are worth bookmarking: <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc9989\" rel=\"noopener\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 9989<\/a> defines the current DMARC protocol, and <a href=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc7489\" data-type=\"link\" data-id=\"https:\/\/datatracker.ietf.org\/doc\/html\/rfc7489\" rel=\"noopener\" target=\"_blank\" rel=\"noopener noreferrer\">RFC 7489<\/a> is the original 2015 specification it replaces.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>TL;DR In May 2026 the IETF published RFC 9989, 9990, and 9991, the first substantive update to the DMARC specification since the original landed in 2015. DMARC is finally a Standards Track protocol instead of an informational one. If you run cold outreach or manage deliverability for a growing domain, you have probably seen a [&hellip;]<\/p>\n","protected":false},"author":2,"featured_media":8178,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[120],"tags":[],"class_list":["post-8177","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-email-best-practices"],"acf":[],"lang":"en","translations":{"en":8177},"pll_sync_post":[],"_links":{"self":[{"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/posts\/8177","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/comments?post=8177"}],"version-history":[{"count":3,"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/posts\/8177\/revisions"}],"predecessor-version":[{"id":8181,"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/posts\/8177\/revisions\/8181"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/media\/8178"}],"wp:attachment":[{"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/media?parent=8177"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/categories?post=8177"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.warmy.io\/blog\/wp-json\/wp\/v2\/tags?post=8177"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}