DKIM glossary
What does t=y mean in a DKIM record?
By Samuel Chenard · CEO & Co-Founder, Palisade · Reviewed July 15, 2026
t=y is the testing flag in a DKIM public-key record: it signals the domain is still testing DKIM. Per RFC 6376, receivers must not treat a test-mode signature differently from unsigned mail, though they may note it. Leaving t=y in production advertises an unfinished rollout — remove it once signing works.
t=y at a glance | |
|---|---|
| Tag | t (flags, key record) |
| Valid values | y (testing) and/or s (strict i=/d= matching), colon-separated — e.g. t=y, t=s, t=y:s |
| Default | Optional; with no t= tag there are no flags and no testing or strict behaviour. |
| Where it goes | In the _domainkey TXT record (the DNS key), not in the DKIM-Signature header. |
How t=y works
t= sets flags on the DNS key record, and y is the testing flag. It announces that the domain is still trialling DKIM. Per RFC 6376, verifiers must not treat a signature from a testing key differently from unsigned mail — even if it fails to verify — though they may make a note of it.
That safety is also the catch. Leaving t=y in place after go-live tells the world your rollout is unfinished and effectively tells receivers not to lean on your signatures. Once you've confirmed signing works end to end, remove t=y so your DKIM actually carries weight.
The t tag can carry a second flag, s, for strict identity matching: it requires the i= identity to share the exact domain of d=, forbidding subdomains. The two combine as t=y:s. Use s deliberately — it's a tightening, not a default.
Correct record vs common mistake
Correct
v=DKIM1; k=rsa; p=MIIBIjANBgkq...IDAQABA finished, production key: no t=y flag, so receivers give the signature full weight.
Common mistake
v=DKIM1; k=rsa; t=y; p=MIIBIjANBgkq...IDAQABt=y left in production. Receivers may treat the signature like unsigned mail, so DKIM does nothing for you — remove the testing flag once signing is verified.
Troubleshooting t=y
| Issue | Likely cause | Fix |
|---|---|---|
| DKIM 'passes' but gives no protection | t=y still set, so receivers treat the signature like unsigned mail | Remove the t=y flag from the key record once signing is verified |
| Subdomain identity rejected | t=s (strict) requires i= to match d= exactly, blocking subdomains | Drop the s flag if you need subdomain identities, or align i= with d= |
| Testing flag forgotten after onboarding | t=y was added during setup and never removed | Make removing t=y a step in your go-live checklist and re-check the record |
Why it matters for MSPs
A t=y left behind after onboarding is easy to miss and quietly neutralizes DKIM for that client — receivers are told not to trust the signatures. Across many tenants, forgotten testing flags mean domains that look DKIM-enabled but get no real protection from it.
Trusted by MSPs
“I've migrated all my clients from PowerDMARC. The agent was so powerful it allowed us to do the work in a fraction of the time.”
Marc-Olivier Hardy — VP & CTO, CDT Connexion
DMARC software that does the work
Palisade checks whether each client's key is still flagged for testing and confirms signatures are being honored, so a stray t=y is caught and cleared before the domain is advanced to reject.
1 domain free up to 1,000 emails/month
Questions readers ask