Enter a domain and a DKIM selector to look up the public key TXT record published at <selector>._domainkey.<domain> and read its tags. It is free, runs instantly in your browser over DNS-over-HTTPS, with no signup and nothing stored.
DKIM (DomainKeys Identified Mail) lets a sending server attach a cryptographic signature to each message. The matching public key is published in DNS as a TXT record at <selector>._domainkey.<domain>, where the selector is a label the sender chooses so it can run several keys at once. A receiving server reads the selector from the message's DKIM-Signature header, fetches that public key, and verifies the signature to confirm the message was not altered in transit and really came from the signing domain. A valid DKIM signature is also one of the ways a message can align with and pass DMARC. Mailbox providers like Gmail and Yahoo expect bulk senders to authenticate with DKIM, so a published, correct record is part of getting to the inbox.
DKIM is published per selector, not per domain, so you must supply one. Find it in a message you received from the domain: open the raw headers and read the s= tag inside the DKIM-Signature line. If you cannot see a header, try common selectors such as google (Google Workspace), selector1 and selector2 (Microsoft 365), k1 (Mailgun), s1 and s2 (SendGrid), k1, k2 and k3 (Mailchimp), default, or dkim.
The version tag. It should read v=DKIM1 and, when present, must be the first tag in the record. Anything else means the record is not a valid DKIM key record.
The key type. Most records use k=rsa; some modern setups use k=ed25519. If k= is omitted it defaults to rsa, so a missing k tag is normal.
The base64-encoded public key. This is the core of the record and must be one unbroken string with no spaces or line breaks. RFC 8301 sets a 1024-bit minimum for RSA, and 2048-bit is the current recommendation.
If the record exists but p= is empty (p=), the key has been deliberately revoked per RFC 6376. This is different from no record at all: an empty p= tells verifiers to treat any signature using this selector as invalid.
The lookup returns nothing because the selector is wrong or the key was never published. Confirm the exact selector from the s= tag in a real DKIM-Signature header, then re-check. Each selector is separate, so the right key may live under a different selector.
The record is present but the p= value is blank, which RFC 6376 defines as a revoked key. Receivers will fail any signature signed with this selector. Republish the record with the current public key, or point your sending platform at a selector that still has a valid p= value.
The p= value was pasted across multiple strings or has stray spaces and line breaks, so verifiers reconstruct the wrong key. Publish the base64 key as one continuous value. If your DNS host splits long TXT records into quoted chunks, that is fine as long as no whitespace lands inside the key itself.
If the record does not start with v=DKIM1, parsers may reject it. Make sure the version tag is present and first, with tags separated by semicolons.
A 1024-bit RSA key meets the old minimum but 2048-bit is the current recommendation, and a t=y tag marks the domain as testing so receivers may ignore failures. For production mail, use a 2048-bit key and remove t=y once you have confirmed signing works.
