DKIM Validation Report

A DomainKeys Identified Mail, or DKIM, record is the DNS entry that tells receiving mail systems which public key belongs to a sending domain's selector. When that record is missing, weak, or still marked for testing, valid signatures can fail or an old key can linger longer than you expect. This validator looks up the published record and turns it into readable checks.

That matters most during first rollout and key rotation. A control panel can say DKIM is enabled while public DNS still answers with an older TXT value, a delegated alias, or a record that does not match the policy you meant to publish. Here the output is tied to the hostname that receivers can actually query.

A typical use case is checking a selector after moving from one mail provider to another. The tool assembles the full owner name, follows a published alias when one exists, and reports the version tag, key family, estimated key size, service and hash restrictions, cache time, and resolver status in one place.

That makes it easier to catch quiet publication problems before they turn into deliverability questions. If the record still carries t=y, if the hash list does not mention SHA-256, or if an RSA key sits in the older 1024-bit range, the warning appears immediately instead of hiding inside raw DNS output.

A strong result does not mean mail is currently signed, aligned, or accepted everywhere. This page reads DNS publication only. It does not inspect a live message, evaluate SPF or DMARC behavior, or prove that every resolver has dropped an earlier cached answer.

Everyday Use & Decision Guide:

If you are checking a normal deployment, start with the selector your mail provider gave you and leave Resolver on Auto. Before you trust the rest of the page, make sure the generated FQDN matches the hostname in your provider's instructions. A single selector typo can make the whole lookup look broken.

• Read DKIM Overview first. If Raw Record is empty or DNS Status is not 0 (NOERROR), the later checks are not the main problem yet.
• Use Tags when you want to compare the parsed record with vendor documentation or a zone-file export.
• Treat Validation Checks as quick triage. A high pass count means the published record looks internally consistent, not that every message path is healthy.
• If a result changes between retries, note TTL, Resolver Used, and CNAME Target before you edit DNS. Those fields often explain propagation or delegation issues.

The common misread is treating No DKIM record found as proof that DKIM itself is misconfigured. Often the record exists under a different selector, a provider has delegated the lookup through an alias, or caches have not converged after a change. When CNAME Target appears, compare that target with your provider's published hostname before you touch the TXT value.

Before you move on, check that Key Bits (p), Flags (t), and Hash Algos (h) still match the policy you intended to publish.

Technical Details:

DKIM key records live at a DNS owner name shaped like selector._domainkey.domain. The record is a semicolon-separated tag list where v identifies the record type, p holds the public key, and optional tags such as k, h, s, and t refine how that key is meant to be used. Receiving systems use those published tags while checking message signatures, but this tool stays focused on the published key record itself.

The lookup path is straightforward and visible. The page builds the owner name from Domain and Selector, asks the chosen DNS-over-HTTPS resolver for a CNAME answer first, and then requests TXT at the alias target or at the original owner name when no alias exists. Long TXT answers are concatenated into one string before parsing, which matters because DKIM public keys are often split across multiple quoted fragments in DNS.

After parsing, the tool estimates Key Bits (p) from the Base64 text length instead of decoding the key structure. That is good enough for rough policy checks and for spotting obviously weak RSA publications. It also records TTL, lookup time, DNS Status, DNSSEC AD, and Resolver Used, so you can separate a genuinely bad record from propagation or resolver differences.

Those diagnostics matter because DKIM publication is sensitive to cache state. One resolver may still serve an older answer while another already sees the new key, and a delegated alias can move the real TXT record somewhere you were not expecting. That is why the page exposes the full chain of what it asked and what it received instead of reducing everything to one opaque score.

Rule Core

The pass or fail logic is deliberately narrow. It checks publication quality signals that administrators commonly want to confirm during rollout, not every nuance of the DKIM specification.

Formula Core

The size estimate is a fast publication check, not a deep key parser. The package converts Base64 text length into an approximate byte count and then into bits.

If the cleaned p value is 342 characters long, the estimate becomes 8 * floor(3 * 342 / 4) = 2048 bits. That is accurate enough for the package's threshold checks, but it should not be mistaken for a full cryptographic inspection of the key material.

Step-by-Step Guide:

Use the page as a publication check, then decide whether the problem is the record itself or the path to the record.

1. Enter Domain and Selector. The read-only FQDN should immediately show the exact owner name you expect to exist in DNS.
2. For a normal first pass, leave Resolver on Auto. Open Advanced and pick Cloudflare, Google, Quad9, or OpenDNS only when you are comparing resolver behavior.
3. Click Validate or turn on Auto validate. A successful lookup fills DKIM Overview; a failed one shows Domain is required, No DKIM record found, or Lookup failed.
4. In DKIM Overview, read Raw Record, DNS Status, Resolver Used, CNAME Target, and TTL before you focus on pass counts.
5. Open Validation Checks and compare Key Bits (p), Flags (t), and Hash Algos (h) with the policy you meant to publish. If the record is RSA and the size line misses the recommended threshold, plan a rotation even if the minimum still passes.
6. If the lookup fails, go back to FQDN first. Correct the selector, wait out a short TTL, or verify the alias in CNAME Target. When the record looks right but behavior is still odd, use JSON to inspect the raw DNS response.

Interpreting Results:

The first question is whether the page actually retrieved a record. If Raw Record is present and DNS Status is 0 (NOERROR), the rest of the output is describing a real published answer rather than a guess.

• For RSA, Key Bits (p) >= 2048 is the stronger target, 1024 <= Key Bits (p) < 2048 is older but still above the tool's minimum, and Key Bits (p) < 1024 fails the size rule.
• If Flags (t) contains y, the record still advertises test mode. That can be intentional during rollout, but many production domains will want to remove it later.
• DNSSEC AD = Yes increases confidence in the DNS answer from that resolver. It does not prove that outbound messages are signed, aligned, or passing DMARC.
• If CNAME Target is populated or TTL is short, treat mismatched answers as a propagation question first. Verify the alias target and requery after caches have had time to expire.

Worked Examples:

A steady RSA publication

A domain owner checks a live selector after finishing provider setup. DNS Status returns 0 (NOERROR), Raw Record contains v=DKIM1; k=rsa; p=..., Key Bits (p) lands at 2048, and Checks shows 9 out of 9. That is the profile you want for a conventional RSA deployment: the record exists, the version is right, the key is present, and the stronger RSA threshold is met.

An older key that still verifies the minimum

Another selector returns a valid RSA record, but Key Bits (p) comes back as 1024 and Checks stops at 8 out of 9. Nothing here says the record is unreadable; it says the publication is still on an older key size that misses the package's recommended threshold. The right follow-up is to schedule key rotation, not to assume the TXT syntax is broken.

A rollout that looks empty because the selector is wrong

An administrator types newsletter instead of the provider's actual selector and clicks Validate. The page shows No DKIM record found, Raw Record stays empty, and there is no useful pass count yet. The corrective path is to compare the generated FQDN with the provider document, then check whether the provider expected an alias under CNAME Target or whether the change is still inside the published TTL.

FAQ:

Glossary:

• Selector. Label that chooses which DKIM key a domain publishes.
• TTL. Cache lifetime that influences how long old DNS answers persist.
• DNSSEC AD. Resolver flag marking the answer as authenticated by DNSSEC validation.
• Ed25519. Elliptic-curve signing key family with a fixed 256-bit public key size.
• Service tag. The s tag that narrows intended service use.

References:

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