DKIM Record Checker

Free online tool · DNS-over-HTTPS live lookup · runs in your browser, no data upload

DKIM (DomainKeys Identified Mail, RFC 6376) uses digital signatures to prove mail was not tampered with in transit and binds it to the sending domain. The signer signs with a private key; receivers fetch the public key from <selector>._domainkey.<domain> to verify. DKIM record lookup is the first step in troubleshooting issues like mail landing in spam or bounces with 554 — a missing public key or wrong selector are the two main causes of DKIM verification failure.

Enter a domain and DKIM selector (provided by your sending service, e.g. default, google, s1); the tool queries <selector>._domainkey.<domain> TXT records.

Features

  • Selector+domain lookup: queries TXT records at <selector>._domainkey.<domain> per DKIM DNS naming
  • Tag parsing: automatically parses v= k= p= s= t= tags, highlighting public key length and format validity
  • Key strength: classifies RSA 2048/1024-bit keys (RFC 8301 recommends 1024+ bits)
  • Multi-selector: query several selectors in a row to compare which ones exist

How to Use

DKIM records are located by “selector + domain”. The selector is set by your sending service (Tencent Cloud email push defaults to s1, Google Workspace to google, self-hosted OpenDKIM is customizable). Enter the domain and selector, click check, and the tool builds <selector>._domainkey.<domain> and runs a DoH TXT query, parsing the v/k/p/s/t tags and assessing public key strength. On failure, first confirm the selector spelling, then check whether DNS has propagated (wait for TTL).

Why Check Regularly

DKIM (DomainKeys Identified Mail, RFC 6376) uses digital signatures to verify whether a message was tampered with in transit and binds the message to its sending domain. It does not directly judge sender identity; it provides evidence of “content integrity + domain association”.

Typical DKIM failure scenarios: private key not migrated after changing mail servers, expired public key records in DNS (TTL elapsed), or a selector that does not match the signature header. These failures rarely error out immediately — they quietly degrade reputation and push mail to spam.

Checking DKIM records with this tool confirms the public key is published correctly in DNS, the key length meets security standards (RFC 8301 recommends 1024+ bits; 2048 recommended), and the record format matches the signing algorithm (rsa-sha256 etc.).

Interpreting Results

CheckPass CriteriaRisk
Public key record existsTXT record for selector._domainkey is resolvableNone
Key length≥1024 bits (RFC 8301); 2048 recommendedMedium
Record formatStarts with v=DKIM1 and contains p= public key fieldHigh
Selector matchs= selector in signature header matches queried selectorHigh
TXT record countOnly one DKIM record under the same selectorMedium

Common Misconfigurations & Fixes

  • Public key record lost：Republish the key: after generating a new key pair, paste the p= field into the selector._domainkey TXT record
  • Key too short：Regenerate a 2048-bit RSA key (some DNS providers limit TXT length; split if needed)
  • Selector mismatch：Ensure the selector configured on the signing server exactly matches the published one
  • Record truncated：TXT records are limited to 255 chars/segment; split long keys per standard and wrap in quotes
  • Rotation incomplete：Publish the new public key before switching private keys; wait for TTL to expire before changing signing config to avoid verification failures

Technical Standards

This tool follows the IETF standards below; lookup and parsing logic match the RFC definitions:

  • DNS lookup: RFC 8484 (DNS Queries over HTTPS), RFC 1035 (DNS protocol)
  • Record parsing: DKIM: RFC 6376 §3.6.1 (DNS naming), RFC 8301 (key strength), RFC 8463 (ED25519)