DKIM Checker

DomainKeys Identified Mail (RFC 6376) lets a sending domain attach a digital signature to a message header. The signature is generated with a private key held by the sending mail server and covers a defined set of headers plus the message body. The receiving server looks up the matching public key in DNS and recomputes the signature; if the two match, the message was not altered in transit and really originated from a server that holds the private key.

DKIM says nothing about the envelope sender or the "From" address a recipient sees - that alignment work belongs to DMARC. DKIM only proves the signed content is intact and was signed by whoever controls the selector.

• The signature lives in a DKIM-Signature header added by the sending server
• Verification pulls the public key from a TXT record, not from the message itself
• A domain can run several selectors at once - one per sending provider is common

The public key sits at `<selector>._domainkey.<domain>` as a TXT record. The selector is an arbitrary label chosen by whoever configures the signing - your email provider assigns it, and it is not guessable from the domain name alone. A typical record looks like this:

• `v=DKIM1` - protocol version, always present
• `k=rsa` - key algorithm (rsa is standard; ed25519 is valid but rarer)
• `p=` - the base64-encoded public key itself
• `p=` with an empty value means the key was deliberately revoked

Unlike an MX or SPF record, a DKIM key has no fixed hostname - it only exists under the selector chosen at setup time, so a checker either needs the selector or has to try common ones. Google Workspace typically uses `google`, Microsoft 365 rotates through `selector1`/`selector2`, and transactional senders like Sendgrid, Mailgun or Amazon SES each default to their own name. If you know the exact selector your provider assigned, entering it directly skips the guessing and checks only that record.

RFC 6376 treats the selector as the unit of rotation: to rotate a key, a sender publishes a new selector with the new public key, switches signing over to it, and only removes the old selector once no queued mail still references it. Publishing an empty `p=` tag on the old selector revokes it immediately without deleting the record - useful when a private key may have leaked, since a deleted record can still be cached by resolvers for the TTL period while an empty `p=` is unambiguous the moment it is fetched.

A dangling selector - one still published in DNS with a valid key long after the sending system that used it was decommissioned - is a standing exposure. Anyone who obtains that old private key can still produce signatures that verify.

Each selector that resolves gets its own line. A passing selector reports a valid public key found at its `_domainkey` subdomain, with the record value shown so you can confirm the key tag is not empty. A selector with an empty `p=` value is flagged as revoked, distinct from a selector that simply does not exist. When none of the checked selectors resolve, the results list which ones were tried so you know whether to add your provider's selector and check again. A separate summary line reports how many selectors were actually found across the sweep, and a legacy ADSP record - a pre-DMARC mechanism - is surfaced separately if still published, since it signals leftover configuration rather than active protection.