DKIM Record Checker
Look up your DKIM record by selector, confirm the public key is published, and check your signing setup.
What is a DKIM record?
DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to every message you send. Your mail server signs each email with a private key, and receivers verify it using a public key you publish in DNS. If the signature checks out, the message provably came from your domain and wasn't altered in transit.
Think of it as a wax seal on a letter: the seal proves who sent it and proves nobody opened the envelope along the way. DKIM was standardized as RFC 6376 in 2011, and since 2024 Google and Yahoo require it for bulk senders.
Unlike SPF, DKIM survives forwarding, because the signature travels inside the message itself rather than depending on the sending IP. And unlike SPF, a domain can publish multiple DKIM records - each one keyed by a unique selector.
How DKIM works
Signing and verification are two halves of the same asymmetric-crypto handshake:
The DKIM-Signature header
This is what a signature looks like riding along in a sent message. v= version, a= algorithm, d= signing domain, s= selector, h= signed headers, bh= body hash, b= the signature itself.
a=rsa-sha256; d=yourdomain.com; s=google;
h=from:to:subject:date; bh=abc123...; b=xyz789...What is a DKIM selector?
DKIM records live at selector._domainkey.yourdomain.com, where the selector is a label your mail provider chooses. It lets one domain hold several live keys at once - which is what makes zero-downtime key rotation possible.
You can find your exact selector in the DKIM-Signature header of any signed email you've sent - look for the s= tag. Enter it above along with your domain, or leave it blank and this tool will try the common selectors for you.
Common selectors by provider
If you don't know your selector, your provider narrows it down. These are the defaults for the major senders.
| Provider | Selector(s) |
|---|---|
| Google Workspace | |
| Microsoft 365 | selector1, selector2 (two keys for rotation) |
| SendGrid | s1, s2 |
| Mailgun | smtp, k1 |
| Postmark | date-stamped, e.g. 20240101 |
| HubSpot | hs1, hs2 |
| Instantly / Smartlead | default, dkim |
1024-bit vs 2048-bit keys
Key length is the main quality signal on a DKIM record. 2048-bit is the current standard; upgrade any 1024-bit key when you can.
| 1024-bit | 2048-bit (recommended) | |
|---|---|---|
| DNS TXT length | ~175 chars | ~350 chars |
| Security | Minimum acceptable, theoretically breakable | Infeasible to break, RFC 6376 recommended |
| Support | Universal | All modern providers |
| Status | Being phased out | Industry standard |
How to read your DKIM result
A healthy DKIM record contains a public key in the p= tag with correct syntax. If the checker finds one, DKIM signing is working for that selector. A record with a malformed key or a missing version tag shows as found with issues; no record at all usually means the wrong selector or that DKIM isn't set up for that service.
Beyond presence, the analysis looks at the key type (RSA is the dominant standard), the key length (2048-bit current, 1024-bit weak), the hash algorithm (SHA-256 is current and secure, SHA-1 is deprecated), and any flags. A t=y flag means the key is in testing mode, so failures are treated as non-fatal - fine while you set things up, but remove it in production.
DKIM and email forwarding
DKIM's biggest advantage over SPF is that it survives forwarding: the signature rides in the headers and is tied to the content, not the transmitting IP. SPF almost always fails on a forward, and because DMARC needs only one of the two to pass in alignment, a valid DKIM signature is often what saves a forwarded message.
It can still break when a mailing list rewrites the subject, a forwarder appends a footer, or content is transformed (HTML to plain text, re-encoding). Those edge cases are exactly why ARC (Authenticated Received Chain) was created.
Frequently asked questions
What is a DKIM selector?
A selector is a label that points to a specific DKIM key, letting a domain publish several keys for different services. The record lives at selector._domainkey.yourdomain.com. Find yours in the s= tag of a sent email's DKIM-Signature header.
How do I find my DKIM selector?
Open a signed email you've sent, view the original/raw headers, and look at the DKIM-Signature line. The s= value is your selector, and d= is the signing domain. If you can't find it, try common selectors like google, selector1, or default.
Why can't the checker find my DKIM record?
Almost always the wrong selector, or DKIM isn't enabled for that provider. Enter the exact selector from a real signed email, or leave the field blank to try common selectors automatically.
Does DKIM survive email forwarding?
Yes. Because the signature is embedded in the message, DKIM keeps verifying after a forward, unlike SPF, which breaks when the sending IP changes. It can still break if a forwarder modifies the message body or signed headers.
What key length should DKIM use?
Use 2048-bit keys where your provider supports them - that's the RFC 6376 recommendation and the current industry standard. 1024-bit keys are still valid but weaker; rotate up when you can. 4096-bit can exceed DNS record-length limits, so 2048 is the sweet spot.
Does DKIM prevent spoofing on its own?
No. DKIM proves a message was signed by your domain and not altered, but it doesn't tell receivers what to do when a message fails. That decision comes from DMARC, which needs DKIM (or SPF) plus alignment. Use all three together.
Can I have multiple DKIM records?
Yes - one per selector. That's the mechanism behind key rotation: publish a new selector, move your mail server onto it, then remove the old selector after propagation, all with no downtime.
What happens if DKIM fails?
It depends on your DMARC policy. With p=none the message is delivered but logged; with quarantine it may go to spam; with reject it can be blocked - unless SPF still passes in alignment, which is enough to satisfy DMARC on its own.
Next steps
Stop configuring DNS by hand
Cladiant provisions real Google Workspace, Microsoft 365, and Azure Entra mailboxes with SPF, DKIM, and DMARC written and verified on every domain before a single message sends. No DNS headaches, no authentication gaps, one invoice.