# DKIM Record Checker > Resolve a DKIM selector, follow provider aliases, parse its public-key record, inspect RSA or Ed25519 key material, and export an evidence bundle for DNS and deliverability owners. - **Category:** Deliverability - **Updated:** July 2026 - **Canonical page:** [https://emailbump.com/tools/dkim-record-checker](https://emailbump.com/tools/dkim-record-checker) - **Interactive tool:** [Open the DKIM record checker](https://emailbump.com/tools/dkim-record-checker) ## What the tool does The checker evaluates one DKIM public-key selector in either live-DNS or draft-record mode. Live mode: - Constructs the DNS name from the signing domain and selector - Queries the TXT record through Google Public DNS over HTTPS - Disables EDNS Client Subnet in the request - Follows a CNAME delegation chain up to a safety limit - Preserves resolver status, TTL, and DNSSEC Authenticated Data evidence - Separates DKIM-looking TXT values from unrelated TXT records Both modes: - Parse the DKIM tag-value list - Detect malformed and duplicate tags - Validate the record version and tag order - Decode the public key from base64 - Parse RSA DER public-key material and measure the modulus - Validate an Ed25519 key's required 32-byte length - Compute a SHA-256 fingerprint of the public key in the browser - Identify revoked selectors - Evaluate hash, service, and testing restrictions - Explain default tag values - Export the evidence and findings as JSON Draft record contents stay in the browser. In live mode, the queried selector name is sent to Google's DNS-over-HTTPS resolver. ## Start with a real message DKIM records are not normally published at the bare domain. A verifier uses two values in the message's `DKIM-Signature` header: - `d=` is the Signing Domain Identifier - `s=` is the selector The DNS name is: ```text ._domainkey. ``` For this header fragment: ```text DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1; ... ``` the public-key query is: ```text selector1._domainkey.example.com ``` Use the values from a message that represents the sending stream under investigation. Guessing common selectors such as `default`, `google`, `selector1`, or `s1` can find a record, but it cannot prove that the active sender uses that record. One domain can publish many selectors at the same time. This is normal during rotation and when several sending systems sign for the domain. ## What DKIM establishes DomainKeys Identified Mail associates a signing domain with a cryptographic signature over selected message headers and the body. The signer creates the signature with a private key. A receiver retrieves the corresponding public key from DNS and verifies the message. A successful signature indicates that: - The signer had the private key corresponding to the published public key - The signed header fields still match under the chosen canonicalization - The signed portion of the body still matches its hash - The signature identifies the domain in `d=` as taking responsibility for the message DKIM does not encrypt the message. It does not establish that the visible From address belongs to an individual. It does not independently express a rejection policy. It does not guarantee that every visible header was signed. ## RSA algorithm and key-size rules RFC 8301 updates the original DKIM cryptographic requirements. For RSA: - Signers must use RSA-SHA256 - Verifiers must support RSA-SHA256 - RSA-SHA1 must not be used for signing or verification - A signing key must be at least 1,024 bits - Signers should use at least 2,048 bits - Verifiers must not consider a signature made with an RSA key shorter than 1,024 bits valid - Verifiers must be able to validate RSA keys from 1,024 through 4,096 bits The checker reads the RSA modulus rather than estimating strength from the length of the base64 text. That matters because the encoded value contains structure, algorithm identifiers, an exponent, and padding in addition to the modulus. A 1,024-bit RSA key satisfies the current minimum but not the recommendation. Treat it as a rotation candidate. A key shorter than 1,024 bits is a blocking standards failure. Long RSA keys can require a DNS TXT resource record to contain several quoted character strings. DNS consumers concatenate those strings without adding spaces. Splitting one TXT resource record into chunks is normal. Publishing several separate competing key records is a different condition and can cause verifier-dependent behavior. ## Ed25519 keys RFC 8463 adds the Ed25519-SHA256 DKIM signing method. An Ed25519 selector uses: ```text k=ed25519 ``` The decoded public key is exactly 32 bytes, or 256 bits. That numeric length is not comparable to RSA bit lengths; the algorithms and security properties are different. The checker validates the fixed encoded-key requirement rather than labeling 256 bits as weak. Deployment support and provider configuration still matter. A structurally valid Ed25519 key does not show that a sending platform signs with Ed25519 or that a particular receiver processed the signature successfully. During an algorithm transition, a message can carry more than one DKIM signature. ## Public-key record tags A DKIM key record is a semicolon-separated tag-value list. ### v — version `v=DKIM1` identifies the record version. The tag is optional, but when it appears, it must be the first tag. An unrecognized version must be ignored by a verifier. ### p — public-key data `p=` is required. For an active selector it contains base64 public-key material whose format is determined by `k=`. An empty value: ```text p= ``` means the selector is revoked. A verifier treats a signature using that key as a permanent failure. A revoked record is therefore intentionally not an active usable key. ### k — key type `k=` identifies the public-key algorithm. Its default is `rsa`. RFC 8463 registers `ed25519`. The checker accepts RSA and Ed25519. An unknown key type is not usable by this analysis and is reported as blocking. ### h — allowed hash algorithms `h=` restricts the hash algorithms that may be used with the key. Values are separated by colons. If omitted, the default permits all recognized algorithms. An explicit list that allows only `sha1` excludes the required SHA-256 path and makes the key unusable for current RSA DKIM. Listing SHA-1 alongside SHA-256 is also discouraged because RFC 8301 made SHA-1 historic and prohibited its use for DKIM signing and verification. ### s — service types `s=` restricts the services for which the key is valid. The default wildcard permits all services. A DKIM email key must permit `email` or the wildcard. Do not confuse the public-key record's `s=` service tag with the DKIM-Signature header's `s=` selector tag. They use the same letter in different structures. ### t — selector flags Flags are separated by colons. `t=y` marks testing mode. It asks a verifier not to treat a message from the signer differently based solely on a testing-key failure. The exact receiving policy remains local. Remove testing mode after a controlled rollout. `t=s` requires the domain portion of the Agent or User Identifier to be exactly the signing domain. Without it, the AUID domain may be the signing domain or one of its subdomains. ### n — notes `n=` is a human-readable note for administrators. Software does not assign it authentication semantics. Use it sparingly because DNS response size and record maintenance matter. ### Unknown tags DKIM is extensible. Unrecognized key-record tags are ignored. The checker reports them as information so an operator can confirm whether they are intentional extensions or old configuration artifacts. ## CNAME delegation A selector can be a CNAME that points to a name controlled by a sending provider. Delegation lets the provider manage the public-key record and rotate key material while the customer's visible signing domain remains stable. The checker follows the alias and reports the chain. Review it as an ownership dependency: - Confirm the target belongs to the expected provider - Confirm the provider still sends authorized mail for the domain - Track which team owns the vendor relationship - Remove unused selector aliases after a migration - Recheck the target when the provider announces a rotation A working CNAME is not inherently weaker than a direct TXT record. It does add an external operational dependency and another DNS name that must remain resolvable. The tool stops following aliases after a bounded depth and rejects loops. That is an analysis safety limit, not a DKIM protocol limit. ## DNSSEC evidence The live resolver response can include the Authenticated Data flag when it validated a DNSSEC chain. The checker records that signal. DKIM does not require DNSSEC. A response without authenticated data is not automatically a DKIM error. It means this resolver did not provide cryptographic authentication of the DNS answer in this transaction. DNSSEC also does not prove the sender holds the matching private key or that the message signature is correct. It protects the integrity and origin of DNS data within its validation model. ## Multiple key records RFC 6376 allows a verifier that receives multiple key records to choose one or cycle through them. The order is unspecified, so behavior can differ. For predictable operations, publish one public-key record per selector. Remember that several quoted strings inside one TXT resource record are not several key records; they are concatenated into one value. The checker analyzes the first DKIM-looking record and warns when more than one is present. Its verdict should not be read as a simulation of every receiver's record-selection behavior. ## Safe selector rotation Selectors make key rotation possible without an abrupt replacement at one DNS name. Recommended sequence: 1. Generate a new key pair in the signing system. 2. Create a new selector name rather than overwriting the active selector. 3. Publish the new public key. 4. Wait for DNS publication and relevant caches. 5. Confirm the new selector resolves through independent DNS paths where appropriate. 6. Configure the signer to use the new private key and selector. 7. Send representative messages to several mailbox providers. 8. Inspect the delivered `DKIM-Signature` and `Authentication-Results` headers. 9. Confirm the expected signing domain, selector, algorithm, and DKIM pass. 10. Retain the old public key while delayed and queued messages can still arrive. 11. Remove or revoke the old selector after the transition window. 12. Archive the rotation date, owner, fingerprint, and provider configuration. Do not reuse a selector immediately with different key material. A receiver looking up a delayed message may retrieve the new key and fail to validate a signature made with the former private key. An empty `p=` record explicitly revokes a selector but does not create a grace period. Retaining the former public key during a controlled transition is normally what permits delayed signatures to verify. ## DKIM and DMARC alignment A DKIM pass is not automatically a DMARC-aligned DKIM pass. DMARC compares the authenticated DKIM signing domain in `d=` with the domain in the visible RFC 5322 From header. Under relaxed alignment, the domains may share an organizational domain. Under strict alignment, they must match exactly. Examples: - Visible From `alerts@example.com`, DKIM `d=example.com`: aligned - Visible From `alerts@news.example.com`, DKIM `d=example.com`: relaxed alignment can pass; strict alignment does not - Visible From `alerts@example.com`, DKIM `d=vendor.example`: DKIM may pass, but it is not aligned for `example.com` Use a real message and its Authentication-Results header to evaluate the outcome. The selector checker only sees the public-key side. ## Published key versus verified message A coherent selector record proves a narrow fact: the queried DNS path returned structurally usable public-key material. It does not prove: - The outbound system has the corresponding private key - The sender used this selector on the message being investigated - The message used RSA-SHA256 or Ed25519-SHA256 - The body hash is correct - Signed headers remained unchanged - The visible From domain aligns with the signing domain - The signature covers every security-relevant header - A receiver accepted or trusted the result - An intermediary did not modify signed content Always pair DNS inspection with header evidence from actual delivered mail. ## Recommended diagnostic workflow 1. Obtain the complete original source of a representative message. 2. Find every DKIM-Signature header; a message may have several. 3. Record `d=`, `s=`, `a=`, `c=`, `h=`, timestamp, and expiration data. 4. Check the exact selector and signing domain. 5. Review record syntax, key type, strength, service, testing, and revocation state. 6. Confirm any CNAME target belongs to the expected provider. 7. Compare the result with the receiver's Authentication-Results header. 8. If the result is body-hash failure, inspect content modifications, gateways, footers, and canonicalization. 9. If no key is found, distinguish DNS propagation or temporary resolver failure from a genuinely missing selector. 10. Evaluate DMARC alignment separately. 11. Export the checker JSON when coordinating with DNS, security, or vendor owners. ## Limitations The checker does not: - Verify a complete DKIM-Signature against a message - Accept an EML file or parse Authentication-Results - Prove possession of the private key - Query every public resolver or authoritative server - Guarantee that another receiver has the same cached answer - Evaluate DNS propagation globally - Calculate DMARC organizational domains or alignment - Inspect signed-header selection - Evaluate canonicalization - Detect a compromised private key - Determine whether a CNAME target is organizationally authorized - Model every verifier's behavior when several key records exist - Replace production-message tests The SHA-256 fingerprint is calculated over the decoded published key bytes. It is useful for change tracking, but it is not a certificate fingerprint and does not establish trust by itself. ## Frequently asked questions ### Where can I find the selector? Open the original source of a delivered message and find `s=` in a DKIM-Signature header. Use `d=` from the same signature as the signing domain. ### Why does default._domainkey return nothing? The sender may not use `default`. Selectors are arbitrary names chosen by the signer or provider. Inspect a real signature rather than guessing. ### Is a 1,024-bit RSA key valid? It meets the RFC 8301 minimum but not the recommendation of at least 2,048 bits. Plan a new selector and controlled rotation. ### Why is my 2,048-bit key split into quoted pieces? A DNS TXT resource record can contain several character strings that are concatenated by consumers. This is normal. Do not add spaces between the chunks. ### Does an empty p= mean the record is broken? It means the selector is revoked. That may be intentional, but messages signed with its private key cannot verify. ### Can I delete the old key immediately after switching? Delayed and queued messages signed with the old private key may still be in transit. Retain the old public key through an appropriate transition window. ### Does DNSSEC make DKIM pass? No. DNSSEC can authenticate the DNS answer. DKIM still has to validate the message signature, and DMARC still has to evaluate alignment and policy. ## Primary sources - [RFC 6376: DomainKeys Identified Mail Signatures](https://www.rfc-editor.org/rfc/rfc6376.html) - [RFC 8301: DKIM cryptographic algorithm and key usage update](https://www.rfc-editor.org/rfc/rfc8301.html) - [RFC 8463: Ed25519-SHA256 for DKIM](https://www.rfc-editor.org/rfc/rfc8463.html) - [IANA DKIM Parameters Registry](https://www.iana.org/assignments/dkim-parameters/dkim-parameters.xhtml) - [Google Public DNS JSON API](https://developers.google.com/speed/public-dns/docs/doh/json) ## Related guidance - [DKIM definition](https://emailbump.com/glossary/dkim.md) - [DMARC definition](https://emailbump.com/glossary/dmarc.md) - [Email authentication definition](https://emailbump.com/glossary/email-authentication.md) - [DMARC record builder](https://emailbump.com/tools/dmarc-record-builder.md) - [SPF lookup budget checker](https://emailbump.com/tools/spf-record-checker.md) - [Gmail via-label and DKIM alignment guide](https://emailbump.com/blog/gmail-via-label-dkim-alignment.md) - [Sending domains documentation](https://emailbump.com/docs/domains.md)