Guide
Check DKIM for a domain you do not control
You may need to look at someone else’s DKIM setup: a vendor you are assessing, a customer whose mail is failing at your gateway, or a domain in an incident. DKIM keys live in public DNS, so you can check them without access to the domain. What you can conclude is narrower than it first looks.
What public DNS can and cannot tell you
From DNS alone you can learn whether a key is published at a given selector, what its tags say, the key type and size, whether the name is a CNAME to a provider, and whether the key is revoked or flagged for testing. Discover adds the domain’s MX hosts and whether it publishes SPF and DMARC records.
You cannot learn which selectors the domain signs with today, whether its mail is signed at all, or whether a key you found is the one in use. Selectors cannot be listed (see Find a DKIM selector without an email header), so a scan finds only names on a list. Records that exist only on internal name servers are not visible from outside, and dkim.fyi sees what a public resolver sees. A single-record check may serve an answer up to five minutes old from its cache.
Run the checks
- Enter the domain in Discover. Read "What dkim.fyi saw" for the MX hosts, SPF, DMARC and the hints that decided which selectors went first.
- Note any wildcard warning before reading the hits.
- Open each hit. The result page shows a verdict, then five panels: Findings, Record, Key, DNS and Provider attribution.
- If you already know a selector, for example from a bounce or a vendor’s setup page, go straight to Validate with the domain and selector filled in.
Read the verdict
- Valid: a DKIM record is there, the key parses and no finding is an error.
- Testing: valid, but the record carries
t=y, which tells receivers not to treat failures differently from unsigned mail. Until the flag is removed, a failing signature counts for nothing. - Revoked: the record exists with an empty
p=. That is how a key is withdrawn, and any signature made with that selector fails. A revoked selector tells you the domain once signed with it, not what it signs with now. - Invalid: something is published, but it is malformed or the key cannot be used. Findings say what.
- Not found: nothing DKIM-shaped at that name. It rules out this selector only.
- Lookup error: the resolver gave no definite answer, so dkim.fyi cannot say whether a record exists. Try again before drawing a conclusion.
Wildcards, CNAME chains and provider attribution
Alongside the selector, dkim.fyi queries a random, made-up selector under the same _domainkey. If that answers, the domain has a wildcard and every selector appears to exist. The result then says "Wildcard DNS detected under _domainkey", and Discover marks Found hits suspect: wildcard. Treat them as unproven.
When the selector name is a CNAME, the DNS panel draws the chain from the queried name to the terminal target, with each hop’s TTL. That is normal when a provider hosts and rotates the key. Provider attribution reads the target’s suffix, so a CNAME into a provider’s zone names that provider even when the selector is custom; the evidence line says what matched, such as the selector name, the CNAME target or both. If the target does not exist, the findings say the CNAME is dangling: the provider has not published the key, or the value was mistyped.
Each provider in the attribution panel carries a confidence that follows what its evidence can show. From weakest to strongest:
- Selector name alone: a hint. Names such as s1, k1, selector1 and default are shared or generic. The name says who might use it, not who owns this key. The attribution shows it as “selector name only: a hint”, at medium confidence at most.
- Name plus the domain’s MX, SPF or DMARC records pointing at the same provider: likely. It shows the domain uses that provider, not that this key is theirs, because mixed setups are common, such as Google for mail and SendGrid for marketing. For providers that publish a TXT key on the customer’s own domain (Google Workspace, Zoho and many mailbox hosts) this is the most DNS can show. Discover marks such hits “likely”.
- CNAME target in the provider’s zone: strong. The domain handed its key to that provider. Name plus CNAME is the top rung, shown as “selector name and CNAME target” at high confidence.
- A real signed message, read from the
s=andd=tags: it proves the selector signs live mail for that domain. It names the provider only if the key is also a CNAME to one.
Some evidence counts against a name. A provider that only publishes CNAMEs, such as Microsoft 365, is not supported by a TXT record reached with no CNAME. A CNAME that points into another provider’s zone outranks the name. In both cases the name-only match drops to low confidence, as it does when the name is generic or several companies list it.
Key strength
The Key panel shows type, size, a strength rating, whether the key imports cleanly and its SHA-256 fingerprint. For RSA, dkim.fyi follows RFC 8301:
- 2048 bits or more is rated strong.
- 1024 to 2047 bits still works, but gets a warning: it is considered weak and may be rejected by strict receivers.
- Under 1024 bits is an error, because RFC 8301 forbids verifiers from accepting such keys.
- Over 4096 bits gets a warning, because verifiers are only required to support up to 4096. Keys over 8192 bits are not imported at all.
- A record that restricts the key to SHA-1 (
h=sha1) is an error.
An Ed25519 key (RFC 8463) is reported as valid, with a note that not every receiver verifies Ed25519 yet.
DNSSEC
The DNS panel shows "validated (AD)" when the resolver reports the answer as DNSSEC-validated. dkim.fyi does not validate DNSSEC itself. A "not validated" answer is what an unsigned zone looks like, so it is not a fault on its own.
When to ask the domain owner for a header
Ask for the headers of one recent message from the system in question when the scan finds nothing, when the hits sit under a wildcard, when the only hits are revoked, or when you need to know which key signs current mail. The DKIM-Signature header names the selector and signing domain outright. Paste the headers into Headers: it looks up each key and, if the body is included, verifies the body hash and signature. Pasted messages are parsed on request and not kept. If the owner would rather send a test message, get an address from the email check and ask them to send one message to it. Only the headers are read.