DKIM Validation Report

DKIM is one of the places where email authentication turns from a policy idea into a real cryptographic check. A sending system signs selected message headers, usually the body hash as well, with a private key. The receiver fetches the matching public key from DNS and uses it to test whether the signed material still matches what arrived. When the check passes, the receiver has evidence that a domain took responsibility for that message and that the signed parts were not changed in transit.

The public key is not published at the bare domain. DKIM uses a selector, which is a short label chosen by the mail platform, under the reserved _domainkey branch. A signature with d=example.com and s=selector1 points receivers to selector1._domainkey.example.com. This extra label lets one domain run several mail streams at the same time, rotate keys without breaking older mail, and delegate different selectors to different services.

A selector record is a compact tag list stored as a DNS TXT record. The v tag identifies a DKIM key record, k names the key type when it is not the default RSA, p carries the public key, and t can mark special selector flags such as testing. A blank p value is not a harmless omission. It revokes the selector, so messages that point to that selector should no longer verify.

Publication checks matter most during setup, sender migration, and key rotation. A provider may give the right key for the wrong DNS zone, a copied selector may accidentally include ._domainkey, or a new TXT record may be visible through one resolver but still cached elsewhere. A selector can also look correct while real mail still fails because the message was not signed, the body hash changed, the wrong header fields were signed, or the DKIM signing domain does not align with the visible From domain for DMARC.

A coherent DKIM key record is therefore a prerequisite, not the whole verdict. It proves that the public key a receiver would fetch is visible and internally plausible. It does not prove that every outgoing message is signed, that mailbox providers accept the signature, or that the signature is aligned with the domain shown to recipients.

How to Use This Tool:

Use values from a mail provider setup screen or from a real DKIM-Signature header. The signing domain normally comes from d=, and the selector comes from s=.

1. Enter the d= value in Signing domain. A pasted URL is reduced to its hostname before the lookup name is built.
2. Enter only the selector label in Selector. Values such as default, google, and selector1 are common; use a dotted value only when the selector itself includes dots.
3. Leave Resolver on the default public resolver for an ordinary first pass. Change it when you need to compare propagation, resolver caching, or a suspected DNS service difference.
4. Run the validation and read Key Profile first. Confirm the built Selector host, resolver name, DNS status, TXT answer count, key type, key bits, and lookup time.
5. Open Tag Ledger when you need to inspect the parsed DKIM tags, then use Validation Checks for the record count, version tag, public key payload, RSA strength or Ed25519 recognition, and testing flag result.
6. Use DKIM Check Status Chart or JSON only after the table-level checks make sense. The result is ready to share when the summary says the selector is coherent or clearly names the review item to fix.

If validation stops before DNS is queried, remove spaces, trailing punctuation, and full owner-name fragments from the fields. If no DKIM record appears, copy the selector from a recent signed message header before changing DNS.

Interpreting Results:

Start with Validation Checks, not the chart. Exactly one DKIM-looking TXT record is the expected publication state. No DKIM record is marked Review because the selector may be wrong, retired, or still propagating. More than one DKIM record is Needs attention because receivers expect one effective key record for a selector owner name.

Healthy means the visible DNS record passed that specific publication check. It does not mean a message will pass DKIM at every receiver. Review points to a condition that may still work but deserves context, such as a 1024-bit RSA key or a selector marked for testing. Needs attention points to a publication problem, such as a missing v=DKIM1 tag, an empty p value, multiple DKIM records, or an RSA key below the minimum size checked by the report.

Read TXT answers and DNS status as resolver evidence. They describe what the selected public resolver returned for the selector owner name. They do not inspect the original message, the signed header list, the DKIM body hash, or mailbox provider policy.

If the selector looks coherent but mail still fails authentication, compare the entered selector and domain with the exact s= and d= values from a failing message. Then inspect the receiver's authentication result for body-hash, canonicalization, timestamp, and DMARC alignment failures.

Technical Details:

DKIM key discovery starts with two signature fields: the signing domain and the selector. The DNS owner name is built as selector._domainkey.domain. TXT answers at that owner name are joined from quoted fragments when needed, then scanned for DKIM-style tag lists.

The record-level checks cover selector publication and key-record structure. They do not recompute a message body hash, verify a b= signature value, inspect the signed header list, apply canonicalization rules, or decide whether the DKIM signing domain aligns with the visible From domain. Those checks require the actual message as received.

Lookup Core:

Rule Core:

Formula Core:

For RSA selectors, the key-bit estimate comes from the decoded RSA modulus. Leading zero padding bytes are removed, then the first significant byte is used to subtract leading zero bits from the byte count.

Here B is the displayed bit length, n is the number of bytes in the trimmed modulus, and z is the count of leading zero bits in the first trimmed byte. A 257-byte DER integer with one leading padding byte and no leading zero bits after trimming is displayed as 8 * 256 - 0 = 2048 bits.

Privacy and Accuracy Notes:

The lookup sends the selector owner name to the selected public DNS resolver. It does not send message bodies, private keys, inbox data, or full mail headers, but the resolver can see the domain and selector being queried.

• Resolver caches can disagree after a DNS change, so compare resolvers or wait for cache expiry before assuming a new record is globally visible.
• TXT answers counts TXT records returned for the owner name, while Record count evaluates DKIM-looking records within that answer set.
• Malformed Base64, unusual key encoding, or unsupported key types can leave key bits unavailable even when a p value is present.
• A coherent selector does not prove that outgoing messages are currently signed, aligned, accepted, or delivered.

Worked Examples:

A setup check might use Signing domain as example.org and Selector as selector1. If Key Profile shows Selector host as selector1._domainkey.example.org, DNS status as 0 (NOERROR), Key type as RSA, and Key bits as 2048 bits, the main confirmation is that Validation Checks shows Healthy for record count, version tag, public key payload, RSA strength, and testing flag.

An older selector audit may return Key bits as 1024 bits. In that case, RSA strength becomes Review, while the selector may still have a non-empty public key payload. Treat that as a rotation target, especially before switching providers or enforcing stricter DMARC policy.

For a troubleshooting case, suppose a vendor says the selector is s1, but the report finds no DKIM record. Copy the actual s= value from a recent signed message header and run the lookup again. If the new selector host returns one DKIM record, the first result was a selector mismatch rather than a missing public key.

FAQ:

Glossary:

Selector

The DKIM label from s= that tells receivers which DNS key record to fetch.

Signing domain

The domain from d= that claims responsibility for the DKIM signature.

Selector host

The full DNS owner name built from the selector, _domainkey, and signing domain.

p tag

The DKIM key-record tag containing the public key, or an empty value when the selector is revoked.

t=y

A selector flag that marks the key as being in DKIM testing mode.

RSA modulus

The public-key number whose bit length is used for the RSA strength check.

References:

• RFC 6376: DomainKeys Identified Mail (DKIM) Signatures, RFC Editor, September 2011.
• RFC 8301: Cryptographic Algorithm and Key Usage Update to DomainKeys Identified Mail (DKIM), RFC Editor, January 2018.
• RFC 8463: A New Cryptographic Signature Method for DomainKeys Identified Mail (DKIM), RFC Editor, September 2018.