Moving from p=none to enforcement is a meaningful change. Aggregate reports may show that most mail is authenticated, but a small forgotten application, forwarding path, or seasonal sender can still be important.
DMARC has a test-mode tag for this situation: t=y. It lets a domain owner publish the policy they are preparing to enforce while asking receivers not to apply that policy at full strength yet.
The important detail is that t=y does not mean "ignore DMARC." It is a request to test the declared policy at the next lower enforcement level:
p=quarantine; t=y is expected to behave like none for DMARC-failing mail.p=reject; t=y is expected to behave like quarantine for DMARC-failing mail.The current DMARC specification, RFC 9989, defines this behavior and also makes clear that reporting is unaffected.
t=y changesA DMARC receiver first evaluates SPF and DKIM, including alignment with the visible From: domain. The t tag matters only when the message fails that DMARC evaluation and the applicable policy is not none.
Consider this record:
v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.comThe domain is saying, "The intended policy is reject, but this is a trial. For now, use the next less disruptive treatment for failures." Under the specification, the expected fallback is quarantine rather than rejection.
This is different from publishing p=none because the record documents the intended destination. It tells receivers, and the people reviewing DNS later, that reject is the target rather than merely a possibility.
Test mode is narrower than a general delivery bypass.
It does not:
Receivers can combine DMARC with reputation, content filtering, user settings, and local security rules. They may also have special handling for test mode, such as rewriting the visible From: address. A receiver that does not implement the signal may apply the published policy normally or handle the message using its own rules.
Test mode reduces the requested DMARC enforcement step. It is not a promise that every receiver will deliver a failing message, and it should not be used as a substitute for fixing authentication.
t=y with each policyThe useful combinations are easiest to see side by side:
| Record | Intended policy | Expected treatment of DMARC failures |
|---|---|---|
p=none; t=y | Monitoring | No change, because test mode has no effect on none |
p=quarantine; t=y | Quarantine | One level lower: none-like handling |
p=reject; t=y | Reject | One level lower: quarantine-like handling |
p=reject; t=n | Reject | Apply the published reject request |
The tag is t=n by default, so omitting t means normal policy processing. Once testing is complete, remove t=y or change it to t=n; leaving test mode in place means the domain is still asking receivers not to use the intended enforcement level.
The test signal applies to the policies declared by the record, including sp for existing subdomains and np for nonexistent subdomains when those tags are applicable.
For example:
v=DMARC1; p=reject; sp=quarantine; np=reject; t=y; rua=mailto:dmarc@example.comThis record has three intended policies, all in test mode:
reject, trialed at quarantine.quarantine, trialed at none.reject, trialed at quarantine.The policy still has to be discovered for the message's Author Domain. A t=y tag on the organizational-domain record does not override a separately published DMARC record on a subdomain.
Test mode works best as a short, observable phase rather than a permanent setting.
Start with p=none and a working rua destination while building the sender inventory.
Fix SPF or DKIM alignment for legitimate senders, especially low-volume applications and subdomains.
Publish the intended enforcement policy with t=y:
v=DMARC1; p=reject; t=y; rua=mailto:dmarc@example.comWatch aggregate reports through at least one complete business cycle. Look for legitimate sources that still fail, not only for the total failure percentage.
Send controlled test messages from known aligned and deliberately misaligned sources where that can be done safely.
Review provider-specific results. Quarantine may mean a junk-folder placement at one receiver and a gateway quarantine at another.
When the failures are understood, remove t=y and keep the intended policy, for example:
v=DMARC1; p=reject; rua=mailto:dmarc@example.comIf the reports reveal a legitimate sender, pause the transition and correct its authentication. Do not treat a low volume of failures as proof that the sender is unimportant. A single failed password-reset or invoice stream can matter more than thousands of routine messages.
pctBoth t=y and pct can appear in a rollout plan, but they solve different problems.
t=y changes the enforcement level for the policy under test. pct limits the share of applicable messages to which a policy action is applied. Neither option fixes a sender, and neither applies to messages that already pass DMARC.
For most domains, a simpler sequence is easier to reason about: monitor with p=none, trial quarantine or reject with t=y, then remove test mode. Use pct during a staged DMARC rollout when deliberately sampling enforcement is useful, and document how the two controls are expected to interact at the receivers that matter.
t=y as a monitoring recordp=reject; t=y is not equivalent to p=none in the published intent. It communicates a planned reject policy and requests a quarantine-like trial. Keep the distinction visible in change records and dashboards.
DMARC does not define a single mailbox workflow for quarantine. The result may be spam placement, a separate quarantine, extra scrutiny, or another local action. Test the providers and gateways used by real recipients.
DMARC policy is a request from the domain owner. Receiver filtering, forwarding, allowlists, and anti-abuse systems can produce outcomes that differ from the requested disposition. Aggregate reports and controlled message tests are more useful than assuming a single universal result.
The DNS record can look "strong" while the receiver is still being asked to step down one level. Set an owner and a review date for the trial, then make the final t value an intentional decision.
t=y is a bridge between monitoring and enforcement. It gives the domain owner a way to test the operational consequences of a stronger policy without immediately requesting the full consequence for every DMARC-failing message.
Use it briefly, keep aggregate reporting enabled, inspect failures by sender and domain, and remove it when the evidence supports enforcement. The goal is not to remain in test mode. The goal is to make the eventual p=quarantine or p=reject change unsurprising.