DMARC is in test mode, so the policy is not applied

HighConfirmedemail.dmarc.test-mode

What this check looks for

Your record states a policy and then, with t=y, asks receiving mail servers not to act on it. The record reads as strict, but receivers apply the policy one step weaker than the one written down — p=reject is treated as quarantine, and p=quarantine is treated as none.

Why it matters

This is the gap between what your record looks like and what it does. Anyone reading p=reject — you, an auditor, a customer's security questionnaire — concludes that forged mail from your domain is refused. It is not: receivers were told to stand down. A domain can sit in this state for years because nothing about it looks wrong.

When the check passes, your report says: “The published policy is the one receivers apply”.

What it costs your score

When this check fails it removes 14 points from your Email authentication score, before the status, confidence and repeat multipliers are applied. Email authentication carries a weight of 15 in the overall score.

It shares the email-auth.dmarc family ceiling of 40 points: however many findings that family produces, together they cannot remove more than that from Email authentication. One underlying problem showing up in several places is still one problem.

Severity: high
Default confidence: confirmed
Status when triggered: fail
Deduction: 14 points
Family cap: email-auth.dmarc · 40
Category: Email authentication
Module: Email dmarc
Fix owned by: dns host
In the ruleset since: 2026.09

How the whole score is calculated

How to fix it

Remove the t=y tag so the policy you publish is the policy receivers apply.

Test mode is a rollout step, not a configuration. While it is set, your effective policy is ‹effective policy› — so if that is the protection you want, publish it as p=‹effective policy› and say what you mean; and if it is not, remove the tag.

There is a legitimate reason to be here: t=y lets you publish the policy you intend to end at while receivers still apply the weaker one, so you keep getting aggregate reports under the real record without risking delivery on the day you publish it. If you set it deliberately in the last few weeks, this finding is a reminder rather than a fault — but give it a date.
Read the aggregate reports at the rua= address and confirm no legitimate sender is failing alignment. That is the same evidence you would gather before any policy step, and it is the only thing that makes removing the tag safe.
Delete t=y from the record. Do not replace it with t=n: n is the default, and an absent tag is clearer than a tag that says "no".
If the reports show a sender you have not fixed yet, step the policy down honestly instead — publish p=‹effective policy› with no t tag — rather than leaving a stricter policy on display that nobody applies.

How to confirm it worked

dig +short TXT _dmarc.‹domain› — the record must not contain a t=y tag
Send a message that fails authentication from a test sender and confirm the receiving mailbox treats it the way p=‹policy› says it should.
Use "Test again" on this finding once the tag is removed.

A named slot like ‹domain› — and the braces left in the configuration below — is filled in with your own values when this rule appears on a report.

Remediation by platform

Generic DNS

_dmarc.‹domain›. 3600 IN TXT "v=DMARC1; p=‹policy›; rua=mailto:‹rua address›"

The same record with t=y dropped. This raises enforcement from ‹effective policy› to ‹policy› at every receiver, so treat it as a policy change and not as tidying: any sender still failing alignment will start being handled by ‹policy›. Rollback is re-adding t=y to this one TXT record, which takes effect within the TTL.

Technical detail

_dmarc.‹domain› publishes p=‹policy› together with t=y. RFC 9989 §4.7 defines t as DMARC policy test mode and states that with t=y the Domain Owner asks the receiver not to apply the declared policy and "has an expectation that the policy applied to any failing messages will be one level below the specified policy" — reject becomes quarantine, quarantine becomes none. The effective policy for ‹domain› is therefore ‹effective policy›, and that is what this report scores. The tag has no effect on p=none, and it does not affect reporting: aggregate reports keep arriving either way. t is the replacement for pct=0: RFC 9989 Appendix A.6 removed pct and describes t=y and t=n as analogous to pct=0 and pct=100.