DKIM Checker Guide: Read a DKIM Signature's Tags

Email is easy to forge, because the basic protocol trusts the sender to state who they are. A message can claim to come from any address, and a receiving system that takes that claim at face value will deliver a forgery as readily as a genuine message. DKIM, which stands for DomainKeys Identified Mail, adds a checkable signature to that claim. When a domain sends mail, its mail system signs selected parts of the message with a private key, and publishes the matching public key in DNS. A receiving system can then verify the signature: if it matches, the signed parts have not been altered since signing, and the signer held the private key for that domain. DKIM proves the signature, not the safety of the content, and that distinction runs through this entire guide.

The DKIM Checker tool pastes a DKIM signature header or DNS record and checks its required tags. It works on pasted text, not on a live lookup. You paste either the DKIM-Signature header from a message or the public key record from DNS, and the tool reports whether the required tags are present and well-formed. That scope is important, because a full DKIM verification needs both pieces together plus the message body: the signature header alone cannot be cryptographically verified without the public key, and the public key alone verifies nothing. The checker performs the format gate that comes first: are the tags present, spelled correctly, and shaped as expected, or is there a fault that would stop any later verification from working.

A DKIM signature header is a list of tags separated by semicolons, and each tag has a name, an equals sign, and a value. The v tag states the version and must read 1. The a tag states the signing algorithm, such as rsa-sha256. The d tag states the signing domain, which is the domain claiming responsibility for the message. The s tag states the selector, which is a label the domain uses to pick among its keys, allowing key rotation without changing the domain. The h tag lists the headers that were signed, such as from, subject, and date, in the order they were signed. The bh tag carries the hash of the message body, and the b tag carries the signature value itself, a long base64 string. A DNS record for DKIM carries its own tags: v reading DKIM1, k stating the key type, and p carrying the public key data. Reading either form means reading tags one by one, not skimming the block as a whole, because a single mistyped tag invalidates the whole structure.

The relationship between the signature and the key is where most confusion lives. The selector in the signature tells the verifier which DNS record to fetch: the record lives at the name formed by the selector, followed by the marker _domainkey, followed by the domain, so a signature with selector s1 and domain example.com points at s1._domainkey.example.com. If that record is missing, mistyped, or carries a different key, verification fails, even though the signature header itself may be perfectly formed. Conversely, a perfectly formed DNS record cannot rescue a signature whose signed headers do not match the message as received, because any alteration after signing breaks the match. Both halves must be correct, and the format checker helps with each half separately, which is why it accepts either form of paste.

A worked example you can follow

Take a sample DKIM signature header with 8 tags: v=1, a=rsa-sha256, d=example.com, s=s1, h=from:subject:date, bh=a short hash value, b=a long signature value, and an extra tag c=relaxed/simple stating the canonicalisation. Count the required tags: version, algorithm, domain, selector, signed headers, body hash, and signature value, which is 7 required items. The sample contains all 7, plus 1 optional tag, giving 8 total, so 7 out of 7 required present, or 100 percent, with 1 optional extra. Check each: v reads 1, which is correct; d reads example.com, which matches the sending domain in the sample; s reads s1, which points at s1._domainkey.example.com for the key; h lists 3 headers, from, subject, and date, which is 3 signed headers; and b is present and non-empty, which is the minimum a format check can confirm about a signature value without the key.

Now take the matching DNS record sample: v=DKIM1, k=rsa, p=a long public key value. Count its tags: 3, of which the required ones are v and p, so 2 out of 2 required present, or 100 percent, with k as a useful extra stating the key type. The v value reads DKIM1, which is correct for a DNS record and deliberately different from the header's v=1, a distinction that catches people who copy one form's value into the other. The p value is present and non-empty. Together, the header sample and the record sample give a verifier everything it needs to attempt verification: a signature with all required tags, and a key record with all required tags, linked by the selector s1 and the domain example.com.

Take a third, broken sample: a signature header with 6 tags, missing the b tag entirely. The required count is 7, the present count is 6, so 6 out of 7, or about 86 percent, present, but the missing 14 percent is the signature itself, without which there is nothing to verify. The header is not mostly valid; it is invalid, because the missing tag is load-bearing. The fix is to re-copy the complete header, since a signature value cannot be reconstructed from the other tags, and then re-check to confirm 7 out of 7. A second broken sample has d=example.com in the signature but the key record published under a different domain, so the two halves disagree, and verification fails even though each half passes its own format check. Format checks are per-document; agreement between documents is a separate check that must be done explicitly.

Mistakes to avoid

The first mistake is treating a well-formed signature as proof a message is safe. DKIM proves the signer held the domain's key and the signed parts are unaltered; a signed phishing message from a compromised or malicious domain passes DKIM. The second mistake is pasting only half the picture, a signature without its key record or vice versa, and concluding something about verification that needs both. The third mistake is confusing the header's v=1 with the DNS record's v=DKIM1, and copying one into the other. The fourth mistake is pasting private keys or full message bodies containing sensitive content into a checker. A signature header and a public key record are public material; private keys and message content are not, and they should never appear in a paste.

The SPF Checker tool covers the sender-authorisation half of email authentication, and the Email Header Analyzer tool helps read message headers more broadly. For background on checking all three email authentication methods together, see How to Check SPF, DKIM and DMARC.

Checking the result before you act on it

Treat a clean format result as permission to proceed to verification, not as proof the message is authentic. After the format passes, confirm the signature against its key record, confirm the selector points at the record you expect, and confirm the signed headers include the ones that matter for your decision, especially the from header. Keep a note of the domain, selector, and check date, because keys rotate and a signature verified against today's key may not verify against tomorrow's. A DKIM result that is well-formed, key-matched, and understood for what it does and does not prove is a genuine authentication signal; a result read as a safety verdict is a misunderstanding waiting to be exploited.