DMARCbis: the complete implementation guide for senders (2026)

Q: How is t=y different from pct?

pct asked receivers to apply the policy to a random share of messages, which was unpredictable. t=y declares that the whole record is in testing: receivers evaluate and report but do not necessarily enforce, so you get clean data before committing.

DMARCbis is the IETF revision of DMARC (RFC 7489) — an evolution, not a rupture. The pct tag is removed, the np (non-existent subdomain) and psd (Public Suffix Domain) tags are added, and t=y test mode replaces partial deployment. Mailbox-provider enforcement should roll out from Q4 2026 through 2027. Audit your current DMARC and resolve every failure before migrating.

What is DMARCbis, and why it matters

DMARCbis is the in-progress IETF revision of DMARC (Domain-based Message Authentication, Reporting and Conformance, RFC 7489). It clarifies ambiguous behaviours, removes deprecated mechanisms such as the pct tag, and adds explicit handling for Public Suffix Domains and non-existent subdomains. For most senders it is an evolution rather than a revolution — but legitimate forwarders, mailing lists and complex multi-source senders will feel the difference.

From RFC 7489 to DMARCbis

DMARC was published as an informational RFC in 2015 — never a formal Standards-Track document, but a specification of running code contributed by large senders and mailbox providers. That origin left ambiguities: how policy is discovered across organisational boundaries, how non-existent subdomains are treated, and how partial deployment actually behaves. DMARCbis is the IETF working group turning DMARC into a proper Standards-Track document, folding in a decade of operational experience.

Policy discovery was under-specified. The original spec leaned on the Public Suffix List, a community-maintained artefact rather than an IETF standard. DMARCbis introduces explicit tree-walk discovery and PSD handling.
The pct tag was unreliable. Partial deployment was applied inconsistently by receivers. DMARCbis removes it in favour of a clean t=y test mode.
Non-existent subdomains were a spoofing gap. Attackers spoof subdomains that were never meant to send mail. The np tag sets an explicit policy for them.

Who needs to care, and when

B2B sender, 5k+/day, clean p=reject: low urgency — audit and adjust syntax.
B2B sender on p=none or p=quarantine: medium — plan a progressive migration.
Multi-source sender (ESP, transactional, tools): high — a full audit is recommended.
ESP, host or multi-tenant SaaS provider: critical — you must understand PSD policy.
TLD, registry or PSL operator: critical — PSD policy is mandatory.

If you already run DMARC at p=reject with every source aligned, DMARCbis is a light syntax review. If you are stuck at p=none, send from many sources, or operate infrastructure for other people’s domains, this is the moment to get your authentication in order. Existing records stay valid: nothing breaks on day one.

DMARC vs DMARCbis: what actually changed

DMARCbis keeps the core intact — SPF and DKIM alignment, the p= policy, rua and ruf reporting — and changes the edges. In short: pct and rf are gone, np, psd and t=y are new, and policy discovery is now explicitly specified instead of relying informally on the Public Suffix List.

pct (percentage of messages): removed.
rf (report format): removed, AFRF only.
np (non-existent subdomain): new.
psd (Public Suffix Domain): new.
t=y (test mode): new, replaces pct.
Policy discovery: organisational domain plus an explicit tree walk and PSD lookup.
Forwarding and mailing lists: clarified, with ARC encouraged.
Alignment, reporting, backward compatibility: unchanged — existing records remain valid.

What was removed

The pct tag. Under DMARC, pct=10 told receivers to apply the policy to roughly 10% of messages. It was implemented inconsistently and often used as a crutch to avoid full enforcement. Phased rollout is now handled by test mode plus subdomain policies, which is far more predictable.

The rf tag. It nominally let senders request a forensic report format, but everyone used AFRF and the tag carried no useful signal.

What was added

The psd tag. A Public Suffix Domain is a domain under which independent organisations register names — .com, .co.uk, or a managed platform where each tenant gets a subdomain. DMARCbis lets the operator publish a policy that protects the boundary. This matters to TLD operators, registries and multi-tenant SaaS providers, and was not expressible under RFC 7489.

The np tag. It sets the policy for subdomains that do not exist in DNS — names an attacker would only ever spoof. You can keep p=none and still set np=reject, closing that gap without touching legitimate mail from real subdomains. It complements sp, which governs existing subdomains.

Test mode, t=y. It declares that the record is being tested: receivers evaluate and report, but do not necessarily enforce. That gives you a clean way to validate a new policy against real aggregate reports before committing — the role pct filled badly.

Timeline: when DMARCbis becomes the standard

DMARCbis is still an IETF draft in 2026, in late-stage working-group process. There is no hard cutover date like the Gmail and Yahoo mandate of February 2024. Expect mailbox-provider support to phase in from Q4 2026 through 2027 and 2028. Prepare now, but do not panic.

2026: the draft finalises, tooling vendors add DMARCbis-aware parsing. Senders audit and clean up.
2027: the RFC is likely published, receivers begin honouring np and psd. Senders move to enforcement.
2028: DMARCbis behaviour becomes the default expectation, and senders still on p=none see placement degrade.

Gmail, Yahoo and Microsoft helped author DMARC and take part in DMARCbis, so adoption is expected — but gradual and quiet. Do now: audit DMARC, inventory every sending source, fix alignment failures, add np protection. Wait for: anything that depends on universal receiver support of psd, unless you are a PSD operator yourself.

How DMARCbis changes deliverability

DMARCbis does not add a new spam filter. It tightens the authentication layer that filters already trust, so the impact is indirect but real: cleaner policy discovery and explicit non-existent-subdomain handling reduce spoofing and protect your domain reputation, while a sloppy migration breaks alignment and sends legitimate mail to spam.

Stricter policy discovery. With explicit tree-walk discovery, receivers find and apply the correct organisational policy more reliably. If subdomains inherit a policy you did not intend, their mail can be quarantined or rejected — map subdomain sending before you enforce.
Non-existent subdomain protection. np=reject stops attackers spoofing subdomains you never use. A low-risk, quick reputation win.
Forwarders and mailing lists. Forwarding breaks SPF and can break DKIM, so wanted mail fails. DMARCbis encourages ARC, which lets a trusted forwarder vouch for the original authentication. Validate ARC before enforcing if your audience is list-heavy.
Reporting. Aggregate reports remain the backbone. Make sure your aggregator understands the new tags rather than dropping them.

Common pitfalls: enforcing before every source failure is resolved; forgetting a sending source; setting np=reject while real mail comes from a subdomain that is not properly in DNS; assuming every receiver already supports the new tags.

Step by step: migrating from DMARC to DMARCbis

The flow is: audit, inventory your sources, fix failures, update syntax, run test mode for 30 to 60 days, enforce, monitor, document. Never enforce before the failures are resolved.

1. Audit your current DMARC posture

Pull your _dmarc record, note the policy, and collect two to four weeks of aggregate reports. The usual mistake is judging your posture from the record alone. Allow one to two days, plus the reporting window.

2. Inventory every sending source

List every system that sends as your domain — ESP, transactional platform, CRM, billing, automation, support desk — and confirm each one is listed in SPF and signs with DKIM, with alignment. Aggregate reports reveal the sources everyone forgot. Allow two to four days.

3. Resolve all DMARC failures before migrating

Fix SPF (stay under ten DNS lookups, flatten if needed), publish or repair DKIM with 2048-bit keys, and align every source. The usual mistake is treating symptoms instead of aligning the source. Allow one to three weeks.

4. Update your record syntax

Drop pct= and rf=, add np= for non-existent subdomain protection, and add psd=y only if you genuinely operate a public suffix domain. Less than a day of work.

5. Test in t=y mode for 30 to 60 days

Publish with t=y, watch aggregate reports for failures and iterate. The usual mistake is cutting the test window short.

6. Enforce, from quarantine to reject

Move from none or test mode to p=quarantine, monitor, then go to p=reject. Mirror the move with np and sp. Do not jump straight to reject. Allow two to four weeks, staged.

7. Monitor with a DMARCbis-compatible aggregator

Keep reading aggregate reports, alert on new failing sources, and watch how np and PSD boundaries are evaluated. Monitoring does not stop once you enforce.

8. Document and maintain

Record every source, its owner and its DNS entries, then set a quarterly review. The usual mistake is having no one who owns deliverability.

DMARCbis record syntax, with examples

DMARCbis records look almost identical to DMARC records, and existing records stay valid. The differences are the removed pct and rf tags and the new np, psd and t=y.

Minimal record, in test mode

_dmarc.example.com. IN TXT "v=DMARC1; p=none; t=y; rua=mailto:dmarc@example.com"

The safest starting point: no enforcement, test mode on, and a reporting address. While testing, it is worth setting np=none and sp=none explicitly, so reports show what would happen before you tighten anything.

Ready for quarantine

_dmarc.example.com. IN TXT "v=DMARC1; p=quarantine; np=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:forensic@example.com"

Full enforcement

_dmarc.example.com. IN TXT "v=DMARC1; p=reject; np=reject; adkim=s; aspf=s; rua=mailto:dmarc@example.com; fo=1"

PSD policy, for a TLD or PSL operator

_dmarc.example.tld. IN TXT "v=DMARC1; p=none; psd=y; rua=mailto:psd-reports@example.tld"

Use psd=y only if you genuinely operate a public suffix. Because DMARCbis is still a draft, records using these tags are forward-compatible: providers that do not support them yet simply ignore them, so there is no downside to deploying np today.

Tools and monitoring

You manage DMARCbis the way you manage DMARC: publish a record, collect aggregate reports, act on them. The only new requirement is an aggregator that understands np, psd and t=y. The major platforms are adding that support as the draft stabilises — ask your vendor whether the new tags are surfaced or silently dropped.

Aggregate reports are XML summaries per source. Read them for sources failing alignment, volume per source, and how non-existent subdomains and PSD boundaries are evaluated. A clean report shows every legitimate source passing SPF or DKIM, with alignment. Forensic reports give per-message detail but are sparsely supported for privacy reasons: treat them as a bonus, not a primary signal.

Under 5,000 messages a day: review weekly.
5,000 to 100,000 a day: review daily.
Above 100,000 a day: review daily, with automated alerts.

When to call a deliverability expert

Most healthy single-source senders can migrate with this guide alone. Bring in help when complexity, your role in the infrastructure, or unexplained failures raise the cost of getting it wrong — a botched enforcement step rejects real mail and damages your reputation for weeks.

You have three or more distinct sending sources and are not sure they are all aligned.
Your DMARC sits at p=none and you have never reached enforcement.
You operate as an ESP, a host or a multi-tenant SaaS, so PSD policy applies and the blast radius is large.
Your reports show failures you do not understand.

A MailSoar readiness audit covers the full authentication review (SPF, DKIM, DMARC, ARC and alignment), a complete map of every sending source, root-cause analysis of report failures, an np, psd and t=y strategy for your setup, and a staged migration plan with a monitoring runbook.

A recent case. A B2B SaaS sending from five sources sat on p=none for two years, afraid that enforcement would break invoicing mail. The audit mapped all five sources and found two unaligned — a billing platform and a support desk. After fixing alignment and running 45 days in test mode, the domain moved to p=reject without losing a single legitimate message, and spoofing attempts dropped to zero in the reports.

DMARCbis FAQ

What is DMARCbis in simple terms?

The updated version of DMARC, the email authentication standard that tells receivers what to do with mail failing SPF and DKIM. It removes an unreliable tag (pct), adds protection for non-existent subdomains (np) and public suffix domains (psd), and clarifies policy discovery. Existing records keep working.

When will DMARCbis officially replace DMARC?

There is no fixed date. It was an advanced IETF draft in 2026, a Standards-Track RFC is likely in 2027, and mailbox-provider behaviour should phase in through 2027 and 2028.

Is DMARCbis backward compatible?

Yes. Existing records remain valid and receivers ignore tags they do not recognise, so you can deploy np today with no downside.

Do I need to migrate in 2026?

There is no rush, but prepare: audit your DMARC, fix the failures, add np. ESPs and multi-tenant platforms should start looking at PSD policy now.

What is the np tag?

It sets the policy for non-existent subdomains — names that are not in DNS and that attackers might spoof. You can set np=reject while keeping p=none and close that gap at very low risk.

What is a PSD?

A Public Suffix Domain is a domain under which independent parties register names, such as .com or a multi-tenant platform domain. The psd tag lets the operator publish a protective policy, which matters to registries, TLD operators and SaaS hosts.

What happened to the pct tag?

It was removed. Receivers implemented it inconsistently and senders used it to avoid full enforcement. Phased rollout now uses t=y test mode.

How is t=y different from pct?

pct asked receivers to apply the policy to a random share of messages, which was unpredictable. t=y declares that the whole record is in testing: receivers evaluate and report but do not necessarily enforce, so you get clean data before committing.

Will DMARCbis break my mailing lists?

Not in itself, but lists and forwarders break SPF and sometimes DKIM, which causes failures. DMARCbis encourages ARC to solve this. Validate ARC before enforcing if your audience is list-heavy.

Does Gmail support DMARCbis yet?

Google takes part in the process and enforces the 2024 bulk sender rules today. Full support will phase in quietly as the RFC finalises.

Can I publish a DMARCbis record if my provider does not support it?

Yes. The new tags are forward-compatible and unsupported receivers ignore them, so deploying np now is a safe win.

How long should I stay in test mode?

Thirty to sixty days for most senders — long enough to capture the full range of sources and edge cases before enforcement.

Does DMARCbis require ARC?

No, but it strongly encourages it for legitimate forwarders and mailing lists, because ARC preserves the original authentication result across intermediaries.