Free DKIM Record Checker

What is DKIM?

DKIM (DomainKeys Identified Mail, RFC 6376) is a cryptographic signature on your email. Your mail server holds a private key and signs each outgoing message with it; the matching public key is published in your DNS. When a message arrives, the receiving server fetches that public key and checks the signature. If it verifies, the receiver knows two things: the mail really was authorized by your domain, and the signed parts — headers and body — weren't altered in transit.

Unlike SPF, which checks the server a message came from, DKIM travels with the message itself. That makes it survive forwarding, and it's why mailbox providers like Gmail and Yahoo now require DKIM outright for anyone sending at volume.

What is a selector — and how do I find mine?

A domain can have many DKIM keys at once — one per sending service, old keys mid-rotation, and so on. The selector is the label that picks one: the receiver builds the DNS name <selector>._domainkey.<domain> and looks up the TXT record there. Google Workspace uses google by default, Microsoft 365 uses selector1 and selector2, and most ESPs generate their own.

To find the selector your mail actually uses, don't guess — read it off a real message. Send yourself an email from the service you care about, open it, and view the raw headers (Gmail: the ⋮ menu → Show original; Outlook: View message source). Find the DKIM-Signature header. The s= tag is your selector and the d= tag is the signing domain — type both into the checker above for an exact lookup. The no-selector scan is a convenience, not a guarantee: selectors can be any name at all, so a scan of common ones is always best-effort.

Reading a DKIM record's tags

A DKIM record is a TXT record made of tag=value pairs separated by semicolons. The ones that matter:

• v=DKIM1 — the version. If present it must be exactly DKIM1 and must come first.
• k= — the key type: rsa (the default) or ed25519.
• p= — the base64-encoded public key. This is the heart of the record, and because keys are long, DNS often splits the value across multiple quoted strings — that's normal, and verifiers (and this check) join the chunks back together.
• t= — flags. t=y means testing mode: receivers may treat signatures as if the mail were unsigned, so remove it once DKIM works. t=s is strict mode — the signing identity must match the domain exactly, with no subdomains.
• h= and s= — optional restrictions on hash algorithms and service type. Rarely set, rarely a problem.

1024-bit vs 2048-bit keys

RSA key length is a real security decision, and you can estimate it from the record: a 1024-bit public key encodes to roughly 216 base64 characters, a 2048-bit key to roughly 392. 1024-bit keys are weak — researchers have factored keys of that size, and RFC 8301 moved the floor for signers to 1024–4096 bits while requiring verifiers to handle 2048. Some receivers already treat short keys with suspicion. If the checker flags a 1024-bit key, rotate: publish a new 2048-bit key under a new selector, switch your signer to it, and retire the old one.

Why an empty p= means the key was revoked

A record like v=DKIM1; k=rsa; p= — with nothing after p= — isn't broken syntax. It's the standard's explicit way of saying this key has been revoked. Receivers treat any signature made with that key as a failure. Publishing an empty p= is the right move for a retired or compromised key; it's a silent mail-killer if your server is still signing with the selector you revoked, which is exactly why the check flags it in red.

Why providers use CNAME delegation

Instead of handing you a TXT value to paste, many providers — Microsoft 365 with selector1/selector2, Amazon SES, many ESPs — ask you to publish a CNAME at the selector name, pointing into DNS they control. The receiver's resolver follows the chain and finds the TXT at the other end. The payoff is key rotation without you touching DNS again: the provider swaps the key on their side whenever they like. This check follows CNAME chains too, notes the delegation, and warns when a chain dangles — a CNAME that points at a name with no key behind it.

DKIM next to SPF and DMARC

The three standards answer different questions. SPF says which servers may send for your domain. DKIM says this message was signed by your domain and arrived unmodified. Neither one, alone, stops spoofing — a forger simply doesn't sign, and receivers have no instruction about what to do with unsigned mail. That instruction is DMARC: it requires SPF or DKIM to pass in alignment with the visible From address, and tells receivers to quarantine or reject mail that doesn't. DKIM matters most of the three in practice, because a DKIM signature survives forwarding while SPF often breaks — but you want all three in place, and you can verify the other two with the SPF checker and DMARC checker.

One honest limit, stated plainly: a record lookup checks what you publish. Only real messages prove that signatures actually verify — which is why your free credits also cover inbox placement tests that send real mail and show you where it lands. Authentication opens the door; your sending reputation decides whether you walk through it.