DMARC “t=” tag vs “pct=” — what changed in DMARCbis

You've seen a DMARC record with t=y and don't recognize the tag — or you're wondering whether the pct= tag you've always used still works.

Check your domain first — 10 seconds, free, no signup.
See your DMARC policy, SPF lookup count and every issue explained in plain English.
Run the free check →

What this means

RFC 9989 (the DMARCbis core standard) retires the pct tag — IANA's DMARC Tags Registry now lists it as “historic” — and registers a new t tag with status “active”, described as “DMARC policy test mode”. The t tag is binary (y/n, default n) rather than a percentage, and it steps enforcement down exactly one level for a domain owner who is still testing: with t=y, a policy of reject is applied as quarantine, and a policy of quarantine is applied as none — it has no effect once the policy is already none, and it doesn't change report generation. Source: RFC 9989, Record Tags (“t:”) and the IANA DMARC Tags Registry (pct=historic, t=active) · verified 2026-07-17.

What to do about it

Step 1. If you're still on pct=, keep it — RFC 9989 retiring the tag doesn't break existing records; receivers that haven't updated their parsers keep honoring it.
Step 2. For new deployments, prefer t=y over a low pct= value while validating a quarantine or reject policy — one flag instead of a percentage, and it's what the current standard defines.
Step 3. Don't combine t=y with p=none expecting extra caution — the tag has no effect when the policy is already none.
Step 4. Confirm your DMARC monitoring tool recognizes the t tag before relying on it — RFC 9989 is only months old.

Frequently asked

Do I need to change my DMARC record because of DMARCbis?

No, not immediately. RFC 9989 keeps the same v=DMARC1 tag syntax your current record uses — it mainly changes how receivers discover the record (the DNS Tree Walk) and adds optional new tags like t= and np=. Nothing about your existing record becomes invalid.

Is DMARCbis a completely different standard from DMARC?

No — RFC 9989 explicitly obsoletes RFC 7489 as a refinement of the same DMARC standard, based on years of implementation experience. Aggregate and failure reporting moved into their own documents, RFC 9990 and RFC 9991, all published May 2026.

Where can I read the actual standard instead of a summary?

RFC 9989 (core), RFC 9990 (aggregate reports) and RFC 9991 (failure reports) are all published free at rfc-editor.org, no registration required.

Don't want to babysit DNS records?
DMARCKeeper monitors your reports, names every sender, and walks you to full p=reject protection.
Start free monitoring →