DKIM
DKIM lookup
Fetch the public key at a selector, or try a short list of common ones. See whether the key is strong, short, revoked, or still marked as a test.
DKIM
Fetch the public key at a selector, or try a short list of common ones. See whether the key is strong, short, revoked, or still marked as a test.
DKIM lets a sending system sign a message with a private key and publish the matching public key in DNS. The signature header names a domain (d=) and a selector (s=). The public key lives at selector._domainkey.domain as a TXT record. A receiver fetches that TXT record, checks the signature, and then, if DMARC is in play, checks whether d= aligns with the From domain.
The selector is chosen by whoever turns signing on, so it is not guessable in general. If you leave it blank, this page tries google, selector1, selector2, k1, default, s1, and s2. A miss on that list means the key, if any, uses a different name. Type the s= value from a real signature, or the name shown in the mail provider's settings.
v is the version. When it is present it must be DKIM1. Omitting v is allowed, and many provider records do that. k is the algorithm. It defaults to rsa. ed25519 is the other algorithm you will see, and a short Ed25519 key is normal. p is the public key, base64. This page decodes p and estimates the RSA key length from the modulus inside the key. An empty p= revokes the selector. Signatures that still name a revoked selector are supposed to fail.
RSA keys shorter than 2048 bits are flagged. 1024-bit keys still show up on older providers, and they are deprecated because the modulus can be factored with enough computation. 2048 bits is the size to publish. Keys under 1024 bits are called out as broken, not merely short. Ed25519 is not judged by the RSA scale. A 256-bit Ed25519 key is the whole key, and it is strong.
Many providers ask you to publish a CNAME rather than the key itself. selector1._domainkey.example.com might point at a host on the provider's domain, and the TXT record is over there. The DNS answer includes both the alias and the key. This page shows the key and names the alias. A CNAME with no TXT at the target is a miss: the name was delegated, and the provider has not published a key there.
t=y is test mode. Receivers must not treat a bad signature as suspicious, so a test selector does not protect you. Remove it once real mail signs cleanly. t=s is different: the signing identity must use the same domain as d=, and it is not a warning by itself. Long keys are often split across two quoted strings in one TXT record. Those strings are joined before the key is measured.
This lookup reads public TXT records only. It does not forge a signature, connect to an SMTP port, or download a message. The private key never appears in DNS, and nothing on this page asks you for one.
Use the s= value from a DKIM-Signature header on mail the domain actually sent, or the selector shown in the provider's admin console. The blank search only tries a short public list.
It will often still verify, and it is weaker than a key you would create now. Publish a 2048-bit RSA selector or an Ed25519 selector, start signing with it, then retire the short key.
The selector is revoked. That is a normal way to retire a key after a replacement is in use. It is a problem only when live mail still signs with that selector.
The selector name on your domain is a CNAME. The provider hosts the TXT record so they can rotate the key without asking you to edit it. The alias target is part of the public DNS answer.
No. DMARC also needs the signature's d= domain to align with the From header, and the signature has to verify over the message. This page only shows that a public key is published.