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 }} |
Tag | Value | Copy |
---|---|---|
{{ key }} | {{ val }} |
DKIM Checks | Status |
---|---|
{{ c.label }} |
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.
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).
<selector>._domainkey.<domain>
(trims any trailing dot on the domain).CNAME
; if present, follow the alias as the effective target.TXT
at the alias or original name; strip surrounding quotes from each fragment and concatenate to reconstruct the record string.key=value
pairs separated by semicolons; unknown tokens are retained.Estimated key length is computed from the Base64 p=
value using:
Definitions: L is the Base64 character count (dimensionless); B is the byte estimate; bits is the derived key length in bits. Rounding uses floor.
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.
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. |
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.
Checks would mark RSA length ≥ 2048 as “recommended,” assuming k=rsa
and other tags are compatible.
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.
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.
Use this procedure to read and evaluate a selector’s published DKIM record.
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.
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.
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.
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.
Yes. One alias hop is attempted; the TXT is read from the target when present, and the alias name is reported alongside other fields.
No. DNS information is fetched over HTTPS from resolvers; without network access, validation cannot proceed and errors may be shown.
No license text is included in the package; consult the project’s distribution page or publisher for terms of use.
DomainKeys Identified Mail, a method for authenticating a domain’s use of email by verifying a header signature with a DNS‑published public key.
t=y
as temporary only; remove it before enabling broad sending.