DMARC RFC Guide: How the Revised Standard Affects You
Now that DMARCbis has become a reality after development in the IETF DMARC Working Group, we’re following up to explain how the new 9989, 9990, and 9991 RFCs (Requests for Comments) have evolved and how they affect your DMARC records.
The IETF published three new DMARC specifications, RFC 9989, RFC 9990, and RFC 9991, rendering RFC 7489 obsolete.
Though the updates aren’t revolutionary and won’t require domain owners to update their DMARC records to maintain functionality, the changes are an attempt to improve clarity, security, and interoperability of the control.
What has changed in the DMARC specification?
Instead of one DMARC RFC, there are now three separate RFCs, which we cover below.
DMARC (RFC 9989)
The foundational DMARC specification, RFC 9989 introduces new tags, deprecates other tags, and replaces Public Suffix List (PSL) with a DNS tree walk algorithm to more accurately discover valid DMARC policy records.
Obsolete DMARC tags
Tags removed from the DMARC specification include pct, rf, and ri. The pct tag is replaced with the t (testing mode) tag to create an all (100%) or nothing (0%) scenario. rf (aggregate report format) and ri (interval between aggregate reports) tags have been removed because they weren’t implemented often and ignored by receivers, respectively. Their absence aims to simplify and streamline DMARC deployment.
New DMARC tags
Following are the new DMARC record tags and how they work:
t (testing mode) – Replaces the pct tag and has the following binary values:
- t=n is the default value that applies the published DMARC policy and equivalent to the pct=100 value.
- t=y indicates that the published DMARC policy in the p, sp, and/or np tags should not be applied and acts like the pct=0 value.
When to use the t tag
Set t=y (alongside p=quarantine or p=reject) to test enforcement safely: receivers apply no enforcement action, so no mail is impacted, while reports still show which sources would fail. Mail that an intermediary rewrites, such as a mailing list resending under its own domain, drops out of the data, leaving only the sources that must become compliant before you enforce.
np (non-existent subdomain policy) – with the same policy values as p and sp tags, the np tag allows you to apply a policy to a subdomain that doesn’t exist. The tag’s power is setting an enforcement policy for a non-existent subdomain to stop criminals from sending fraudulent emails from a fake subdomain based on your parent domain.
When to use the np tag
Set np=quarantine or np=reject to enforce on mail from non-existent subdomains while keeping p and sp at none. A common attack pattern is spoofing addresses at subdomains that don’t exist; for example, abc123.example.com since these have no policy of their own. The np tag lets you block that abuse without committing the rest of your mail to enforcement.
psd (public suffix domain) – used to clarify and define public suffix domains (PSD). The tag will be used to define the root domain of the From domain and has the following values:
- psd=y demonstrates that the domain is a PSD. If a record containing this tag with a value of y is found during policy discovery, this information will be used to determine the organizational domain and DMARC policy domain.
- psd=n indicates that the DMARC policy record is published for a domain that is not a PSD, but an organizational domain and its subdomains.
- psd=u is the default value indicating that the DMARC policy record is published for a domain that is not a PSD, and may or may not be an organizational domain for itself and its subdomains. In this case, the DNS tree walk determines the organizational domain. DNS tree walk is the process of associating a domain name with an IP address by navigating the DNS.
When to use the psd tag
The most common setting for a domain owner is psd=n. Previously, the Organizational Domain was fixed and the DMARC specification determined it for you with no owner control. The psd=n tag and value lets a domain owner define more than one Organizational Domain within the same domain space, which is useful for segmenting mail sources and managing policies distinctly at different levels. For example, setting psd=n at a.b.example.com makes it an Organizational Domain: its subdomains inherit the record, while b.example.com and c.example.com will instead inherit example.com‘s record.
DMARC Aggregate Reporting (RFC 9990)
The DMARC Working Group removed aggregate reporting from the original DMARC RFC and created a dedicated RFC. In RFC 9990 DKIM was previously optional and is now required in reports; this helps with DKIM key insights and key rotation troubleshooting. Additionally, the RFC modernizes the XML format to make reports more uniform and easily digestible for associated tools and picks up data points from the new DMARC specification.
Failure Reporting (RFC 9991)
The publication of RFC 9991 includes a standardized abuse reporting format (ARF) and requires receivers to include specific fields, like failures and DKIM/SPF authentication results. It also speaks to the long-standing problem of exposing PII and focuses on redaction and transport security along with introducing third-party verification guidelines so RUF reports are contained.
What domain owners should do in response to the new RFCs
First and foremost, the DMARC specification changes won’t break your current DMARC setup; RFC 9989 is compatible with RFC 7489, but complying with the new standards aligns your domain security with best practices.
With the publication of the fresh DMARC RFCs, existing v=DMARC1 records remain valid and continue to be the industry standard for email security. You can, however, examine your DMARC records to ensure they are in line with the amended DMARC specification:
- Remove obsolete pct (percentage), rf (report format) and ri (report interval) tags.
- Add the new np (non-existent policy), psd (Public Suffix Domains), and t (testing mode) tags as needed.
Here’s an example of how the new tags appear in DMARC record:
v=DMARC1; p=reject; np=quarantine; psd=y; t=y; rua=mailto:[email protected]As with any change to an internet standard, provider adoption takes time. If a new tag does not produce the expected result, the provider has likely not implemented it yet. Support will roll out gradually and not simultaneously across providers.
—Ash Morin, dmarcian Director of Professional Services
dmarcian is here to help
Effective DMARC deployment and maintenance is crucial in fighting phishing and spoofing, and we offer the resources and expertise you need to get it right the first time.
We help organisations of all sizes:
- Deploy DMARC the right way—no guesswork, no disruptions
- Gain full visibility into your email ecosystem
- Stay ahead of evolving email security policies
Want to continue the conversation? Head over to the dmarcian Forum.