DMARCbis is the working title of what will become the next revision of the DMARC standard, replacing RFC 7489 and RFC 9091. Due to DMARC’s importance to the internet, it is now stewarded by the IETF as a proposed Internet Standard.. DMARC policy records will continue to begin with v=DMARC1.
Begin preparing now so you are ready to adopt when published.
What is DMARCbis: A quick refresher
DMARCbis maintains the same goal of enabling you to declare a policy of how email receivers should treat unauthorised email sent on behalf of your domain, and providing reporting that enables you to identify authorised and unauthorised email flows. Authorisation still requires configuring DKIM and/or SPF for each email flow. 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: Today, receivers look for a DMARC records only at the Author Domain and the Organizational Domain. DMARCbis implements a DNS Tree Walk used for both policy discovery and alignment including full support for nesting subdomains
- Public Suffix List (PSL) is out:The DNS Tree Walk also replaces the PSL lookups, meaning Public Suffix Operators (PSOs) can independently self-identify their domains as Public Suffixes without needing to be manually added to the Public Suffix List and waiting for receivers to update.
- 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 understand the upcoming changes. Do not make changes yet. It will take some time after the standard is finalized for all email receivers to implement it. Most importantly, keep [v=DMARC1] - the version number of the policy format has not changed!
Tags overview
Tag | Purpose | When to use it | Options | Example |
[psd] | Indicate whether a policy record belongs to a Public Suffix Domain or an Organizational Domain | Should be set on Organizational Domains and Public Suffix Domains (PSDs) | [y] = domain is a Public Suffix Domain Use only if you are a Public Suffix Operator [n] = domain is not a Public Suffix Domain, and is the Organizational Domain for its and its subdomains Use on Organizational Domains such as the apex of your domains [u] = not a Public Suffix Domain, may or may not be an Organizational Domain for itself and its subdomains Use on subdomains or if otherwise unsure. This is the default behaviour | v=DMARC1; p=quarantine; psd=n; rua=mailto:dmarc@example.com |
[np] | Policy for mail that uses Author Domains that do not exist under the DNS of your domain | Use for as long as you require a different policy for non-existent domains as for subdomains or domains If not set, non-existent domains will follow the subdomain or domain policy | [none], [quarantine], [reject] | v=DMARC1; p=reject; sp=quarantine; np=reject; rua=mailto:dmarc@example.com |
[t] | Test mode signal for the policy you set in p, sp, or np | Turn on when testing e.g. such as when upgrading policy; remove for normal operation | [y] testing enabled Receivers should apply a policy to failing emails one level below the specified policy and continue to apply special handling rules such as rewriting Similar to [pct]=0 previously. | v=DMARC1; p=quarantine; t=y; rua=mailto:dmarc@example.com |
[rf], [ri] | Old hints for failure report format and aggregate report interval | Deprecated. Plan to remove from your records after widespread DMARCbis implementation | - | - |
[pct] | Old percentage rollout control | Deprecated. Its purpose is fulfilled by the new [t] testing tag Recommend you already only use pct=100 or pct=0 which closely match the new supported behaviour | - | 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 longer supported; use [t=y] to manage risk while testing higher policy level
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 deprecated and will not have an effect when email receivers implement the updated standard..
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.