{{ summaryTitle }}
{{ summaryValue }}

{{ summaryLine }}

Resolver{{ resolverLabel }} Records{{ resultsReady ? computation.values.record_count : '—' }} Key{{ resultsReady ? keySummary : '—' }}
Enter one public domain, such as example.com. A pasted URL is reduced to its hostname.
Common examples include default, google, selector1, and s1.

{{ runStatus }}

Change resolver when comparing propagation or cache views. The selected provider can observe the queried owner name.
Selector report
{{ overallStatusLabel }}
{{ row.label }}{{ row.value }}
{{ section.title }}

{{ section.body }}

CheckStatusObservedNext stepCopy
{{ row.label }}{{ row.statusLabel }}{{ row.observed }}{{ row.action }}

The chart renderer is unavailable. The same counts remain available in the evidence ledger and JSON handoff.

DMARC Validation Report Validate a domain's DMARC policy and check syntax, alignment and external report receivers before making stricter mail enforcement changes.
SPF Validation Report Check a domain's SPF record, trace include and redirect dependencies, and flag duplicate policies or lookup-budget risks from public DNS.
DKIM DNS Record Generator Build a DKIM TXT record from a selector and public key with validation and DNS string splitting, plus rollout checks before publishing.
MX Record Lookup Inspect a domain's MX route and compare public DNS answers while catching Null MX conflicts, unresolved exchanges, and alias targets.

DomainKeys Identified Mail (DKIM) lets a receiving mail system check that selected message content was signed by an organization controlling a domain. The message carries a signature header, while the corresponding public key is published in DNS. A receiver combines both pieces to verify the signature without learning the private key.

Two fields locate that public key. The signing domain comes from the signature's d= value, and the selector comes from s=. Together they form a DNS owner such as selector._domainkey.example.com. Checking the wrong selector or the visible From domain instead of the actual signing domain commonly produces a false missing-record diagnosis.

Selector
A label chosen by the signer so keys can be rotated or separated by service.
Key record
A semicolon-delimited TXT value containing tags such as version, key type, public key, hash policy, service scope, and testing flags.
Revoked selector
A key record with an empty p= value, which tells verifiers that the selector no longer has a usable public key.

Publication quality matters because a valid message signature cannot be checked when the DNS owner is wrong, the key payload is malformed, or restrictive tags exclude the signature's algorithm or email service. Key size also affects security and interoperability: Ed25519 keys use a fixed 256-bit public key, while RSA keys need enough modulus strength for current DKIM practice.

A healthy DNS record is necessary but not sufficient. It does not prove that outgoing messages are signed, that a particular message verifies, that the body and signed headers were preserved, or that DKIM aligns for DMARC. Message-level troubleshooting still requires the received headers and signature data.

How to Use This Tool:

Use the signing domain and selector from a recent DKIM-Signature header or from the mail provider that publishes the key.

  1. Enter the d= signing domain, not an email address or an assumed organizational domain.
  2. Enter only the s= selector label. The DNS owner name is assembled automatically.
  3. Choose Cloudflare DNS or Google Public DNS when a second recursive-resolver view would help distinguish a record problem from cache or propagation delay.
  4. Select Validate, then start with the first non-healthy item in the evidence ledger.
  5. After publication checks are healthy, verify a newly received signed message to confirm the signature, signed headers, body hash, and alignment behavior.

Interpreting Results:

Healthy means all ten publication checks passed in the selected resolver view. Review identifies a missing record, an RSA key from 1024 through 2047 bits, an unreadable RSA size, or the t=y testing flag. Needs attention means at least one stronger failure was found, such as a DNS error, duplicate key records, invalid tags, or unusable key material.

The status is severity-based rather than an average: any attention item controls the overall result, otherwise any review item does. Compare resolvers when a record was just changed, but use message-level verification before concluding that production mail is authenticating correctly.

Technical Details:

DKIM key publication uses a DNS TXT record containing tag-value pairs. Quoted TXT fragments are joined without added spaces, tag names are compared case-insensitively, and records containing a p= tag are treated as DKIM key records. Omitting k= selects RSA by default; omitting v= uses the DKIM1 default.

Lookup Core

StageMechanismFailure meaning
Owner constructions= selector + ._domainkey. + d= signing domainA correct key published at another owner will not be discovered.
TXT retrievalOne explicit query through the selected public recursive resolverCache state and resolver policy can differ from another viewpoint.
Record selectionTXT values with a p= tag are counted as DKIM key recordsZero records needs confirmation; multiple effective records are ambiguous.
Tag parsingSemicolon-separated names and values are preserved, including an empty valueDuplicate names or an empty public key can invalidate or revoke the selector.

Rule Core

The report applies ten checks in a fixed order. The counts of healthy, review, and attention results always add to ten.

CheckHealthy conditionReview or attention condition
DNS responseResolver returns NOERROR.Any other response needs attention.
Record countExactly one DKIM key record.Zero is Review; more than one needs attention.
Versionv=DKIM1 is first, or v= is omitted.An explicit invalid or misplaced version needs attention.
Tag uniquenessNo duplicate tag names.Any duplicate needs attention.
Key typeRSA or Ed25519.Another advertised type needs attention.
Public keyp= contains decodable key material; Ed25519 decodes to 32 bytes.Missing, empty, malformed, or wrong-length material needs attention.
Key strengthRSA is at least 2048 bits, or Ed25519 is 256 bits.RSA 1024 to 2047 bits or unreadable size is Review; below 1024 bits needs attention.
Hash policyh= is omitted or includes sha256.A restrictive list without SHA-256 needs attention.
Service scopes= is omitted, wildcarded, or includes email.A scope excluding email needs attention.
Testing flagt=y is absent.t=y produces Review.

Formula Core

RSA strength is estimated from the decoded modulus. Leading padding bytes are removed before the first significant byte determines the remaining leading zero bits.

B = 8 ⁢ n − z

B is the displayed bit length, n is the number of bytes in the trimmed modulus, and z is the number of leading zero bits in its first byte. A DER integer containing one leading padding byte may therefore still represent a 2048-bit RSA modulus after trimming.

Privacy and Accuracy Notes:

The selected public resolver receives the selector owner name, revealing which domain and selector are being investigated. Results describe one cached resolver view at one moment and can differ during propagation.

RSA size extraction can be unavailable for malformed or unexpected encodings. The report never sees a private key or message content and does not perform cryptographic verification of an email message.

Worked Examples:

Ed25519 key still marked for testing

A selector returning one v=DKIM1; k=ed25519; p=…; t=y record with a 32-byte decoded key passes nine checks. The testing flag changes the tenth check to Review, so the overall result is Review even though the key length and record structure are healthy. Remove t=y only after testing is complete and normal receiver treatment is intended.

References: