RFC 9989 is now the current core DMARC specification. It obsoletes RFC 7489, the document most administrators still have in their bookmarks, and RFC 9091, the earlier Public Suffix Domain extension.
That makes "DMARC 2.0" a useful shorthand, but not a good reason to replace a working DNS record in a hurry. The familiar model is still here: receivers authenticate SPF and DKIM, check alignment with the visible From: domain, apply the published policy when DMARC fails, and can send aggregate feedback.
The important changes are in the edges of that model. RFC 9989 standardizes policy discovery more explicitly, adds controls for nonexistent subdomains and policy testing, and removes the old pct rollout mechanism from active processing.
For most domain owners, the immediate action is review, not wholesale DNS replacement:
v=DMARC1 records while checking them against the new rules.pct values.np=reject or np=quarantine for domains that must not be invented beneath your organizational domain.t=y before using it as a test signal. It is not a percentage control and it does not change report generation.Existing records using p, sp, rua, ruf, adkim, and aspf remain recognizable. The change is the processing model around them, not a new email authentication mechanism.
RFC 9989 is a standards-track update, but receiver support will not appear everywhere at the same time. During the transition, validate important behavior against the receivers that matter to your mail streams.
DMARC still authenticates domain use, not message content or the identity of a person. A message passes when at least one validated SPF or DKIM identifier is aligned with the domain in the RFC 5322 From: field.
The familiar distinction remains:
The policy record is still a DNS TXT record at _dmarc.example.com, and the policy values are still none, quarantine, and reject. RFC 9989 does not turn a DMARC pass into a guarantee that a message is wanted or safe. Receivers can continue to combine DMARC with reputation, content, and local filtering signals.
The new specification does, however, give administrators more precise tools for describing the DNS namespace below a policy and more precise rules for finding the policy that applies.
np: protect nonexistent subdomainsThe sp tag applies to existing subdomains. RFC 9989 adds np for nonexistent subdomains, meaning names for which DNS returns NXDOMAIN.
Consider this policy:
v=DMARC1; p=reject; sp=reject; np=reject; rua=mailto:dmarc@example.comIt expresses three related intentions:
example.com and failing DMARC should be rejectedThat last case matters because an attacker can use a plausible label such as billing.example.com even when the organization never created it. A policy record at the organizational domain can now state what should happen for that namespace without requiring a DNS record at every possible child name.
np is not a wildcard record and it does not create the subdomain. It is a policy used during DMARC policy discovery when the queried name does not exist. It also does not override a real subdomain's own policy. Keep the distinction between “the name exists but has no local DMARC record” and “the name does not exist” clear when troubleshooting.
If np is absent, RFC 9989 falls back to sp when present, or p when sp is absent. That default makes older records usable, but an explicit np is easier to audit when nonexistent-subdomain protection is part of the design.
t: test the policy without using pctThe new t tag is a policy test mode:
v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.comWith t=y, the receiver is asked not to apply the declared policy directly. The specification describes a policy one level below the declared policy for failing mail: reject is treated as quarantine, and quarantine is treated as none. A receiver can also apply its own special handling, such as rewriting the visible sender.
With t=n, the default, the declared policy is applied. The tag has no effect on a p=none policy and does not suppress or alter aggregate reports.
This is deliberately different from pct. t=y does not mean that a random percentage of failing messages is treated differently. It is a signal about the policy level being tested.
Testing is still receiver behavior, not a guarantee of delivery. A receiver can honor the request differently from another receiver, and a message can be handled by additional filtering rules after the DMARC policy decision.
pct is no longer a rollout planOlder deployment guides often recommended a sequence such as:
p=reject; pct=10
p=reject; pct=50
p=reject; pct=100RFC 9989 removes pct from active processing. The reason is operational, not cosmetic: receivers implemented percentage handling inconsistently, so the same record did not reliably produce the same protection everywhere.
The safer modern rollout is based on evidence rather than a hoped-for sample:
p=none with an aggregate report destination.p=quarantine or p=reject for the scope that is ready.If a team needs to test an enforcement policy before applying it, evaluate whether t=y is supported as intended by the receivers in scope. Do not assume that adding an old pct value provides a portable safety net.
The removal does not mean every historical receiver will instantly forget pct. It means new operational guidance and implementations should not depend on it. Keep old records simple while planning the migration, and test changes with actual messages rather than relying on the tag alone.
Previous DMARC descriptions commonly explained organizational-domain discovery using a Public Suffix List. RFC 9989 defines a DNS tree-walk procedure instead. Receivers can query the Author Domain and walk upward to discover an applicable policy and the boundary of the organizational domain.
The psd tag helps describe that boundary:
psd=y identifies a Public Suffix Domain policy published by a Public Suffix Operatorpsd=n identifies a domain that is authoritative for itself and its subdomains as an organizational domainpsd=u is the default when the status is not explicitly knownThis matters most to Public Suffix Operators and organizations with unusual delegation structures. A normal domain owner will usually continue publishing DMARC at the organizational domain. The operational lesson is to understand which DNS names a receiver will query, not to add psd=y to an ordinary company domain.
There is also a practical limit to the walk. RFC 9989 limits the relevant queries to eight labels. If an Author Domain is unusually deep and needs an exact policy, publishing the policy directly at that Author Domain avoids depending on a distant ancestor being discovered.
A receiver that still uses older policy-discovery assumptions may find a different policy from a receiver implementing the RFC 9989 tree walk. That can produce apparently inconsistent results for domains near public-suffix or delegation boundaries.
When investigating such a case, capture:
From: domain_dmarc DNS answer while following the name hierarchyNXDOMAIN or an empty positive responsepsd, p, sp, and np valuesDo not diagnose a policy-discovery issue from the visible From: address alone. The DNS response sequence is part of the evidence.
RFC 9989 defines the DMARC protocol and its policy records. The reporting formats and processing details are now specified in companion documents, including RFC 9990 for aggregate reporting and RFC 9991 for failure reporting.
This separation does not make rua optional in an operational sense. If reporting is part of the rollout, keep a valid rua destination and verify that reports are arriving, being parsed, and being retained appropriately.
The new text also changes some reporting guidance. A receiver that sends aggregate reports should send them to each listed reporting URI, and aggregate report generation is generally expected at least every 24 hours. Failure reports remain optional and can contain sensitive message data.
DMARCPal does not process ruf failure reports. That keeps the reporting workflow simpler and preserves privacy, since per-message failure reports are rarely available consistently and may contain message content or addresses.
For most domain owners, the practical reporting checklist is unchanged:
Check that each record has v=DMARC1 first, a clear p value, and a valid report destination where monitoring is expected. Review whether sp reflects the actual subdomain strategy. If nonexistent labels must be protected, add an explicit np value after confirming receiver support.
Do not add psd=y to a normal organizational domain. That value is for a Public Suffix Operator. If your organization administers a delegated namespace and needs to declare its own boundary, study whether psd=n is appropriate before publishing it.
Remove new references to pct from runbooks and automation. Replace a percentage-based rollout with a measured transition from monitoring to enforcement. If the runbook needs a policy test stage, document t=y and the receiver-specific behavior you observed.
Send legitimate messages from each production stream and inspect the delivered headers. Confirm that:
From: domainFor a new np policy, test both an existing subdomain and a deliberately nonexistent name in a controlled environment. The DNS state is important: a name that returns NXDOMAIN exercises a different path from a name that exists but has no DMARC record.
If you operate DMARC software, verify that it:
np, psd, and tpct as a current enforcement controlA parser can accept a tag syntactically while silently ignoring its operational meaning. That is not enough for a migration. Add test cases for an existing subdomain, a nonexistent subdomain, a PSD policy, and a policy with t=y.
The update does not make DMARC a complete anti-phishing system. DMARC still does not directly stop:
It also does not force a receiver to accept the domain owner's requested action. p=reject is a strong signal, but local filtering and receiver policy still control final handling.
Continue treating SPF, DKIM, DMARC, ARC where appropriate, reputation, and recipient expectations as separate parts of the mail system. RFC 9989 improves the policy language and discovery rules; it does not remove the need for an accurate sender inventory.
Use this short review when bringing existing operations into line with RFC 9989:
v=DMARC1 is the first tag and that records parse cleanly.pct.np policy.sp is intentional for existing subdomains.psd=y for a real Public Suffix Operator use case.t=y is useful for a controlled policy test.p=none monitoring until legitimate sources are understood.RFC 9989 is best understood as a clarification and hardening of DMARC's foundations. The visible policy values and SPF/DKIM alignment model remain familiar, while policy discovery becomes more explicit and namespace protection gets two useful additions: np for nonexistent subdomains and t for policy testing.
The biggest rollout change is the removal of pct. Replace percentage-based confidence with report-driven inventory, controlled receiver testing, and a clear move from monitoring to enforcement. For ordinary domain owners, that is the safest way to adopt the new specification without turning a standards update into an avoidable mail outage.