DKIM record is in testing mode (t=y)
Updated
What this check looks for
Your DKIM record tells receivers to ignore any failures because you are still testing. Left in place, it means a genuine signature failure is never acted on.
Why it matters
Testing mode is meant for the first days of a rollout. Forgotten, it quietly weakens the protection you think you have.
When the check passes, your report says: “DKIM is live, not in testing mode”.
What it costs your score
When this check fails it removes 4 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.dkim family ceiling of 30 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
- low
- Default confidence
- confirmed
- Status when triggered
- warn
- Deduction
- 4 points
- Family cap
- email-auth.dkim · 30
- Category
- Email authentication
- Module
- Email dkim
- Fix owned by
- dns host
- In the ruleset since
- 2026.09
How to fix it
Remove the t=y flag once signing is confirmed working.
While it is set, receivers are asked to disregard signature failures.
Confirm outbound mail shows
dkim=passin the Authentication-Results header at an external mailbox, withheader.d=‹domain›andheader.s=‹selector›.Edit the TXT record and remove the
t=ytag — or only theyflag, if the tag also carriess.If the selector is a CNAME to your email provider, the record is theirs: turn testing mode off in the provider's settings rather than in your DNS.
Watch the next DMARC aggregate reports for this selector's DKIM results.
How to confirm it worked
dig +short TXT ‹selector›._domainkey.‹domain› — the record must not contain t=y
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.
Technical detail
‹selector›._domainkey.‹domain› sets the t=y flag. RFC 6376 §3.6.1 defines it as meaning the domain is testing DKIM: verifiers must not treat its messages differently from unsigned mail, even when the signature fails to verify.
Receivers differ in practice. Some ignore the flag and others follow it, so a key carrying t=y gives you no dependable behaviour either way. Under DMARC the cost is concrete: a receiver that honours the flag gives this selector's signatures no weight, which leaves DMARC alignment resting on SPF alone — and SPF does not survive forwarding, where DKIM usually does.
The flag belongs to the first days of a rollout, while you confirm that the signing service and the published key match. It is usually left behind because the setup instructions included it and nothing visibly breaks when it stays. The record's tags are independent, so removing it changes nothing else and needs no new key and no change on the sending side. If the record reads t=y:s, keep t=s, which stops signatures made with this key from using a subdomain in their i= identity.
The edit takes effect as resolvers' cached copies of the record expire, within its TTL.
Standards and references
- RFC 6376 §3.6.1 — Flags § 3.6.1
Test this on your domain
Run the check that produces this finding, on its own, against any domain.