DKIM CheckerA DKIM signature is a cryptographic hash of message headers and body, signed with the domain's private key. Learn more →
Check a DKIM public key for a given domain and selector. Instant, no signup, plain English.
Quick answer: DKIM is a cryptographic signature on every outbound message that lets receivers verify the message was authorized by your domain and was not altered in transit. This tool fetches the DKIM public key for the domain + selector you specify, checks it parses cleanly, validates the key length, and flags revoked keys, test-mode, and other advisories. No DKIM signature on your mail means receivers cannot verify your domain's authorship.
What this checksThe selector identifies which public key to fetch from DNS at <selector>._domainkey.<domain>. Learn more →
DKIM is a cryptographic signature mechanism that lets receivers verify a message was authorized by the sending domain and was not altered in transit. Per RFC 6376, the sending mail server signs each message with a private key, and the receiver fetches the corresponding public key from DNS at <selector>._domainkey.<domain>. Relaymetry queries this DNS path for the domain + selector you provide, parses the TXT record, validates the v=DKIM1 version tag, decodes the public key (p=...), checks the key length against a 1024-bit minimum, and flags advisory tags: test mode (t=y), hash-algorithm restrictions (h=), service type (s=), key-type (k=rsa vs k=ed25519), and explicit revocation (empty p=). We do not validate that an actual message signed by this key would verify — that requires a real signed message.
How to read the resultThe p= tag in the DKIM DNS record holds the public key receivers use to verify signatures. Learn more →
The result shows the resolved DKIM record verbatim, the parsed public-key length in bits, and any advisory flags. Common provider selectors include google and google2048 (Google Workspace), selector1 / selector2 (Microsoft 365), s1 / s2 (custom), and mte- (Mailchimp Transactional). If a provider rotates keys, the active selector changes — old selectors may resolve to revoked records (p= empty), which means receivers will reject any mail still signed with that selector. A 1024-bit key is the historical minimum; modern providers ship 2048-bit or larger. Test-mode (t=y) tells receivers to treat failures as informational rather than authentication failure — useful during rollout but should be removed once stable. If your selector returns NXDOMAIN, the DKIM record does not exist at that selector — verify the selector name with your provider's documentation.
Common failures
No DKIM record at the selector: NXDOMAIN response means the <selector>._domainkey.<domain> TXT record was never published, was removed, or the selector name is wrong. Confirm the selector with your provider — default is rarely correct. Public key revoked: p= is empty, signaling the key is explicitly revoked per RFC 6376 §3.6.1. Mail signed with this key will fail DKIM. Rotate to the active selector. Key too short: keys under 1024 bits are below modern minimums; receivers like Google Workspace warn or downgrade. Re-issue at 2048 bits. Wrong key in DNS: the published key does not match the private key the mail server signs with — every signed message will fail. Re-export the public key from the provider and re-publish. Selector typo: default._domainkey.example.com vs selector1._domainkey.example.com — receivers see no record. CNAME chain to provider: providers like SendGrid use CNAME aliases that delegate the actual key — these resolve correctly per RFC 6376 but require the provider's documentation to be followed exactly. Forwarding modifications: if a forwarding mail server rewrites the message body or headers, the DKIM signature breaks even when the DNS record is correct — the receiver sees dkim=fail even though your published key is valid.
What this does not prove
A valid DKIM key in DNS does not mean every outbound message gets signed correctly. The mail server must actually invoke DKIM signing, the canonicalization mode must produce a stable hash, and the message must reach the receiver without modification. We only inspect the public-key DNS record. We do not test signing, verify signed messages, detect provider-side misconfiguration, or check whether DKIM alignment with the visible From-domain works for DMARC — that is the DMARC Checker's job.
Common questions
What happens if there is no DKIM?A DKIM signature is a cryptographic hash of message headers and body, signed with the domain's private key. Learn more →
Receivers cannot verify your domain authorized the message and cannot detect content tampering. Per the 2024 Gmail/Yahoo bulk-sender requirements, senders of more than 5,000 messages per day to those providers must have DKIM. Mail without DKIM is more likely to be filtered to spam or rejected.
Do I need both SPF and DKIM?
Yes — they cover different parts of the message path. SPF authorizes which servers may send mail using your domain envelope. DKIM signs the message body and headers cryptographically. DMARC requires either SPF or DKIM to align with the visible From-domain; modern best practice is to ship both so DMARC has two paths to pass.
Should I turn on DKIM?
Yes. Every modern mailbox provider — Google, Microsoft, Yahoo, Apple — uses DKIM as a primary trust signal. Most providers (Google Workspace, Microsoft 365, Resend, Postmark, etc.) make enabling DKIM a one-click operation. The only valid reason to skip DKIM is if you do not control the sending infrastructure, in which case ask your provider.
Why does DKIM fail?An empty p= tag explicitly revokes the key. Any mail signed with this selector will fail DKIM. Learn more →
Common causes: (1) the sending server is not signing messages at all; (2) the wrong selector is published in DNS; (3) the public key in DNS does not match the private key in use; (4) the message was modified by a forwarding hop after signing; (5) the public key has been revoked (p= empty). Inspect the failed message's Authentication-Results header to see which class.