DKIM Checker

Look up and verify DKIM (DomainKeys Identified Mail) DNS records for any domain and selector

Domain
Selector (leave blank to auto-discover)
Try:
Common selectors:

Frequently Asked Questions

DKIM (DomainKeys Identified Mail) is an email authentication method that adds a cryptographic digital signature to outgoing emails. The private key signs the message headers; the public key is published in DNS as a TXT record. Receiving mail servers verify the signature using the public key, confirming the email wasn't altered in transit and genuinely came from your domain.
A selector is a label that allows a domain to publish multiple DKIM public keys simultaneously. The DKIM DNS record is stored at {selector}._domainkey.{domain}. The sending mail server includes the selector in the DKIM-Signature email header so receivers know which key to use. Common selectors include google, selector1, default, and date-based selectors like 20230601.
A DKIM key is considered revoked when the p= tag is empty (e.g. v=DKIM1; p=). An empty public key tells receivers to treat all signatures under this selector as invalid. This is the recommended way to retire an old DKIM key — publish the record with p= empty rather than deleting the DNS entry.
For RSA, use at least 2048-bit keys. 1024-bit keys are deprecated and no longer accepted by major providers like Gmail. Alternatively, use Ed25519 keys (k=ed25519) — they are smaller, faster, and more secure, though not yet supported by all mail servers. Rotate DKIM keys at least annually as a best practice.
DKIM uses asymmetric public/private key cryptography. When your mail server sends an email, it uses a private key to compute a cryptographic hash of selected email headers and the message body. This hash is encoded in base64 and added to the email as a DKIM-Signature header. When a receiving mail server gets the email, it fetches the public key from DNS and uses it to verify the signature — confirming the email wasn't altered in transit.
The easiest way is to find the DKIM-Signature header in a sent email. In Gmail, open an email you sent, click the three-dot menu and select "Show original" — look for the s= tag. In Outlook, open an email and view message source. Alternatively, check your email provider's admin panel: Google Workspace lists selectors under Apps → Gmail → Authenticate Email. Use this tool's auto-discover mode (leave the selector blank) to try 12 common selectors automatically.
Use 2048-bit RSA keys as a minimum. 1024-bit keys are deprecated — they are considered cryptographically weak, and Gmail has rejected 1024-bit DKIM keys since 2024. Google Workspace and Microsoft 365 both default to 2048-bit. For maximum future security, consider Ed25519 keys — equivalent security to 3072-bit RSA in a much smaller key size. Rotate your DKIM keys at least annually.
When a receiving mail server verifies DKIM, it adds an Authentication-Results header to the email. In Gmail, open the email, click the three-dot menu → "Show original". Look for the Authentication-Results header — it will show something like dkim=pass or dkim=fail. A DKIM fail can mean the keys don't match, the message was modified in transit, or the DNS record was deleted.
DKIM failure after forwarding is a known limitation. When an email is forwarded by an intermediate server, that server may modify the message (adding a footer, changing headers) which breaks the cryptographic signature. This is why SPF also fails for forwarded email. DMARC relaxed alignment partially mitigates this by allowing the organizational domain to match rather than the exact subdomain. For mailing lists, the ARC (Authenticated Received Chain) protocol was developed to preserve authentication across forwarding hops.

About This DKIM Checker

This free DKIM Checker queries the DNS TXT record at {selector}._domainkey.{domain}. Leaving the selector blank triggers auto-discovery — the tool checks 12 common selectors (google, mail, default, dkim, k1, s1, s2, and more) and reports every active one it finds. Each discovered record is fully parsed to show key type, approximate key length, flags, and allowed hash algorithms.

DKIM Tag Reference

TagNameDescription
vVersionAlways DKIM1
kKey Typersa (default) or ed25519
pPublic KeyBase64-encoded key; empty = revoked
tFlagsy = testing mode; s = no subdomain signing
hHash AlgorithmsAccepted algorithms (e.g. sha256)
sService Typeemail = email only; * = all

The Email Authentication Stack

DKIM is the cryptographic layer of email authentication. Combined with SPF, DMARC, and BIMI it forms a complete protection chain.

ProtocolWhat it authenticatesDNS RecordOur Tool
SPFThe sending server's IP address is authorizedTXT at root domainSPF Lookup & Generator
DKIMMessage was cryptographically signed and not alteredTXT at {selector}._domainkey.{domain}This tool
DMARCSPF/DKIM alignment with From: header; sets enforcement policyTXT at _dmarc.{domain}DMARC Lookup & Generator
BIMIDisplays brand logo in email clients once SPF, DKIM, DMARC all passTXT at default._bimi.{domain}BIMI Lookup & Generator
MXWhere inbound email for the domain should be deliveredMX at root domainMX Lookup

Related Internet Tools

SPF Lookup DMARC Lookup BIMI Lookup MX Lookup

Related Articles

In-depth guides and technical articles.

View all →
Internet Jul 3, 2026
Where Your DKIM Private Key Lives and How Attackers Steal It — A Security-First Look at DKIM Key Management
DKIM private keys must be accessible to the mail server at send time — unlike HTTPS where hardware security modules can isolate keys. Here's where DKIM private keys actually live (PEM files, config, secrets managers), the four exposure vectors (version control, backups, server decommission, shared hosting), what an attacker can do with a stolen key (DKIM-signed phishing that passes DMARC), and why Ed25519 is replacing RSA for new DKIM deployments.
Internet Jun 19, 2026
DKIM Signatures Don't Expire — and That's the Replay Attack Problem
DKIM signatures stay valid indefinitely on unmodified messages — which means an attacker who receives a legitimately signed email can replay it to other recipients and the signature will still verify. Here's how DKIM replay attacks work, why the specification doesn't prevent them, what DMARC aggregate reports reveal about replay patterns, and the countermeasures (signing the To: header, signature expiry x= tag) that limit the attack surface.
Internet Jun 16, 2026
DKIM Key Length and Algorithm: Why "Still Validates" Doesn't Mean "Still Recommended"
A DKIM key generated five years ago might still be using RSA-1024 — a length that was acceptable then but has since been "softly" deprecated by major providers, even though signatures using it still technically validate. Here's how to identify your key's algorithm and length from its DNS record, why Ed25519 is the emerging alternative (and why dual-key signing addresses its adoption gap), and why this migration follows the same process as any DKIM key rotation.
Internet Jun 16, 2026
DKIM, Mailing Lists, and Forwarding: Why Signatures Break and How ARC Tries to Help
A correctly signed email can fail DKIM verification at the recipient simply because a mailing list added an unsubscribe footer — modifying the signed content. Here's why mailing lists and forwarding break DKIM, how ARC (Authenticated Received Chain) was designed to preserve authentication results through intermediaries, and why SPF and DKIM respond differently to forwarding.
Internet Jun 9, 2026
The Complete Email Authentication Audit: How to Check SPF, DKIM, DMARC, PTR, and BIMI
Most organisations have never systematically audited their full email authentication stack. Here's the complete 8-step process: inventorying all sending services, auditing SPF, DKIM, DMARC, PTR, and BIMI, sending a test to verify all pass, and setting up ongoing monitoring.