DKIM Status
{{ fqdn }}
{{ keyBits }} bits TTL: {{ ttl }} {{ time }} ms Key: {{ keyType }} Checks: {{ passCount }}/{{ checks.length }}
Field Value Copy
FQDN {{ fqdn }}
Version (v) {{ tags.v || '—' }}
Key Type (k) {{ keyType }}
Key Bits (p) {{ keyBits }}
Hash Algos (h) {{ tags.h || '—' }}
Service Type (s) {{ tags.s || '—' }}
Flags (t) {{ tags.t || '—' }}
TTL {{ ttl }}
Lookup Time {{ time }} ms
DNSSEC AD {{ dnssecAD ? 'Yes' : 'No' }}
DNS Status {{ dnsStatusText }}
Resolver Used {{ resolverUsed || resolver }}
CNAME Target {{ alias || '—' }}
Raw Record {{ record }}
TagValueCopy
{{ key }} {{ val }}
DKIM ChecksStatus
{{ c.label }}

      

Introduction:

DomainKeys Identified Mail (DKIM) is a public‑key scheme that lets receiving servers verify a message’s domain authorization using DNS‑published keys. This utility works as a DKIM record checker that interprets a selector’s published tags and presents clear, actionable feedback. By inspecting the DNS text entry that advertises your public key and related policy fields, you can confirm configuration details that influence delivery, anti‑spoofing defenses, and downstream filtering decisions.

You provide a domain and a selector string; the tool composes the fully qualified name used by DKIM to publish keys. It resolves the destination in the Domain Name System, follows an alias when present, and reads the text record containing the version tag, public key material, hash preferences, service scope, and optional flags. Parsed values appear with timing and status indicators to support audits, scheduled key rotations, and troubleshooting without command‑line utilities.

Consider a key rotation where a new selector advertises a fresh public key and the preferred hashing algorithm. After the record propagates, you read the entry to verify the version value, service scope, and whether the apparent key length meets policy expectations. DNS caching and inconsistent resolvers can briefly obscure changes, so an observed value may lag behind the current zone file.

Technical Details:

Concept Overview

A DKIM selector publishes a verifying public key at a predictable name under the domain, allowing receivers to validate signatures in message headers. The record is delivered via DNS as a TXT payload and may be reachable through a canonical name (alias). This tool queries DNS over HTTPS (DoH), parses the semicolon‑separated tag list, estimates public‑key size, and evaluates best‑practice checks. It reports resolver status, an authenticity bit from DNSSEC validation, and the record’s time‑to‑live (TTL).

Core Equation or Process

  1. Compose the lookup name as <selector>._domainkey.<domain> (trims any trailing dot on the domain).
  2. Select a resolver: Auto tries Cloudflare → Google → Quad9 → OpenDNS in order; otherwise the chosen endpoint is used for DoH queries.
  3. Query CNAME; if present, follow the alias as the effective target.
  4. Query TXT at the alias or original name; strip surrounding quotes from each fragment and concatenate to reconstruct the record string.
  5. Parse tags as key=value pairs separated by semicolons; unknown tokens are retained.
  6. Derive metrics and checks: estimate key size from the Base64 public key, and evaluate version, service, hash, test flag, key type, and key length rules.
  7. Report TTL, lookup time, DNSSEC AD flag, resolver used, DNS status code/name, alias target, and raw record.

Estimated key length is computed from the Base64 p= value using:

B=3×L4 bits=8×B

Definitions: L is the Base64 character count (dimensionless); B is the byte estimate; bits is the derived key length in bits. Rounding uses floor.

Interpretation & Thresholds

Check Pass Criteria Reason/Implication
Record present Either p= or v= exists Confirms a DKIM TXT is published.
v tag equals DKIM1 v is exactly DKIM1 Indicates modern DKIM record syntax.
Public key present p= has a value Enables signature verification by receivers.
Service scope s= empty or includes email or all Allows use for email; restrictive scopes may block use.
Hash algorithms h= empty or includes sha256 Ensures SHA‑256 compatibility; SHA‑1 alone is discouraged.
Test flag t=y not present Avoids test‑mode behavior in production.
Key type: RSA k absent or contains rsa Default/explicit RSA accepted.
RSA length ≥ 1024 bits; ≥ 2048 bits recommended Meets minimal and preferred strength guidance.
Key type: Ed25519 k contains ed25519 Modern Edwards‑curve key.
Ed25519 length Exactly 256 bits Matches expected key size.

Passing checks indicate a correctly published key with broadly compatible parameters; warnings suggest configuration risk, policy constraints, or weaker cryptographic posture.

Variables & Parameters

Parameter Meaning Unit/Datatype Notes
Domain Organizational domain being validated Text (hostname) Trailing dot removed before lookup.
Selector Left‑hand label under _domainkey Text Combined to form the FQDN.
Resolver Chosen DNS‑over‑HTTPS endpoint Enum Auto attempts Cloudflare → Google → Quad9 → OpenDNS.
Auto‑validate Re‑run checks when inputs change Boolean Debounce delay is 200 ms.
TTL Record’s cache lifetime as reported Value from resolver Unit is whatever the resolver returns.
DNSSEC AD Resolver’s Authenticated Data flag Yes/No Reflects resolver validation, not a signature here.

Worked Example

Scenario: Domain example.com with selector default publishes a record at default._domainkey.example.com. The public key’s Base64 text has length L = 392.

B=3×3924=294=294 bits=8×294=2352

Checks would mark RSA length ≥ 2048 as “recommended,” assuming k=rsa and other tags are compatible.

Assumptions & Limitations

  • Bit length is estimated from Base64 length; ASN.1 structure overhead can inflate the number. Heads‑up
  • Only the first CNAME target is followed; deeper alias chains are not traversed.
  • TXT assembly removes only outer quotes per fragment and concatenates verbatim; no unescaping is applied.
  • “SHA‑256 present” and “service includes email/all” are the only hash/service tests performed.
  • TTL and DNSSEC fields are reported as returned by the resolver; units and validation path are not normalized.
  • Auto‑validate uses a 200 ms debounce; rapid edits may skip intermediate states.

Edge Cases & Error Sources

  • Internationalized domains must be provided in ASCII (Punycode) form; no conversion is performed. Heads‑up
  • Multiple TXT records at the name are concatenated; unrelated records could corrupt parsing. Heads‑up
  • NXDOMAIN, SERVFAIL, or REFUSED statuses surface as errors or empty records.
  • Missing domain input returns “Domain is required”; missing record yields “No DKIM record found.”
  • Clipboard or download actions can be blocked by browser permissions, affecting copy/export features.

Scientific/Standards Backing

DomainKeys Identified Mail is specified in RFC 6376; RSA key size guidance appears in RFC 8301; Ed25519 for DKIM is described in RFC 8463; DNS over HTTPS is standardized in RFC 8484.

Privacy & Compliance

Lookups are executed by your browser against selected DoH resolvers; no inputs or results are transmitted to or stored on an application server. Outputs are informational and do not guarantee message delivery or authentication.

Step‑by‑Step Guide:

Use this procedure to read and evaluate a selector’s published DKIM record.

  1. Enter your Domain (organizational domain to check).
  2. Enter the Selector used by your sending system.
  3. Optionally choose a Resolver or keep Auto to try several.
  4. Select Validate; the tool follows any CNAME and reads the TXT record.
  5. Review version, key type, key size estimate, hash list, service scope, flags, TTL, DNSSEC, and status.
  6. Export results using CSV or JSON if needed for change control or tickets.
  7. If t=y appears, switch the selector out of test mode before production sending.

Example: domain example.com, selector default → lookup name default._domainkey.example.com and evaluate the returned tags and checks.

FAQ:

Is my data stored?

No. The browser queries DNS‑over‑HTTPS endpoints directly, and results are rendered locally; there is no application server that stores your inputs or outputs.

How accurate is the key size?

It is an estimate from Base64 length using floor rounding; Ed25519 is expected at 256 bits, while RSA length includes encoding overhead and may read high.

Which units and formats are shown?

Lookup time uses milliseconds; TTL and the DNSSEC AD flag appear as provided by the resolver; DNS status shows the numeric code plus a name such as NOERROR or NXDOMAIN.

Does it follow CNAME targets?

Yes. One alias hop is attempted; the TXT is read from the target when present, and the alias name is reported alongside other fields.

Can I use it offline?

No. DNS information is fetched over HTTPS from resolvers; without network access, validation cannot proceed and errors may be shown.

What license applies?

No license text is included in the package; consult the project’s distribution page or publisher for terms of use.

What does DKIM stand for?

DomainKeys Identified Mail, a method for authenticating a domain’s use of email by verifying a header signature with a DNS‑published public key.

Troubleshooting:

  • “Domain is required” — Enter a valid domain before validating.
  • “No DKIM record found” — Confirm the selector spelling and DNS propagation status.
  • “Lookup failed” — Try another resolver or check firewall rules blocking DoH.
  • Key size seems odd — ASN.1 encoding inflates RSA byte counts; prefer the pass/fail bands over the exact number.
  • Unexpected JSON — Some resolvers return minimal Authority/Answer sections; copy the JSON tab when filing support tickets.

Advanced Tips:

  • Tip Use Auto first, then pin a resolver that consistently reflects your authoritative answers.
  • Tip Rotate selectors during key changes to keep old mail verifiable while new keys propagate.
  • Tip Treat t=y as temporary only; remove it before enabling broad sending.
  • Tip Prefer Ed25519 or ≥ 2048‑bit RSA where your sending platform supports it.
  • Tip Export CSV for change logs and JSON for resolver debugging artifacts.

Glossary:

DKIM
DomainKeys Identified Mail; domain‑based message authentication.
Selector
Left label that identifies a specific published key.
FQDN
Fully Qualified Domain Name used for lookup.
TXT Record
DNS text data carrying DKIM tags and values.
CNAME
Alias record that redirects a name to a target.
TTL
Resolver‑reported cache lifetime for a record.
DNSSEC AD
Authenticated Data flag indicating validated answers.
RSA
Widely used public‑key system for DKIM keys.
Ed25519
Edwards‑curve key with fixed 256‑bit size.
SHA‑256
Secure hash algorithm commonly required for DKIM.