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 |
See this on your own domain
Enter your domain — the check runs instantly on the next page. Free, no signup.
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
“Palisade allowed our team to deploy DMARC on our domains in minutes instead of hours and making sure our clients are compliant with cutting edge security recommendations from Microsoft.”
Alvin Kalli — CSIO, MSP Corp
Enforce it — don't just monitor it
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.
Free 15-day trial · No credit card · Your own domain free forever (NFR)