DMARC Is Finallyan Actual Standard

DMARC was never an IETF standard. Now it is.

If you have ever argued with a mailbox provider about DMARC behavior, you have run into the awkward part: RFC 7489 was published as Informational. It described what the industry had converged on. It was not a specification you could hold anyone to.

That ended in May 2026. RFC 9989 carries Category: Standards Track and Obsoletes: 7489, 9091 in its header. DMARC is a Proposed Standard. The normative keywords in it are real ones, and the tag registry it defines is authoritative — per Section 4.7, only tags in that registry are to be processed, and unknown tags MUST be ignored.

The work — known throughout its life as DMARCbis, and finalized as draft-ietf-dmarc-dmarcbis-41 — shipped as three documents, not one:

The second obsoletion is easy to miss. RFC 9091 was the experimental Public Suffix Domain extension — the one that gave us np= and the notion of a registry operator publishing policy on behalf of everything under it. It is no longer an experiment. It is folded into the base standard as the psd= tag.

The tree walk replaces the Public Suffix List

This is the largest architectural change in the document, and it is the one nobody put in a release note.

DMARC has always needed to answer one question before it can do anything else: what is the Organizational Domain for this name? That answer decides which record applies and whether an authenticated identifier is aligned. Under RFC 7489 the answer came from a Public Suffix List. RFC 9989 Section 4.10 explains, at some length, why that was a problem:

Two receivers with two different snapshots of a list maintained outside the IETF could legitimately disagree about your Organizational Domain, and therefore about whether your mail was aligned. RFC 9989 replaces the list with something every receiver already has: DNS.

How the walk works

Section 4.10 lays it out in seven steps. Query _dmarc.<target> for a TXT record in DMARC Policy Record format. Discard anything that does not start with a v tag for the current version. If a single record remains and it carries psd=n or psd=y, stop. Otherwise count the labels, strip the leftmost one, and query again — repeating until you run out of labels.

There is one shortcut in the middle of that loop, and the RFC is refreshingly blunt about why it exists:

So a name with fewer than eight labels strips one label at a time. A name with eight or more jumps straight down to seven remaining labels and continues from there. The RFC works the pathological case through in full:

Author Domain: a.b.c.d.e.f.g.h.i.j.mail.example.com

_dmarc.a.b.c.d.e.f.g.h.i.j.mail.example.com
_dmarc.g.h.i.j.mail.example.com
_dmarc.h.i.j.mail.example.com
_dmarc.i.j.mail.example.com
_dmarc.j.mail.example.com
_dmarc.mail.example.com
_dmarc.example.com
_dmarc.com

= 8 queries, the hard cap

Eight is a ceiling, not a cost. A normal two- or three-label domain that publishes its own record resolves in one query and stops. Nobody is paying eight lookups per message.

It runs more than once per message

Section 4.10 opens by naming two distinct uses for the walk. The first is the obvious one: policy discovery (Section 4.10.1), when the Author Domain has no record of its own and the receiver needs to find the one it inherits from. The second is the one people forget — identifier alignment evaluation (Section 4.10.2), deciding whether the SPF- or DKIM-authenticated identifier and the Author Domain share an Organizational Domain. A receiver may run the walk several times while evaluating a single message.

Once the walk has collected records, Section 4.10.2 picks the Organizational Domain by going from the longest name to the shortest. A record with psd=nwins immediately — that name is the Organizational Domain, stop looking. A record other than the starting point carrying psd=y means the Organizational Domain is the domain one label below it. Failing both, it is the record found at the name with the fewest labels. If the process determines nothing at all, the initial target domain is the Organizational Domain.

Two things this change is not. It is not a deprecation of the Public Suffix List — RFC 9989 replaces the PSL for DMARC Organizational Domain discovery and says nothing about the list’s many other consumers. And it is not a new obligation on you. There is no requirement that you publish a “tree-walk discoverable” record. Section 5.1.4 notes that if the Organizational Domain differs from the Author Domain, a record also needs to be published for the Organizational Domain. That is a publishing recommendation, and the MUSTs in this area all land on the receiver.

pct= is gone

Not softened. Not discouraged in prose. Removed.

Section 4.7 lists the complete set of valid DMARC tags: adkim, aspf, fo, np, p, psd, rua, ruf, sp, t, v. pct is not on it. The IANA registry in Section 9.3 lists it as historic, with the reference column still pointing at RFC 7489 — IANA’s way of saying this tag belongs to the old document. The registry defines that status as meaning “the tag is considered deprecated and is not expected to be in use in any current implementation”.

Combine that with the unknown-tag rule from the same section — only tags in the registry are to be processed, unknown tags MUST be ignored — and a pct=25 in your record is now just text a conforming receiver steps over.

Why, in the RFC’s own words

Read that again if you have ever staged a rollout at pct=25. The percentage was not being applied the way you assumed, and it was being misapplied differently by every receiver. The dial you thought you were turning was painted on.

What survived is the one value that did something reliable. Appendix A.6 records that some intermediaries treated pct=0 as a signal to rewrite the RFC5322.From header, which meant a Domain Owner could compare aggregate reports before and after setting it and infer how much of its traffic flowed through non-rewriting intermediaries. That side effect was worth keeping. The tag wrapped around it was not:

t= steps your policy down one level

Section 4.7 defines t as DMARC policy test mode, optional, defaulting to n. The semantics are more precise than “testing” suggests:

np=, sp=, and what “non-existent” means

These two tags carve the subdomain space in half. np takes the names that do not exist; sp takes the ones that do.

Section 4.7 defines np as the Domain Owner Assessment Policy for non-existent subdomains of the given Organizational Domain. Its syntax is identical to p. It applies only to non-existent subdomains — not to existing subdomains, and not to the domain itself. When it is absent, the policy from sp applies if sp is present, and the policy from p applies if it is not.

That inheritance chain is why np is the cheapest hardening available to most domains. Attackers do not need a real subdomain to spoof you; they need a plausible-looking one. np=reject closes the entire space of names you never created, without touching any name you did.

“Non-existent” is narrower than you think

Appendix A.4 defines the test, and it is deliberately permissive:

The appendix spells out the DNS distinction that this rests on: an NXDOMAIN response means the name does not exist, while a NODATA response — rcode NOERROR with no records of the queried type — means the type does not exist but the name does. It also carries the RFC 8020 consequence forward: if a query for a name returns NXDOMAIN, every name below it in the hierarchy also does not exist.

Note what the RFC declined to do. It does not use the narrower “resolvable” definition from RFC 5321, which would have required MX, A, or AAAA records. A lone TXT record makes a name exist. A stale CNAME makes a name exist. Which means npwill quietly not apply to a large number of names you assumed it covered — and sp will.

sp= got narrower, and gained a footgun

Section 4.7 now scopes sp to mail using an existing subdomain of the prevailing Organizational Domain, and not to the Organizational Domain itself. The non-existent half was carved out into np. The inheritance rule you already know still holds: with both sp absent and np absent or not applicable, the p policy MUST be applied for subdomains.

The part worth writing on a sticky note is the last sentence of that definition:

Publishing sp=reject at _dmarc.mail.example.com does nothing. It parses, it validates, it will show up green in most checkers, and it has no effect. Subdomain policy is a property of the Organizational Domain record.

p= is now RECOMMENDED, not required

This one is under-reported and it changes what counts as a valid record. Section 4.7 marks p as RECOMMENDED for DMARC Policy Records, and adds that if the tag is not present in an otherwise syntactically valid record, the record is treated as if it included p=none.

Section 4.10.1 makes the receiver behavior normative. If a retrieved record has no valid p tag — or has an sp or nptag that is not valid — and a rua tag is present containing at least one syntactically valid reporting URI, the Mail Receiver MUST act as if a record containing p=none was retrieved and continue processing. Without that valid rua, the receiver applies no DMARC processing to the message at all.

; valid under RFC 9989. means p=none.
_dmarc.example.com. IN TXT "v=DMARC1; rua=mailto:dmarc@example.com"

; also valid: a broken p= with a working rua= degrades to p=none
_dmarc.example.com. IN TXT "v=DMARC1; p=bogus; rua=mailto:dmarc@example.com"

; no DMARC processing at all: broken p=, no rua= to fall back to
_dmarc.example.com. IN TXT "v=DMARC1; p=bogus"

The practical read: a monitoring-only record no longer needs to say so. It needs somewhere to send the reports. We will come back to this one — Wraps’ own parser gets it wrong today.

Reporting moved out of the core document

rua and ruf are still active tags, but the formats they produce are no longer defined in the DMARC document. Section 4.7 points rua at RFC 9990 and ruf at RFC 9991. Both also gained a MUST: if the tag is not provided, Mail Receivers MUST NOT generate reports of that kind for the domain, and URIs using schemes a receiver does not support MUST be ignored.

Two tags did not survive the move. Section 9.3 marks both rf (failure report format) and ri (aggregate reporting interval) as historic, and neither appears in the Section 4.7 valid tag list. ri is the sharper loss of the two: report cadence is no longer something a sender asks for in its policy record. If you have been setting ri=3600 and wondering why reports still arrive daily, that question is now settled by removal.

fo survives unchanged in shape — colon-separated values from 0, 1, d, s, defaulting to 0— with one clarification worth knowing: Section 4.7 says its content MUST be ignored if a ruf tag is not also specified. A record with fo=1 and no ruf= is doing nothing.

The tag registry, after RFC 9989

What did not change, and one new protection

The advice has not moved. p=none is still where Section 5.1.4 tells you to start, paired with a rua pointing at a mailbox you actually read. It is still not protection. But RFC 9989 added a normative guarantee around it that RFC 7489 did not have:

That is a floor, not a ceiling: publishing monitoring mode is guaranteed not to make your deliverability worse than publishing nothing. It removes the last excuse for not turning DMARC on tomorrow. It does not make p=none do anything for you.

The same section applies a check in the other direction, at anyone feeling triumphant about reaching p=reject: Mail Receivers SHOULD NOT reject messages solely because of a published policy of reject, and should apply other knowledge and analysis to avoid rejecting legitimate messages sent in ways DMARC cannot describe, harming mailing lists, and similar. Your policy is an input to a decision, not the decision.

And on the timeline, the RFC is sober. Section 5.1.7 says that depending on sending cadence, it may take many months of consuming aggregate reports before a Domain Owner is sure it is properly authenticating all of its mail. If a vendor promises you p=reject in a fortnight, that promise is not coming from the spec. The four-step ramp is covered in detail in Your DMARC Policy Is Useless; nothing in RFC 9989 changes the shape of it, only the tags you use along the way.

The record, before and after

Here is what a Wraps-generated DMARC record looked like before today, and what it looks like now:

; before
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; rua=mailto:postmaster@mail.example.com"

; after
_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:postmaster@mail.example.com"

Two additions, and only one of them changes behavior. sp=quarantine is a no-op in policy terms — Section 4.7 already says an absent sp inherits from p, so writing it out changes nothing except how the record reads. We write it because a record that states its subdomain policy is a record nobody has to reason about at 2am.

np=reject is the real change. Under the old record, mail from a subdomain that has never existed inherited p=quarantine — a spoofed billing.example.com landed in the junk folder, where people read it. Now it is rejected at the door.

What Wraps shipped today

Two packages went out this morning: @wraps.dev/email-check@1.1.0 (the library) and mail-audit@1.2.0 (the standalone CLI that bundles it). The change has two halves: the checker learned the new tags, and every place Wraps writes a DMARC record started writing the new one.

The parser

The generator

The new record string replaced the old one in fifteen places: Pulumi’s Route53, Cloudflare, and Vercel DNS resources; the CDK email construct; the CLI’s Route53 preview and both create paths, its Cloudflare and Vercel paths, and its manual record builder; the CLI’s success and status output; the console’s copy-to-clipboard button; the CLI README; and the domain verification and Vercel setup guides in the docs. If Wraps tells you a DMARC record to publish, it is the DMARCbis one.

Why np=reject is safe as a default here

Defaulting a customer’s domain to a reject policy deserves an argument, so here it is. nponly applies to subdomains that return NXDOMAIN. Wraps’ MAIL FROM subdomain always carries MX and SPF records — that is how Wraps provisions it — and per Appendix A.4, any RR at a name makes that name exist. The subdomain Wraps sends from is therefore, by construction, not a name np can reach. np=reject cannot block Wraps sending.

How to see it on your own domain

The standalone CLI is unscoped on npm and needs no account:

# full deliverability audit
npx mail-audit example.com

# the DMARCbis fields live here
npx mail-audit example.com --json

# same checks, via the Wraps CLI
wraps email check example.com

That --json is not optional advice. The human-readable output of both CLIs prints policy, reporting, and alignment, and stops there:

  ✓ DMARC            v=DMARC1; p=reject; rua=mailto:postmaster@mail.wraps.dev
                     Policy: reject • Reporting: enabled • Alignment: relaxed

No np, no t, no psd. The DMARCbis deductions are all one or two points and the ISSUES section only renders deductions of five or more, so they do not appear there either. The pretty output has not caught up with the parser yet. The structured output has:

{
  "nonExistentSubdomainPolicy": null,
  "testing": false,
  "psd": null,
  "warnings": [
    "No np= set — add np=reject to block spoofing from non-existent subdomains (DMARCbis)"
  ]
}

The same fields come back from the public checker API, which needs no auth and is rate-limited by IP:

curl https://api.wraps.dev/tools/email-check/example.com

Or skip the install entirely and use the checker on the site, where the DMARC panel now has a Non-Existent Subdomains tile in the slot the old pct= tile used to occupy. When np is absent it renders np=inherit, which is the honest description of what happens.

What “DMARCbis-aware” does not mean

Being explicit about the surface area, because “RFC 9989 support” is going to appear on a lot of marketing pages this year and most of it will mean less than this does:

One more limit worth naming, on the standard rather than on us: we have not verified which mailbox providers honor np=, t=, or the tree walk today, and RFC 9989 does not tell you. Publishing the tags is correct because the standard defines them. Assuming a specific receiver acts on them is a different claim, and not one we are making.

Sources