DKIM Record Checker

What DKIM is and what gets checked

DKIM (DomainKeys Identified Mail, RFC 6376) attaches a cryptographic signature to a message. The private key stays on the sending server; the public key is published in DNS. Exactly one party needs the private key, whoever sends the mail. Everything else is public. The sender hashes the body and a chosen set of headers and signs the hash with the private key. The receiver reads the domain and selector from the signature, fetches the public key, computes the hash again and compares. A match means the message really was signed by the key holder and was not altered on the way.

This tool checks what can be seen from the outside: whether a key is published, whether it parses, its type and length, whether it has been revoked and whether testing mode was left on. The signature on a specific message cannot be verified from here, because that needs the message itself; its headers can be read in the email header analyzer.

DKIM-Signature header structure

The signature travels with the message as a header of its own:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=example.com; s=mail2024; h=from:to:subject:date:message-id; bh=…; b=…

• v=1: the signature version.
• a=: the algorithm. Today that is rsa-sha256 or ed25519-sha256; RFC 8301 banned rsa-sha1 for both signing and verifying.
• d=: the domain taking responsibility for the message, and the one DMARC compares with the From address.
• s=: the selector, the name of a specific key in DNS.
• h=: the signed headers. From must be on the list; without it the receiver discards the signature.
• bh= and b=: the body hash and the signature itself, in base64.
• c=: header and body canonicalization, covered next.

Canonicalization: simple and relaxed

Servers along the way make small edits: they unfold long headers and add trailing spaces. If the hash were taken byte for byte, any such change would break the signature. So the message is normalised before hashing, and the c= tag names the method, first for the headers, then for the body.

simple tolerates almost nothing, and it is what applies when the tag is missing: the default is c=simple/simple. relaxed lowercases header names, unfolds continuation lines, collapses runs of whitespace and strips it from line ends. It leaves the case of header values and the words themselves alone. The usual choice is c=relaxed/relaxed, since such a signature survives minor formatting changes.

Where to get the DKIM selector

A DKIM record lives at selector._domainkey.example.com. The selector name is chosen by the sending service and there is no universal list. DNS offers no way to ask which selectors a domain has, so you can only test a specific name.

The one reliable source is a message. Open any mail you have received from the domain, view the source and find the DKIM-Signature header: the s= tag is the selector and d= is the domain holding the key.

With no message at hand, the checker probes a couple of dozen names used by popular services. The sweep often finds a key, but coming up empty proves nothing. "None of the common selectors found" means exactly that: no record exists under the names we tried, and your provider may well have named its key differently.

Selectors used by popular services

• Google Workspace: google
• Microsoft 365: selector1 and selector2
• Mailchimp: k1, k2, k3
• SendGrid: s1 and s2
• HubSpot: hs1 and hs2
• MailerLite: litesrv
• Campaign Monitor: cm

What a DKIM record looks like

v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...

The v tag is optional and defaults to DKIM1. k sets the key type (rsa by default), and p holds the public key in base64. A 2048-bit RSA key takes 392 characters while one TXT string holds only 255, so the record is split into several quoted strings, which receivers join with no spaces in between. If the DNS panel slipped in a space or a line break, the record still looks fine but signatures stop verifying. That is the most common DKIM breakage.

A selector must hold exactly one TXT record. With several, the standard leaves the outcome undefined.

Key length: 1024 or 2048 bits

RFC 8301 requires RSA signing keys of at least 1024 bits and recommends 2048. Receivers must be able to verify keys from 1024 to 4096 bits and must not treat a signature made with a shorter key as valid. A 512-bit key, which RFC 6376 still required receivers to accept, is now as good as no signature. Gmail also requires at least 1024 bits for mail to personal accounts and recommends 2048 where the DNS provider supports it.

RFC 8463 added Ed25519 keys: far shorter for the same strength, they fit in a single TXT string. Not every receiving server supports them, so Ed25519 goes under a second selector next to RSA rather than replacing it. The example in that RFC does the same and signs one message with both keys. A key of the right length can be created in the DKIM generator.

What the result means

• Key found and valid. The record parses and the length is adequate. The infrastructure is ready, but only headers from a real message show whether mail is actually being signed.
• An empty p= tag. The key was revoked deliberately. Normal for an old selector after rotation, a problem if the selector is live.
• A 1024-bit key. Still accepted by the standard, which recommends 2048. Issue a new key under a new selector.
• A key under 1024 bits. Receivers must discard signatures made with it. Replace it right away.
• t=y is present. Testing mode: the message counts as unsigned even when the signature is correct. If the selector has been in production for a while, drop the tag.
• The record will not parse. Nearly always the value was broken by line wraps during copy-paste, or lost characters along the way.

Rotating a key without breaking signatures

The longer a private key lives, the more a leak costs: while the key is valid, anyone holding it can sign mail as you. Rotation goes like this: create a new pair under a new selector, publish the public key, switch signing over and confirm from the headers that mail leaves with the new s=. Delete the old record only a few days later, because queues still hold mail signed with it. The DKIM key rotation guide covers the details, including how often to rotate.

When the DKIM signature fails

A failed signature is not the same as a missing one, and the fix is different. Work through it in this order.

Is a key published under the selector named in the message? The selector is the s= tag of DKIM-Signature, and the record is looked up at selector._domainkey.domain. If the key was rotated and the old record deleted too early, mail still in queues carries a signature nothing can verify any more.

Line wraps can break the key. Some DNS panels split a long value and add spaces when joining it back. The record looks whole, and the signature does not verify.

Was the message changed in transit? DKIM covers headers and body, so any hop that appends a line to the subject or a footer breaks it. Mail gateways, antivirus scanners and mailing lists do exactly that. Relaxed canonicalization forgives whitespace, not edited text.

The From header has to be signed. If it is missing from h=, the receiver discards the signature however correctly it was computed.

Does the signing domain match the visible sender? The d= tag shows which domain signed the message. A signature can be valid on its own and still not count for DMARC when d= belongs to the sending service rather than to you.

DKIM alone does not protect the domain

A signature proves the message was not altered in transit and was sent by someone holding the private key. It tells the receiver nothing about what to do with an unsigned message, or one signed by a different domain. DMARC decides that: it requires SPF or DKIM to pass for the From domain. DKIM without DMARC does not stop anyone forging mail from your domain; they simply send it with no signature at all.

With forwarding, though, DKIM holds up better than SPF. The forwarding server sends from its own IP, so the original domain's SPF fails, while the signature stays valid as long as nobody edits the message. The policy side is in the DMARC checker, the list of authorised servers in the SPF checker.

One selector is rarely the whole picture

Mail almost always leaves from several places: corporate mail, a sending service, a CRM, billing, the website contact form. Each signs with its own key under its own selector. Checking one tells you nothing about the rest.

The easiest way to assemble the full list is DMARC reports. They enumerate every source that sent as your domain, with the DKIM outcome for each. Whatever shows dkim=fail or no signature at all is precisely where the key is missing or wrong.

Checking somebody else's domain

Looking up another domain's DKIM is useful in two situations. Before cold outreach: a domain with authentication in place and a strict DMARC policy usually belongs to a company that pays attention to mail, and expects the same of senders. And when examining a suspicious message: if the DKIM-Signature names a domain unrelated to the visible sender, that is worth a closer look.