DKIM Checker

A DKIM record is a DNS TXT record published at <selector>._domainkey.<domain> . It contains a public key that receiving mail servers retrieve to verify the cryptographic signature in the email's header. The sending server signs outgoing mail with the corresponding private key. If the signature matches the public key in DNS, the message is considered authentic and unmodified in transit.

A selector is a label that forms part of the DNS lookup path. Because a domain can publish multiple DKIM keys (for different sending services or key rotation), the selector tells receivers which specific key to fetch. It appears in the d= and s= fields of the DKIM-Signature header on every signed email. Selectors are not listed in any standard DNS record, so they must be known in advance or guessed from common values.

When no selector is provided, the tool issues DNS TXT queries for a predefined list of common selector names in sequence: default , google , mail , selector1 , selector2 , dkim , email , and a set of date-based Gmail selectors. It stops at the first one that returns a valid TXT record. If none match, the tool reports that no DKIM record was found and prompts you to enter the selector manually.

A revoked key means the DNS record exists but the public key tag is empty ( p= ). This is the standard DKIM mechanism for retiring a key without removing the record entirely. Receiving mail servers that encounter an empty p tag treat any signature using that selector as invalid. The checker distinguishes this from a missing record or a malformed record, reporting it specifically as a revocation rather than an error.

Three warnings are worth acting on. First, a short RSA key (below 1024 bits, sometimes below 2048 bits depending on policy) is considered cryptographically weak and can be broken. Second, t=y means the domain is in testing mode, so receivers may not enforce DKIM failures. Third, h=sha1 alone flags use of a deprecated hash algorithm. Each of these represents a real deliverability or security risk rather than a cosmetic issue.

DKIM operates at the message level. It attaches a cryptographic signature to an email and publishes the corresponding public key in DNS so receivers can verify the signature. DMARC operates at the policy level. It reads the results of DKIM and SPF checks and tells receivers what to do when those checks fail (nothing, quarantine, or reject). DKIM proves integrity; DMARC enforces a response. You can inspect your DMARC configuration with the DMARC Checker .

The most common reasons are DNS propagation delay (records can take minutes to hours to become visible globally), a selector mismatch (the auto-detection list does not include every possible selector), or a typo in the DNS entry. Try entering the exact selector your email provider gave you. If the record still does not appear, verify the TXT record is saved correctly in your DNS provider's control panel and check that the hostname format matches <selector>._domainkey.<domain> exactly.

Yes. The checker reads and reports the key type tag ( k= ) and handles both rsa and ed25519 records. Ed25519 produces shorter keys with strong security properties, but receiver support is not yet universal. Some older mail servers do not verify ed25519 signatures at all, which means a valid signature may still be treated as unsigned. The checker reports the key type so you can assess compatibility with your recipient base.

Yes. The tool exposes a GET endpoint at /api/check-dkim?domain=<domain>&selector=<selector> . The response is JSON and includes fields for dkim_found , selector , dkim_record , is_valid , errors , warnings , tags , key_type , public_key_length , and has_version . This makes it straightforward to integrate DKIM validation into monitoring scripts or deployment pipelines that verify DNS records after configuration changes.

No. The v=DKIM1 tag is recommended by the specification but not strictly required. Mail receivers are expected to accept records without it. The checker reports whether the version tag is present via the has_version field, but its absence does not cause a validation failure. Including it is considered good practice because it makes the record's purpose unambiguous to anyone reading the raw DNS data.

The lookup is a read-only DNS query. The tool queries the DNS record for the domain you provide and returns the result. No personal data is submitted as part of a DKIM check since domain names are public DNS information. For full details on how Pingie handles data, see the privacy policy .

Run a check after any DNS change, email provider migration, or key rotation. It is also worth verifying after your domain's DNS is transferred to a new registrar, since zone file imports occasionally drop or corrupt TXT records. If you use multiple sending services (transactional email, marketing platforms, CRMs), check each selector separately because they are independent records that can break independently.