Why DMARCbis and why now
RFC 7489, published in 2015 as an Informational document, left three gaps: the pct tag allowed policies to apply to only X% of messages, diluting protection and making receiver behavior unpredictable; the absence of a dedicated policy for non-existent subdomains left a gap exploitable for phishing; and reliance on the Public Suffix List (PSL) to identify the organizational domain created inconsistencies between MTA implementations, since the PSL is maintained outside the IETF. RFC 9989 (core DMARC), RFC 9990 (aggregate reporting) and RFC 9991 (failure reporting) address each of these gaps, elevating DMARC to Proposed Standard status.
- RFC 9989 (core DMARCbis) — obsoletes RFC 7489 and RFC 9091; introduces the
nptag, removespct, replaces it with thettag (test mode), and defines Tree Walk DNS to identify the parent domain without relying on the PSL - RFC 9990 (aggregate reporting) — extracts and modernises the aggregate reporting section of RFC 7489; XML reports compressed as GZIP remain the format but external destination verification is strengthened
- RFC 9991 (failure reporting) — extracts failure reporting; emphasises privacy risks and mandates rate limiting at generators to prevent DoS abuse
- Removal of
pct— any existing DMARC record carryingpct=50(or any other value) must be reviewed; RFC 9989-compliant receivers may ignore this tag or apply the policy to 100% of messages - Tree Walk DNS — the receiver climbs the DNS tree via successive queries (capped at 8) to find the applicable policy, removing the PSL dependency and improving cross-implementation consistency
Prerequisites before making changes
Before any modification, confirm your infrastructure meets the basics: SPF and DKIM must be correctly configured on your sending domain — DMARCbis adds nothing to these mechanisms but depends entirely on them. Also ensure your audit tools (dig, nslookup, SSH access to your VPS) are available and that you have access to your DNS zone. Finally, gather your current DMARC aggregate reports (via rua) to establish a baseline of legitimate traffic before tightening policy.
Audit your current DMARC record
Run
dig TXT _dmarc.example.comfrom your VPS or terminal. Note the exact value of each tag:v,p,sp,pct,rua,ruf,adkim,aspf. Ifpctis present with a value below 100, plan its removal.Remove or replace the `pct` tag
In RFC 9989,
pctis deprecated. Its progressive deployment role moves to thettag:t=yinstructs the receiver to treat the message as if the policy werep=none, without applying quarantine or rejection. To migrate smoothly frompct=50, replace witht=y, validate over a few weeks via your aggregate reports, then dropt=y. Migration example:v=DMARC1; p=quarantine; t=y; rua=mailto:[email protected]Add the `np` tag for non-existent subdomains
The
nptag defines the policy to apply to messages claiming to come from a subdomain that does not exist in your DNS. Withoutnp, RFC 9989 falls back tosporp. To block phishing via non-existent subdomains, addnp=reject. Full example:v=DMARC1; p=quarantine; sp=quarantine; np=reject; rua=mailto:[email protected]Understand Tree Walk DNS and publish at the right levels
With Tree Walk, a receiver processing a message from
mail.app.example.comqueries_dmarc.mail.app.example.com, then_dmarc.app.example.com, then_dmarc.example.com, stopping at the first valid response (maximum 8 DNS queries). Audit your DNS zones to detect unintentional_dmarc.*records that could override your root policy.Update your final DNS record
Once tags are reviewed, publish the updated record. Full example for a domain in hardening phase:
v=DMARC1; p=quarantine; sp=quarantine; np=reject; adkim=s; aspf=s; rua=mailto:[email protected]; ruf=mailto:[email protected]; fo=1Check DKIM alignment in Postfix
Ensure
adkim=s(strict) does not conflict with subdomains signing under a different key. In strict mode, theFrom:header domain must exactly match the DKIMd=domain. If in doubt, temporarily useadkim=r(relaxed) and analyse aggregate reports.Check DKIM alignment in Exim
Verify in your Exim configuration that
dkim_domainexactly matches the domain published in your DMARC record. Any mismatch underadkim=scauses a DKIM failure and may trigger quarantine or reject policy.Test and validate reports
Wait 24 to 48 hours and parse the aggregate XML reports received at your
ruaaddress. The<policy_evaluated><dkim>and<policy_evaluated><spf>fields show whether your messages pass alignment. Tools like MXToolbox DMARCAnalyzer or mail-tester.com can parse these reports without requiring you to write code.
To quickly validate your DMARC record from your VPS, run dig TXT _dmarc.example.com +short then paste the value into MXToolbox's DMARC checker (mxtoolbox.com/dmarc.aspx). It detects unknown tags, pct/t conflicts, and reports whether the record is syntactically valid under RFC 9989. To simulate a Tree Walk, run dig TXT _dmarc.subdomain.example.com and dig TXT _dmarc.example.com in sequence and compare the policies returned at each level.
Troubleshooting common scenarios
Most issues have a deterministic root cause — here are the most common ones and how to fix them.
pctignored by a receiver — If RFC 9989-compliant MTAs ignore yourpct=50and apply the policy to 100% of messages, your aggregate reports will show a sudden increase in rejections or quarantines. Addt=yimmediately to switch to test mode while you adapt your infrastructure.nppolicy too strict — If a legitimate service sends from a subdomain not published in DNS,np=rejectwill block those messages. Start withnp=quarantineand analyse reports before moving toreject.- Tree Walk produces an unexpected policy — If you find an orphaned
_dmarc.app.example.comrecord left over from a former service, Tree Walk receivers will apply it first. Delete unused_dmarc.*records after a full DNS zone inventory. - Aggregate reports empty or missing — Verify that the
ruaaddress is reachable and your MX accepts XML reports compressed as GZIP. Some spam filters block.gzattachments. Also check the maximum message size accepted by your report reception server. adkim=smismatch with multi-domain Postfix — If you use one Postfix instance for several domains and the DKIM key signs underexample.comwhileFrom:containsnewsletter.example.com, strict alignment will fail. Either add a dedicated DKIM key per subdomain or switch toadkim=rfor those domains.
RFC 7489 vs RFC 9989: the differences that matter
The table below summarises the structural differences between the two specifications.
Scroll the table
| Point | RFC 7489 (2015) | RFC 9989 (2026) |
|---|---|---|
| `pct` tag | Present — applies policy to X% of messages for progressive rollout | Removed — replaced by `t=y` (test mode); every compliant receiver applies policy to 100% of messages |
| Non-existent subdomains | No dedicated tag — `sp` or `p` applies by default | `np` tag introduced — distinct policy for subdomains absent from DNS |
| Parent domain discovery | Based on the Public Suffix List (PSL), maintained outside IETF, varies by implementer | Tree Walk DNS — climbs the DNS tree via successive queries, capped at 8, defined in the standard |
| Reporting | Aggregate and failure reporting in a single RFC 7489 | Three separate RFCs: 9989 (core), 9990 (aggregate), 9991 (failure) — better extensibility |
| Status | Informational — reference value but not on Standards Track | Proposed Standard (Standards Track) — full IETF authority, basis for future MTA implementations |
Adapt now or deal with it later
DMARCbis is not yet uniformly enforced by all MTAs — Google, Microsoft and Yahoo have announced Tree Walk testing phases but no hard cutoff date has been communicated. This is not a reason to wait: RFC 9989, 9990 and 9991 are on the Standards Track, progressive implementation is underway, and the first pct interpretation divergences between receivers are already appearing. Removing pct, adding np and auditing your DNS zones for Tree Walk are defensive steps that break nothing on receivers still on RFC 7489 — np is ignored by older MTAs, and removing pct only has an effect if the receiver already enforces RFC 9989. The cost of adapting is low; the cost of a policy partially applied by a mixed receiver population is not.
