Verify your DKIM DNS records and cryptographic key configuration. Ensure your emails are properly signed to prove authenticity and prevent tampering.
DomainKeys Identified Mail (DKIM) is the cryptographic layer of email authentication. While SPF verifies which servers can send on your behalf, DKIM goes further and proves that the email content itself hasn't been modified between the sender's outbox and the recipient's inbox. Think of it as a tamper-evident seal on every message your domain sends.
The mechanism is elegant: your sending mail server holds a private cryptographic key and uses it to generate a signature covering the message body and key headers (like From, Subject, and Date). This signature is attached to the email as a DKIM-Signature header. The matching public key lives in your DNS zone under a specific selector, formatted as selector._domainkey.yourdomain.com.
When a receiving mail server encounters your message, it extracts the selector from the DKIM-Signature header, queries your DNS for the public key, and uses it to verify the signature. If the content has been altered, even by a single character, the verification fails, alerting the receiver that the message may have been tampered with. This is particularly important for protecting against man-in-the-middle attacks and email modification by compromised intermediary servers.
Key management is where many organisations stumble. DKIM keys should be rotated periodically, at least annually or immediately if you suspect a compromise. The rotation process involves generating a new key pair, publishing the new public key under a new selector, configuring your mail server to sign with the new private key, and then removing the old public key after a grace period. Using multiple selectors makes this seamless because both old and new keys can coexist during the transition.
The strength of your DKIM key matters too. A 1024-bit RSA key provides baseline security, but 2048-bit keys are the current recommendation. Some forward-looking organisations are already deploying Ed25519 keys, which offer stronger security with shorter key lengths. Our DKIM checker evaluates your key length, algorithm, and record syntax to ensure your configuration meets modern security standards. For complete email protection, combine DKIM with SPF and DMARC.
Type your domain above. Optionally specify a DKIM selector, or we'll automatically try common selectors like "google", "selector1", "default", and "k1".
We query DNS for DKIM TXT records across known selectors, checking each {selector}._domainkey.yourdomain.com for a valid public key record.
For each discovered key, we analyse the algorithm (RSA vs Ed25519), key length (1024 vs 2048-bit), record syntax, and any flags or service restrictions.
You receive a grade reflecting key strength, correct configuration, and best-practice compliance, plus clear steps to improve your DKIM setup.
DKIM (DomainKeys Identified Mail) uses public-key cryptography to sign outgoing emails. When your mail server sends a message, it creates a cryptographic hash of the email body and selected headers, then signs it with a private key. The corresponding public key is published in your DNS as a TXT record. When a receiving server gets the email, it fetches your public key from DNS and uses it to verify the signature, confirming the message was authorised by your domain and hasn't been altered in transit.
A DKIM selector is a label that allows multiple DKIM keys to coexist for the same domain. The selector appears in the DKIM-Signature header of outgoing emails as the "s=" tag. Common selectors include "google" for Google Workspace, "selector1" and "selector2" for Microsoft 365, "k1" for Mailchimp, and "s1" for Sendgrid. To find yours, open a sent email, view the raw headers, and look for the "s=" value in the DKIM-Signature header. Our checker will try common selectors automatically.
DKIM is just one piece of the puzzle. Scan your domain to check SPF, DMARC, SSL, and more, all in one go.
Use a 2048-bit key whenever possible. While 1024-bit keys are still considered functional, they are increasingly vulnerable to brute-force attacks as computing power grows. The NIST and most email security experts recommend 2048-bit RSA keys as the minimum for long-term security. Note that some DNS providers limit TXT record length, which can make 2048-bit keys tricky to publish. In those cases, you may need to split the record or use a DNS provider that supports longer records.
Yes, and it's actually recommended. Each DKIM key uses a unique selector, so you can have different keys for different sending services. For example, your transactional email service, marketing platform, and corporate mail server can each have their own DKIM key with their own selector. This is also useful for key rotation, since you can publish a new key before deactivating the old one to ensure a seamless transition.
When DKIM validation fails, the impact depends on your DMARC policy. With p=reject, the email will be blocked if both SPF and DKIM fail alignment. With p=quarantine, it goes to spam. With p=none, the failure is logged but the email is delivered normally. Common causes of DKIM failure include message modification by mailing lists or forwarding services, expired or revoked keys, DNS propagation delays after key rotation, and body truncation by intermediary servers.