Find a DKIM selector without an email header

Why DNS cannot list selectors

A DNS query asks about one name. There is no query that returns every name under _domainkey, so a domain can publish ten keys and nothing in DNS says what they are called. Every selector finder, dkim.fyi included, is checking names from a list and reporting the ones that answer.

Check the known selectors with Discover

Discover works from a curated list of a little over two hundred selectors, each tied to the providers that use it or marked as a generic name. It reads the domain first, so the likely names go to the front of the queue.

1. Open Discover, enter the domain, leave the selector empty and press "Discover selectors".
2. Read the "What dkim.fyi saw" panel. It shows the MX hosts, whether SPF and DMARC records exist, whether the resolver validated the answers with DNSSEC, and how many candidates will be checked. Under Hints, each line names a record that matched a provider, for example "MX points to … (Microsoft 365) → trying selector1, selector2 first".
3. Watch the progress bar. Selectors are checked 40 at a time: hinted ones first, then the rest by confidence, names tied to a provider before generic ones, then alphabetically. Every candidate is checked; the scan does not stop at the first hit.
4. If a "Wildcard DNS detected under _domainkey" notice appears, a made-up selector also answered. Every name will look published, and Found hits are markedsuspect: wildcard.
5. Read the Hits table: selector, status (Found, Testing, Revoked, Invalid or Error), key type and size, and the provider the selector or its CNAME target points to. A label beside each provider says how strong that is: name only for a hint from the selector name, likely when the domain’s MX, SPF or DMARC records point at the same provider and no CNAME or record type argues against it, and CNAME target or name and CNAME when the key is handed to the provider. Methodology explains the steps. Open a hit for the full record.
6. If you know or suspect a name that is not on the list, type it into "Know a selector that is not on the list?" under the table. It is checked on the same domain and added to the hits.

Selectors no list can contain

Several providers generate the selector per account, per identity or per key. Such names cannot be guessed, so the dataset records them as patterns, and patterns are never probed. Some examples from the vendors’ own documentation:

1. Amazon SES Easy DKIM gives each identity three unique tokens and asks for three CNAMEs of the form <token>._domainkey.<domain> pointing to <token>.<SigningHostedZone>.
2. HubSpot puts a number in the host, as in its example hs1-123456._domainkey.example.com, and two CNAMEs whose targets end in dkim.hubspotemail.net.
3. Atlassian asks for two CNAMEs, DKIM Active and DKIM Fallback, named like its example atlassian-8d2d08._domainkey.test.org.
4. Postmark generates a selector that usually looks like 2023060112345pm and issues a new one when the key is rotated.

A hint does not get around this. An SPF record that includes HubSpot moves hs1, hs2 and hubspot1 to the front, and an Atlassian include moves atlassian and jira. Those are older fixed names kept from third-party lists; the vendors’ current pages show the generated form. A miss on them says nothing about the account’s real records. If you learn one of these names some other way and it answers, the custom check names the provider: HubSpot and Postmark by the shape of the selector, Amazon SES and HubSpot by where the CNAME points.

Read the selector from one message

If you can make the system send an email, you do not have to guess. The email check gives you a throwaway address and shows the signatures on whatever arrives.

1. Open Email and press "Get an address". The address accepts mail for 24 hours.
2. Send any message to it from the system you want to check: an application’s SMTP path, a marketing or support platform, a mail client. Subject and body do not matter; only the headers are read.
3. Wait for the message to appear under "Results appear here". Each signature is listed as "Signature 1 of N" with its s= and d= values, whether the header signature verified, and whether d= aligns with the From domain. If the receiver reported results, they appear as dkim=, spf= and dmarc= badges.
4. Press "Validate this selector" on a signature to open the full record check for that selector and signing domain.
5. Press "Delete now" when you are done, or let the address expire.

The signing domain is not always the domain you started with. A platform may sign with its own domain or a subdomain, which the alignment line shows. If someone can send you the raw headers of a message instead, paste them into Headers for the same reading.

A miss is not proof

When Discover ends with "No known selector found", it means none of the names on the list has a record at this domain. The domain may still sign with a generated selector, a name an administrator chose, or a key under another signing domain. Only a signed message settles it, which is why the result suggests checking a header from a real message. A hit has a limit too: a published key shows that a key exists at that name, not that current mail is signed with it.

Try it

• Scan a domain for known selectors
• Get a throwaway address
• Paste message headers

Sources

1. RFC 6376: DomainKeys Identified Mail (DKIM) Signatures
2. Managing Easy DKIM and BYODKIM
3. DkimAttributes - Amazon Simple Email Service
4. Troubleshoot domain connection
5. Troubleshoot Unverified DNS Checker for Custom Domain Email in Atlassian Cloud
6. Setting up DKIM for your Domain | Postmark Support Center
7. How often should I generate/rotate a new DKIM key? | Postmark Support Center