DMARCbis is the next revision of DMARC from the IETF. It will replace RFC 7489 and RFC 9091 and is tracked as a Proposed Standard. Your existing records keep using v=DMARC1.
Start planning now so you are ready to adopt when published.
What is DMARCbis: A quick refresher
DMARCbis keeps the same goal. It lets you specify which sending sources using your domain are real and how receivers should handle mail that fail those checks. The update clarifies the spec, formalises conformance, and changes how the organisational domain is found using a DNS Tree Walk rather than the Public Suffix List.
What actually changes, and why it helps with complex domains:
- Discovery and alignment are cleaner: Receivers look for a DMARC record at the Author Domain, then the Organisation Domain, and finally the Public Suffix Domain. DMARCbis defines the Tree Walk used for both policy discovery and alignment.
- Public Suffix List (PSL) is out; Tree Walk is in: The Tree Walk is due to replace the PSL lookups, meaning that you can get consistent boundaries even with nested subdomains and PSD records.
- Conformance is explicit: Full DMARC participation states you should publish records for each Author and Organisational Domain, send mail that aligns via SPF and DKIM, and consume aggregate reports.
- Better for decentralised DNS: Records are available to be published at multiple levels. For very deep hostnames, add a record at the Author Domain so it’s found before the walk.
Your updates are in the tags
Use the table below to map old to new: set [t] for testing, use [np] if you want a rule for non-existent names, set [psd] only if you operate a public suffix, remove [pct], [rf], [ri], and keep [v=DMARC1].
Tags overview
Tag | Plain Meaning | When to use it | Options | Example |
[t] | Test mode signal for the policy you set in p, sp, or np | Turn on while you test; turn off for normal operation | [y] testing enabled, do not apply specified policy but apply any special handling rules | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com |
[psd] | Marks a record as published by a Public Suffix Operator, and guides Tree Walk | Only set if you operate a public suffix domain (registry or similar).Most domains will not need to explicitly declare this tag | [y] = domain is a PSD [n] = domain is not a PSD | v=DMARC1; p=quarantine; psd=y; rua=mailto:dmarc@example.com |
[np] | Policy for mail that uses names that do not exist under your domain | Use if you want an explicit rule for fake/typo subdomains | [none], [quarantine], [reject] | v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com |
[rf], [ri] | Old hints for failure report format and aggregate report interval | Remove from legacy records | - | - |
[pct] | Old percentage rollout control | Replace with [t] testing, don’t use in new records | - | See below |
Get ready for DMARCbis with Red Sift OnDMARC
[Pct] -> [t] mapping
- [pct=0] -> use [t=y]
- [pct=100] -> omit the tag, no need to explicitly declare t=n
- [pct=1-99] -> no direct equivalent; use [t=y] and manage risk in testing (e.g. on lower impact domains).
DMARCbis record update: 5 quick checks
1. Find your records
List the DMARC record at your Organisational Domain and any records at key subdomains. Note any legacy tags pct, rf, or ri. These are now deprecated in DMARCbis.
2. Update tag syntax
If you are not yet at pct=100, replace pct with the new test flag t. pct equals zero maps to t equals y. If you are at pct=100, you can remove the pct tag. Remove rf and ri. Leave psd out unless you actually operate a public suffix domain. Keep v equals DMARC1.
3. Set policy scope
Decide p for the base domain and sp for existing subdomains. Add np if you want a rule for mail to names that do not exist, for example np equals reject. If np is missing, receivers fall back to sp then p.
4. Pick alignment modes
Use adkim and aspf. (r means relaxed and s means strict). Choose strict if you want exact matches between the authenticating domain and your From domain.
5. Review reporting
Keep rua for aggregate reports. Use ruf with fo only if you need per message failure detail. Many receivers do not send failure reports and some refuse them for privacy reasons. Plan for that.
Why Red Sift OnDMARC?
DMARCbis changes how policy is found and which tags you use. Red Sift OnDMARC has native support for this, tying DMARC, SPF, and DKIM together so you can ship the update fast.
- One place for DMARC, SPF, DKIM - Edit records side-by-side, see alignment [adkim/aspf] outcomes, and fix the gaps that block enforcement.
- Built for Tree Walk - See the node the walk will hit (Author -> Org -> PSD) and where to publish for deep subdomains.
- Step-by-step tag updates - Use [t], [np], [psd]; remove [pct], [rf], [ri]; keep [v=DMARC1]. The builder prompts you as you go.
- SPF at scale - Dynamic SPF handles the 10-lookup cap with a single include that expands at query time.
- Safer rollout - Model don’t [t=y] (one level softer) before you go live, then push changes in bulk across brands and regions.
- Clear reporting - Aggregate views highlight misalignment by source so you know what to fix next.
Talk to our team for a quick review of your records, and run a free Investigate check to see what receivers report for your domain.