Check a domain's DKIM records the way receiving mail servers find them, or paste an email to test its signature: which selectors answer, who signs, how strong each key is, and whether it lines up with DMARC.
Sources: 140 common selectors from 67 email providers, asked through Google Public DNS (Cloudflare behind it) · RFC 6376 and RFC 8301 key checks · emails verified in your browser · nothing about you is stored
Asks the 140 selectors email providers use at selector._domainkey. plus the domain, since DNS can't list them
or drop an .eml file on this box
Checked in your browser: the email stays on this device, unless it has an Ed25519 signature this browser can't check and you choose to send it to our server. Only the key's name (s._domainkey.d) goes to public DNS, and the From and signing domains to dnsrobot.net for their DMARC policy.
Try
What you'll see
Every DKIM-Signature: who signed, with which key, over which headers
The body hash and the header signature checked apart, so a footer added on the way isn't called a forgery
Whether d= lines up with the From domain for DMARC
Risks a pass can hide: l=, From not oversigned, a key under 2048 bits
What leaves this device when you verify
This device
The emailChecksWebCrypto
selector._domainkey.d TXT?the key's name
From · d=From and d= domains
Public DNS
Cloudflare, Google as a backup
dnsrobot.net
the DMARC policy
The email itself stays behind the green line: only names go out, and their answers come back. The one exception is yours to choose: an Ed25519 signature this browser can't check can be sent to our server, which checks it in memory and keeps nothing.
A made-up email signed by example.com, to see every part
Advertisement
How to check a DKIM record
Type the domain above: the checker asks the 140 selectors email providers use, shows every key it finds with its size and provider, and says honestly when it finds none. Know the selector? Choose Domain + selector and it's checked first.
By hand you need the selector, because DNS can't list them: dig +short TXT selector._domainkey.example.com, or nslookup -type=TXT with the same name on Windows. The selector is the s= in any email's DKIM-Signature (RFC 6376 §3.6.2.1).
dig shows the text, not what it means: it doesn't decode the key's size, follow the provider's CNAME, or tell a standby slot from a broken one. That's what this DKIM record checker adds.
% dig +short TXT selector._domainkey.example.com
Every TXT string at the name: join them to read the key.
1The name is selector._domainkey.domainNo selector, no answer: DNS has no “list all keys”.
2Two strings, one recordA TXT string holds 255 bytes, so a 2048-bit key is split; receivers join them with nothing between.
3The key's real sizeopenssl decodes p=: 2048 bits is what RFC 8301 asks for.
4A CNAME into the providerNo TXT behind it: Microsoft 365's standby slot, not an error.
google.com's key and microsoft.com's selector1 as Cloudflare DNS returned them on October 25, 2026.
Reading the result: the selector sweep
The answer comes first, as a sentence. Under it, who signs and the key itself, each tag coloured over its exact characters with the key's size on RFC 8301's scale; on navy, every selector the check asked, so you can see what was tried.
No grade: a retired key or a provider's empty standby selector is normal, and “not found among the common selectors” never means “no DKIM”.
The verdictOne sentence: how many keys, and what needs doing.Who signsOne card per provider, found by its CNAME or a documented selector. Each selector chip opens its key.The keyEach tag coloured over its characters, and the key's size on RFC 8301's scale.The selector sweepEvery name asked, lit as it answers: green a key, amber 1024-bit, dashed a standby slot.DMARC alignmentWhether a key with this domain's d= lines up with its DMARC policy.
A DKIM check of github.com: the verdict, who signs, the key split into its tags with its size, and on navy every selector the check asked. Select a number to see what each part shows.
Advertisement
What is DKIM?
DKIM (DomainKeys Identified Mail) is a signature a sending server adds to each message, which receivers check with a public key the domain publishes in DNS (RFC 6376). A valid signature proves two things: the domain in d= signed it, and the signed parts haven't changed since.
The sender hashes the body into bh= and signs the chosen headers plus that hash with its private key into b=. The receiver reads d= and s=, fetches the key at s._domainkey.d, and redoes both. One changed byte in the body, or in a signed header, and it fails.
DKIM says nothing about what to do when it fails, and any domain can sign. That's DMARC's job: it asks for a passing signature whose d= matches the From: domain.
One message, signed at the sender and checked at the receiver
Both results are the engine's, from the sample email on this page and the same email with its Subject changed after signing. RFC 6376 §3.7, RFC 8301.
What is a DKIM selector, and how do I find mine?
A selector is the name of one DKIM key: the s= in a signature, and the first label of the DNS name the key lives at (s1._domainkey.github.com). A domain can have as many as it likes: one per provider, per server, per year (RFC 6376 §3.1).
To find yours, open any email the domain sent and look at the original: Gmail's More (⋮) › Show original lists the DKIM-Signature, and its s= is the selector. Or paste the email into Verify an email above.
Most providers use fixed names, so a sweep finds them. Amazon SES, Postmark, SparkPost and HubSpot generate a name per account, which only an email or the provider's dashboard tells you.
From the signature to the key, and the names providers use
github.com's s1 as Cloudflare DNS returned it on October 25, 2026. Providers' names from their own documentation (67 providers, 140 selectors in the sweep).
DKIM record format: every tag explained
A DKIM record is a TXT record of tag=value pairs separated by semicolons; only p=, the public key, is required.v=DKIM1 is optional but, when present, must come first (RFC 6376 §3.6.1).
k= says the key type (rsa unless it says ed25519), t= carries flags (y testing, s strict), h= limits hashes and s= services. An empty p= revokes the key on purpose.
Tag names are case-sensitive and a repeated tag invalidates the record. Unknown tags are ignored.
p= lengths are measured SubjectPublicKeyInfo keys. yahoo.com publishes its 2048-bit key in 4 strings: any split works, since receivers join them with nothing between (RFC 6376 §3.6.2.2).
Advertisement
1024 vs 2048-bit DKIM keys, and how to rotate them
Use 2048-bit RSA. RFC 8301 still requires verifiers to accept 1024-bit keys, but asks signers for at least 2048, and tells verifiers to reject keys under 1024 bits. M3AAWG calls 1024 bits “at the edge of attack” and reports a 512-bit key cracked in about 72 hours for about $75.
An Ed25519 key is small (44 characters of p=), and for backward compatibility RFC 8463 lets signers add an RSA signature beside it: two selectors, two signatures (RFC 8463).
Rotate by publishing the new key under a new selector, switching signing, keeping the old key 7 to 30 days for mail in flight, then emptying its p=. M3AAWG suggests every six months. Providers like Fastmail and Microsoft 365 do it for you with standby selectors.
Where real keys sit on RFC 8301's scale
5121,0242,0484,096
FailsValid, rotate to 2048GoodMay fail at some receivers
microsoft.com · selector2
github.com · k1
google.com · 20251104
fastmail.com · fm2
archlinux.org · dkim-rsa
archlinux.org · dkim-ed25519 (Ed25519)
Rotation without a gap (M3AAWG)
Day 0Publish the new key at a new selector
Day 1+Switch signing to it
+7–30 daysKeep the old key for mail in flight
ThenEmpty the old p=; don't reuse the name
fastmail.comfm1empty p=fm22,048fm3empty p=three CNAMEs, one filled: rotation is a DNS change at Fastmail's end
Key sizes read from DNS on October 25, 2026, decoded from each p=. RFC 8301 §3.2; M3AAWG DKIM Key Rotation Best Common Practices (2019).
Why does DKIM fail? Body hash, forwarding and mailing lists
DKIM fails when the signed bytes changed, when the key can't be found, or when the key doesn't match the signature. Forwarding that leaves the message unchanged keeps DKIM intact (unlike SPF); mailing lists usually break it, because they add footers or tag the subject.
The verifier on this page checks the body hash and the header signature apart, so it can tell a footer added on the way from a forgery.
Body hash did not verify
keybodyheaders
A mailing list added a 153-byte footer. The headers still verify with project.example's key, so this isn't a forgery.
Fix Lists that keep the body intact, or ARC (RFC 8617) so later receivers see the original result.
body-hash-mismatch
Signature did not verify
keybodyheaders
A signed header changed after signing (a list adding its name to the Subject), or the selector now holds a different key.
Fix Don't rewrite signed headers; publish a new key under a new selector instead of replacing one.
signature-mismatch
No key for signature
keybodyheaders
s=2023old._domainkey.shop.example is NXDOMAIN: the selector was deleted while mail signed with it was still in flight.
Fix Keep old keys published 7–30 days after switching; empty p= rather than delete.
key-not-found
Forwarding: a forwarder that passes the message on unchanged keeps DKIM valid, which is why DMARC usually survives forwarding through DKIM even when SPF fails.
DKIM vs SPF vs DMARC
SPF says which servers may send for a domain, DKIM proves a domain signed the message and it wasn't changed, and DMARC ties both to the From: address and says what to do when they fail.
They answer different questions, so you need all three: Gmail and Yahoo require SPF and DKIM from bulk senders, plus a DMARC record, and RFC 9989 asks domains at p=reject to DKIM-sign rather than rely on SPF.
Open the original message and find the DKIM-Signature header: d= is who signed, s= is which key, h= lists the signed headers, and bh= and b= are the two hashes a receiver checks.
The receiver's verdict is a separate header added on arrival: Authentication-Results: … dkim=pass header.d=example.com header.s=dnsrobot-sample. Gmail's Show original page (in English) sums it up as “DKIM: 'PASS' with domain example.com”.
A message can carry several signatures, one per signer (your domain and your email service, or a mailing list). Any one passing signature with an aligned d= is enough for DMARC.
The made-up sample email this page loads (example.com, a key made for it), verified by the engine.
DKIM checker: frequently asked questions
What is a DKIM record?
A DKIM record is a TXT record that publishes a domain's public key at selector._domainkey.domain, such as google._domainkey.example.com. It holds tag=value pairs: p= is the base64 key and is required, k= the key type, t= flags. Receivers fetch it to check the DKIM-Signature on incoming mail. A domain can publish many, one per selector, usually one per sending service.
How do I find my DKIM selector?
Open any email the domain sent, view the original message and find the DKIM-Signature header: the value after s= is the selector, and d= is the domain. In Gmail use More (⋮) › Show original; in Outlook on the web, View › View message source. Or paste the email into Verify an email above, which reads s= and d= for you.
Why does the checker find no key when my mail is signed?
Because DNS can't list selectors: a key is found only by asking for its exact name. The checker asks the 140 names providers use; if yours signs with another (Amazon SES and Postmark generate one per account), the sweep can't see it. Add the selector from an email's s= and it's checked first, or verify an email instead.
Is a 1024-bit DKIM key still OK?
It still works: RFC 8301 requires verifiers to accept RSA keys from 1024 to 4096 bits, and Gmail and Yahoo set 1024 bits as their minimum. But RFC 8301 asks signers for at least 2048 bits, and M3AAWG calls 1024 at the edge of attack. Plan a rotation: Microsoft 365 and Google Workspace both offer 2048-bit keys. RFC 8301 tells verifiers to reject keys under 1024 bits.
What does an empty p= mean?
An empty p= means the key is revoked: signatures with that selector fail, exactly as if the key were missing. It's usually deliberate. Google keeps its old dated selectors this way, and Fastmail and Microsoft 365 keep empty standby selectors to rotate into. It's a problem only if it's the selector your mail is signed with today.
What does t=y mean in a DKIM record?
t=y marks the key as testing: receivers should treat mail signed with it like unsigned mail, even when the signature verifies. It's meant for a first setup and is often forgotten. t=s is different: it means strict, so the i= in signatures must be exactly the signing domain, not a subdomain. Some email services publish t=s on their keys; SendGrid's keys for github.com carry it.
Why does DKIM fail with “body hash did not verify”?
The body the receiver hashed doesn't match the bh= value in the signature, so the body changed after signing. Mailing lists that add a footer, security gateways that rewrite links and disclaimers added by a server all cause it. If the header signature still verifies, the message is genuine but modified; this page's verifier checks both apart.
Does DKIM survive email forwarding?
Usually, yes. A forwarder that passes the message on unchanged keeps the signature valid, because DKIM signs the content, not the path. That's the difference from SPF, which fails at the forwarder's IP address. Forwarders that alter the message, such as mailing lists adding footers or subject tags, break DKIM; ARC lets them vouch for the original result.
Do I need DKIM if I already have SPF?
Yes. SPF breaks when mail is forwarded and only covers the hidden MAIL FROM address, while DKIM survives forwarding and can align with the From: domain DMARC checks. Gmail and Yahoo require both from bulk senders, Outlook.com since May 2025, and RFC 9989 asks domains with p=reject to DKIM-sign their mail.
How often should I rotate DKIM keys?
M3AAWG recommends at least every six months. Publish the new key under a new selector, switch signing to it, keep the old key published for 7 to 30 days so mail in flight still verifies, then empty its p= instead of deleting it. Never reuse a selector name. Hosted providers with CNAME selectors rotate the keys for you.
Is my email uploaded when I verify it here?
No. This DKIM validator checks the email in your browser: public DNS is asked only for the keys' names (s._domainkey.d), and dnsrobot.net only for the From domain's and the signing domains' DMARC policy. The one exception is an Ed25519 signature a browser can't check: the page then asks before sending the email once to our server, which checks it in memory and stores nothing.
Can I use an Ed25519 DKIM key?
Yes. RFC 8463 defines it and requires verifiers to support it. For backward compatibility, publish it at its own selector next to an RSA key and sign every message twice, as archlinux.org does with dkim-ed25519 and dkim-rsa: receivers that can't verify Ed25519 still have the RSA signature. Microsoft 365 and Google Workspace offer RSA keys only.