dkim.fyi

A small, exact tool for one job

What DKIM is

DomainKeys Identified Mail (RFC 6376) lets a sending domain sign outgoing messages. The signature sits in a DKIM-Signature header and names two things: the signing domain (d=) and a selector (s=). A receiver builds the DNS name selector._domainkey.domain, fetches the TXT record published there, and uses the public key inside to check the signature.

Because the selector is part of the name, one domain can publish many keys at once: one per mail system, per year, per rotation. That is also why a domain’s selectors cannot be listed. DNS has no “show me everything under _domainkey” query.

What dkim.fyi does

  • Validate. You give a domain and a selector; dkim.fyi fetches the record, follows CNAME chains, parses the tags, imports the key to measure it, and reports a verdict with plain-language findings.
  • Discover. Without a selector, dkim.fyi reads the domain’s MX, SPF and DMARC records to guess which providers are in play, then checks a curated list of about two hundred selectors, likely ones first.
  • Analyse headers. Paste a raw message and dkim.fyi finds each signature, looks up its key, and, if the body is present, verifies the body hash and the signature itself.
  • Check a real email. Get a throwaway address, send any message to it, and see every signature on it as a receiver does, including selectors nobody could guess. Only the headers are read.

Verdicts

Valid
A well-formed DKIM public key is published at the DKIM name. Receivers can use it to verify mail signed with this selector.
Testing
The record is well formed but carries the t=y flag, which tells receivers the domain is still testing DKIM. Remove the flag once signing is stable.
Revoked
The record exists but its p= tag is empty. That is how a DKIM key is withdrawn: any signature made with this selector will fail verification.
Invalid
Something is published at this name, but it is malformed or its key cannot be used. Signatures that rely on it will fail.
Not found
Nothing DKIM-shaped is published at the DKIM name. That only rules out this selector: the domain may sign with others.
Lookup error
The DNS resolver could not give a definite answer, so dkim.fyi cannot say whether a record exists. Try again shortly.

How it works

dkim.fyi is a static page and a small API running on Cloudflare Workers. DNS questions are asked over DNS-over-HTTPS, primarily to Cloudflare’s 1.1.1.1 resolver, so answers are what a validating public resolver sees, including whether DNSSEC validated them. Keys are analysed with the Workers WebCrypto implementation. The lookups keep no database; the email check uses a small one, described under Privacy.

Limitations

  • DKIM selectors are not enumerable through ordinary DNS. A miss against this list does not prove DKIM is absent.
  • The authoritative selector is the s= value in a DKIM-Signature header paired with its d= signing domain.
  • Some providers generate random, tenant-specific, account-ID, timestamp, or administrator-defined selectors that cannot be represented by a finite wordlist.
  • Several selectors are historical or observed probe candidates rather than current contractual defaults. Use status, confidence, selector_mode, notes, and source_urls.
  • Check for _domainkey wildcards before treating probe hits as real selectors. Resolve both TXT and CNAME chains and detect revoked keys with an empty p= value.
  • A provider-operated-domain selector is not necessarily published on customer domains; consult customer_domain_applicability.

The surest way to find a selector is to read it from a real message: look at the s= tag in a DKIM-Signature header and paste the headers into Headers.

Privacy

There are no accounts, no sign-in and no cookies. Lookups store nothing beyond short-lived DNS caching on the edge (a few minutes at most) so repeated lookups stay fast. Messages you paste on the Headers page are parsed on request and not retained. Your browser keeps only your light/dark choice and, while you use the email check, that tab’s address.

The email check reads only the headers of the messages it receives and keeps a minimal analysis of each (signing domains, selectors, key results, the From domain and the receiver’s pass/fail results) for 24 hours, or until you delete it. It never reads or keeps the body, and never stores email addresses, subjects or raw headers. Separately, dkim.fyi keeps a private catalog of the signing domain and selector pairs it has seen; it is not linked to any address or session and is not published.

Queries are resolved through public DNS-over-HTTPS resolvers, Cloudflare’s 1.1.1.1 with Google as a fallback, so those resolvers see the names being queried. There are no third-party scripts or fonts, and no analytics.