DKIM Checker and Validator

Introduction:

DomainKeys Identified Mail public keys are published as simple text records that live under a selector name for a domain. They signal which signing method is used and expose the public part needed to verify mail that claims to be from that domain.

Administrators use these records to confirm that email authentication is set up as intended and strong enough for present needs. Enter a domain and selector, then read the tags and the quick pass or fail checks to understand what is configured and whether it looks sound.

The lookup builds the full name from your selector and domain, follows a visible alias when present, and collects a single concatenated text value. A clear table reports the version, the declared key type, an estimated bit length, allowed services, hash algorithms, flags, caching time, and resolver status so you can act with confidence.

For example, a marketing domain might use the selector “default” and publish a strong key for all email. If a test flag is left on by mistake, the checks will call that out so you can tidy up before campaigns go live.

Results reflect the published record only, not the behavior of remote mail servers. If you are rotating keys, expect short periods where answers vary by resolver until caches settle.

Technical Details:

The subject is a DomainKeys Identified Mail (DKIM) DNS publication, observed as a text record at a fully qualified name formed from a selector and a domain. The tool measures the presence and content of DKIM tags, the resolver’s code and authenticated‑data flag, the record’s time to live, and a rough key size derived from the public key string.

Computation begins by following a canonical name target when present and then concatenating all text fragments at the target into one record string. The record is parsed into a map of key–value pairs using semicolons as separators. From the public key tag, an estimated key length in bits is computed from the Base64 length.

Results are summarized as simple checks. A correct version string indicates a DKIM key record, a present public key indicates a usable key, a service tag that includes email or all indicates a match for mail, a hash list that includes SHA‑256 indicates modern signing, and a clear flag shows that test mode is not left on. For RSA keys, 1024 bits is the minimum and 2048 bits is the recommended level; Ed25519 keys are fixed at 256 bits by design.

Comparability depends on resolver choice and cache state. The authenticated‑data indicator reflects the upstream resolver’s validation, not a full chain you control. Expect caching to influence the time to live you see across different networks.

1. Build the name as <selector>._domainkey.<domain>.
2. Query CNAME and record the target when present.
3. Query TXT at the target or original name.
4. Concatenate all text fragments into one value.
5. Parse semicolon‑separated tags into a map.
6. Estimate key bits from the Base64 length.
7. Evaluate version, key presence, service, hashes, flags, and size thresholds.

Units, precision, and rounding: Key bits are integers from the Base64 length using floor, time is rounded to whole milliseconds, and the decimal separator is a period. Time to live values are reported in seconds as returned by the resolver.

I/O formats and encoding: Inputs are plain strings for domain and selector. The output includes a tag map, an estimated key length, check results, and resolver metadata. DNS lookups request and parse application/dns-json responses, with a content parameter set for endpoints that require it.

Networking and storage behavior: Queries are issued from the browser to the chosen DNS‑over‑HTTPS endpoint. There is no server component, and no data is kept beyond the current page session.

Performance and complexity: At most two queries per resolver are attempted, so the worst case is eight network calls in auto mode. Response time reflects resolver latency and cache state.

Diagnostics and determinism: Identical published records yield identical tags and check outcomes. Timings and time to live can vary by resolver. The pass counter summarizes overall health at a glance.

Security considerations: Inputs are trimmed and used only to form DNS names. Returned text is displayed and copied as plain values. Do not paste secrets into fields. Use dedicated test records when experimenting.

• Key size is estimated from Base64 length, not from parsed modulus bytes.
• Only one visible alias hop is followed per lookup.
• Record validity is inferred from tags, not from live message signatures.
• Service tag interpretation is a simple string match for email or all.
• Hash list is checked only for the presence of SHA‑256.
• Test flag is treated as production‑unsafe when set.
• Heads‑up TTL may reflect authority hints when answer records are absent.
• DNSSEC authenticated‑data reflects the resolver, not an end‑to‑end chain you control.
• Only the listed resolvers are used; no system resolver fallback exists.
• Multiple records or split keys are concatenated without per‑part validation.

• NXDOMAIN, SERVFAIL, or REFUSED response codes prevent record discovery.
• Empty p= indicates revocation and will fail key‑present checks.
• Non‑Base64 characters in p= are stripped before size estimation.
• Quoted TXT chunks with stray quotes can alter concatenation.
• Unusual whitespace between tags may yield empty keys on parse.
• Multiple DKIM records at one name are not merged intelligently.
• Alias loops or deep chains are not detected beyond the first hop.
• Resolver‑specific caching can produce different TTLs moment to moment.
• Slow resolvers increase measured lookup time and can trigger retries.
• Transient network errors appear as a generic lookup failure message.

Scientific and standards backing: Behavior follows the DomainKeys Identified Mail specification, common DNS resource record conventions, and widely implemented DNS‑over‑HTTPS response formats.

Privacy and compliance: Operation is browser‑based. Queries are sent to the selected public resolver and are not stored server‑side. Treat internal hostnames as sensitive configuration data.

How to Use:

DKIM record inspection shows what a domain publishes and whether basic checks pass.

1. Enter the Domain you want to inspect.
2. Enter the Selector, or keep the default if unknown.
3. Pick a resolver or keep Auto for fallback behavior.
4. Run validation and wait for the status summary to appear.
5. Review tags, key size, and flags, then act on any failed checks.

• If results vary, try another resolver to confirm cache differences.

FAQ:

Troubleshooting:

• Confirm the selector name with your email platform documentation.
• Try a different resolver to bypass cache or regional issues.
• Remove any trailing dot from the domain field.
• Look for a CNAME that points to a hosted mail provider.
• Check that the record is a TXT at the DKIM name, not at the root.
• Wait for caches to expire if you made recent changes.

Advanced Tips:

Tip Keep a standard selector naming scheme across brands for easier audits.

Tip Rotate RSA keys on a regular cadence and retire any 1024‑bit keys.

Tip Use a short time to live during rollout, then raise it after validation.

Tip Prefer separate selectors for automated and human‑sent mail streams.

Tip Keep a change log of selector updates for incident reviews.

Tip Test from different networks to spot resolver‑specific anomalies.

Glossary:

Selector

Left label used to locate a domain’s key record.

TXT record

DNS text data that carries DKIM tags and values.

CNAME

Alias that points one name to another name.

TTL

Time a resolver may cache an answer.

Authenticated‑data

Resolver flag indicating validated DNSSEC.

RCODE

Numeric DNS response code such as NOERROR or NXDOMAIN.

RSA

Public‑key system with variable modulus size.

Ed25519

Curve‑based key with fixed 256‑bit size.

Service tag

Scope of use, often set to email or all.

Test flag

Indicator that a key is published for testing only.