Three things make a published DKIM key unfit for use, and all three are visible in the record without any tooling. This lesson is mostly a checklist you can run by eye.
Key length
RFC 8301 sets the floor at 1024 bits and says signers should use 2048. In practice 1024-bit keys are a finding: they are old, they are cheap to attack by modern standards, and their presence usually means the key has not been touched since it was provisioned years ago.
You do not need a tool to tell the difference. The base64 in p= starts with a fixed prefix that encodes the key size:
1024-bit: p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ... 2048-bit: p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...
So a glance at the first ten characters answers the question. GitHub’s s1 selector began MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA when checked on 2026-09-12 — a 2048-bit key.
Why not 4096
A 4096-bit key does not fit in a single 255-character DNS string and must be split, which some DNS interfaces handle badly. More importantly, some receivers have historically declined to fetch oversized keys. 2048 is the practical answer, and going higher buys less than it costs.
Test mode
t=y tells receivers that the domain is still testing DKIM and that they should treat a failure as though the message were unsigned. It exists so a rollout cannot break mail.
It also means the signature is not being relied on. A key left in test mode after the rollout finished is a key doing no work, and — this is the part that matters — a DKIM pass with t=y may not count for DMARC, because the receiver was told not to rely on it. Domains have reached p=quarantine and been surprised by failures traced entirely to a t=y that was never removed.
v=DKIM1; k=rsa; t=y; p=MIIBIjANBgkq... <- still in test mode v=DKIM1; k=rsa; p=MIIBIjANBgkq... <- in service
Do not confuse t=y with t=s. The latter forbids subdomains from using this key, which is a scoping decision rather than a rollout state, and is harmless.
Revocation
A p= with nothing after it revokes the key. Receivers must treat any signature using it as a failure.
"v=DKIM1; k=rsa; p="
Leaving a revoked key published is better practice than deleting the record. A missing record produces "key not found", which some receivers treat as temporary; an empty p= is unambiguous.
The whole check
| Look for | Verdict |
|---|---|
p= starting MIGfMA0G | 1024-bit. Rotate to 2048. |
p= starting MIIBIjAN | 2048-bit. Fine. |
p= empty | Revoked. Correct if intentional; a live sender using it will fail. |
t=y present | Test mode. Remove once the rollout is done. |
a=rsa-sha1 in signatures | Deprecated by RFC 8301. Replace. |
| No record at the selector | Either the wrong selector, or the key was deleted and mail is now failing. |
Rotation, briefly
Keys should be rotated periodically, and the mechanism is simple because selectors make it simple:
- Publish a new key at a new selector. Both are now live.
- Switch the sending system to sign with the new selector.
- Wait. Messages signed with the old key may still be in transit, in a queue, or sitting in a forwarding system — leave the old key published for longer than you think.
- Revoke the old key by emptying its
p=, then remove it later.
The failure mode is removing the old key too early, which retroactively breaks messages that were correctly signed when they were sent.