The end of the pct tag: DMARCbis's t= testing mode

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

How to roll out DMARC gradually, without pct

The disappearance of pct doesn't change the deployment method — it actually makes it clearer. The sequence stays the one described in how to get to p=reject without breaking email:

1. p=none — pure observation. Reports come in and the senders get inventoried.
2. Aligning every legitimate source (SPF/DKIM), until the reports are clean.
3. p=quarantine with t=y — quarantine declared in testing mode: a check that no forgotten legitimate source would fall, with no real risk.
4. Removing t=y — quarantine actually applies.
5. p=reject (optionally with t=y first, then without) — full enforcement.

Instead of an imprecise percentage slider, there's a clean switch: test or real. Granularity no longer comes from "how much" (the percentage) but from "what" (which policy, on what scope — root, subdomains via sp, non-existent ones via np).

What happens to a pct left in the record

No harm done. DMARCbis-updated implementations simply ignore pct. Leaving it breaks nothing, but it no longer does anything — removing it keeps the record clean. It's one of the small steps in migrating to the new standard, along with adding np.

A nuance during the transition

As always with DMARCbis, the ecosystem updates gradually. For a while, two populations coexist:

• updated receivers, which understand t and ignore pct;
• older receivers, which ignore t (and therefore apply the policy fully, even with t=y).

Practical consequence: t=y is no absolute safety net with older receivers — some will apply p=quarantine for real. That's why real safety remains ramping in steps while watching the reports: t=y helps with observation, but it's the cleanliness of the reports that signals readiness, not the tag. To read those reports, see how to read aggregate reports.

A real rollout, week by week

To make the sequence concrete, here's what a mid-size domain's ramp might look like, with the records at each step.

Week 1 — observation. The record goes up:

v=DMARC1; p=none; rua=mailto:reports@example.com

Nothing else changes. Reports start arriving; the sources surface one by one (mail platform, CRM, billing, a forgotten tool).

Weeks 2 to 4 — alignment. Aligned SPF and DKIM get configured for each legitimate source, until the reports show them all green. The record doesn't change yet: the work happens "under the hood."

Week 5 — quarantine in test. Quarantine gets declared, but in testing mode:

v=DMARC1; p=quarantine; t=y; rua=mailto:reports@example.com

With t=y, the reports show what would be sent to spam without risking a forgotten legitimate source landing there. A few days of watching follow.

Week 6 — real quarantine. Reports clean? t=y comes out:

v=DMARC1; p=quarantine; rua=mailto:reports@example.com

Week 7 — reject. Same logic: optionally p=reject; t=y for a few days, then t=y comes out and np=reject goes in to lock down non-existent subdomains. Enforcement is reached.

This timeline is indicative — a small domain will go faster, a large estate slower (see how to get to p=reject). The key point: it's the state of the reports, not the calendar, that authorizes each move.

What to look for during a t=y window

The test window is only useful when its purpose is clear. During a t=y phase, the failing traffic in the reports splits into two piles. First, recognized sources — a platform, a tool, a partner sending on the domain's behalf — that still fail alignment: each one is a task to finish before the flag comes out, because under the real policy it would have been caught. Second, unrecognized sources: those failures are the policy doing exactly its job, evidence it will bite the right traffic. The window has done its work when the first pile is empty and only the second remains. The window should also be sized to the sending rhythms — a quiet week can hide an infrequent but important sender.

Three mistakes to avoid with t

• Confusing t=y and pct=100. t=y doesn't "reduce" enforcement to a sample: it signals a testing mode that only updated receivers respect. It's not a percentage substitute, it's something else — an experimentation flag.
• Staying at t=y forever. Testing mode is a transition step, not a destination. As long as t=y is there, updated receivers don't really apply the policy: the domain isn't actually protected. It comes out as soon as the reports are clean.
• Believing t=y protects everywhere. Older receivers ignore t and apply the policy fully. So even with t=y, a p=reject may bite for some. A strict policy is only worth declaring once it can be owned everywhere.

Frequently asked questions about t

Is t=y mandatory? No. It's a useful observation tool during a tightening, but the ramp p=none → quarantine → reject works perfectly well by simply watching the reports at each step, never touching t.

Does t=y replace the p=none step? No, they're two different things. p=none asks no action of receivers; t=y with p=quarantine or p=reject tells them "here's my real target, but I'm still testing." t=y is useful after p=none, to move up a rung with a safety net.

Will my old pct=50 cause a problem? No — it will simply be ignored by updated implementations. The next record change is the occasion to remove it.

t, deliverability, and what receivers really do

A common confusion is worth clearing up: t=y is not a deliverability setting. It doesn't tell providers "be nicer to my mail"; it says "this policy is being tested, don't enforce it strictly yet." Deliverability depends on other factors — IP reputation, complaint rate, real alignment — not on the presence of t.

What receivers do with t=y varies. DMARCbis-updated implementations respect it: they send the reports as if the policy were active, but don't actually quarantine or reject the mail. Older implementations, which don't know t, ignore it and apply the policy fully. Practical consequence: during the transition, t=y is a partial safety net, not a total one.

The right use, then: t=y as an observation window during a tightening, knowing some receivers will already apply the policy for real. The aggregate reports get watched; as soon as they're clean, t=y comes out and the policy bites everywhere. Getting stuck at t=y "to be safe" is the trap: it means trusting a protection that updated receivers aren't enforcing at all. Safety is clean reports before tightening — not a test flag left lying around indefinitely.

It also helps to think of t as documentation of intent. A record that reads p=reject; t=y tells anyone inspecting it — a colleague, an auditor, a successor — "the target is reject, and we're in the final test phase." That clarity is worth something on a control that may have to be explained months later, long after the rollout details have faded from memory.

In short

DMARCbis removes the pct tag (percentage-based rollout, deemed unreliable) and replaces it with t, a binary testing mode: t=y signals "policy under test, don't enforce it strictly yet." Ramping is now driven by watching the reports, not by a percentage. t=y is a transition step to remove as soon as the reports are clean — never a destination. Used that way — briefly, then removed — it's a genuinely useful safety net on the road to enforcement, not a substitute for it.

Thomas drives the ramp

Choosing the right moment to remove t=y, moving from quarantine to reject, checking that no source falls: that's exactly the kind of decision Thomas, the virtual CISO, makes on real data. He generates the DMARCbis record for each step and signals when the next one is safe.

Free domain analysis or creating an account. For the full context, see this new standard explained simply.