DKIM is the one mail authentication mechanism with no standard naming convention. SPF lives at the root TXT record. DMARC lives at _dmarc.<domain>. DKIM lives at <selector>._domainkey.<domain> — and the selector can be literally anything the sender chose. When you inherit a domain and need to verify its DKIM is intact, or when a third-party sender swears they published a key but won’t tell you the selector, you can spend an afternoon guessing or you can let the PortJar DKIM Selector Probe try the obvious candidates in seconds.
What the tool does
It takes a domain and probes 24-plus common DKIM selectors against it — the defaults used by Google Workspace, Microsoft 365, Mailgun, SendGrid, Postmark, Zoho, ProtonMail, Mailchimp, Amazon SES, and other mass senders. For each, it tries <selector>._domainkey.<domain> and reports which selectors return a valid DKIM TXT record. If you know the selector you want to check (from a DKIM-Signature header you found in a message), you can probe just that one.
How to use it
Open portjar.com/tools/dkim-lookup, enter the domain, and either let it sweep the common selector list or supply a specific selector to check directly. To find the selector for a given sender, look at the s= parameter in the DKIM-Signature header of an actual message they sent — that’s the authoritative answer. The probe is for when you don’t have a sample message handy.
When you’d reach for it
- Onboarding a new client whose previous operator left no documentation. The client knows they “have DKIM set up somewhere,” but the runbook is silent and the previous admin is unreachable. A probe across the common selectors usually finds the live records in under a minute.
- Verifying that a new sending service actually published its key. When you’ve enabled DKIM in the Postmark or SendGrid dashboard and added the records via DNS API, the probe confirms the records resolve correctly before you cut over production mail.
- Investigating a DKIM check failure. The PortJar troubleshooting guide on DKIM failures lists the four common causes: missing selector, public-key mismatch, header canonicalisation drift, and message modification in transit. The probe distinguishes “missing selector” from the other three in one query — if the record genuinely isn’t there, the rest of the diagnosis simplifies.
- Auditing a domain for shadow IT. Sometimes the probe finds a selector you didn’t expect —
mandrill._domainkey.example.com,smtpapi._domainkey.example.com— pointing to a sender nobody on the current team set up. That’s a finding: someone, sometime, gave a service permission to sign as your domain, and you need to decide whether to keep it active or revoke it. - Confirming a key rotation. When you rotate DKIM keys, you typically run old and new selectors in parallel for 48 hours so in-flight mail signed with the old key still validates. The probe confirms both selectors are live during the overlap and lets you verify the old one is gone after the cutover window closes.
What to make of the output
A probe that finds nothing doesn’t necessarily mean DKIM isn’t set up — it means none of the common selectors are in use. Check the DKIM-Signature header on an actual outbound message; the s= value names the selector. Once you find it, supply it to the probe directly to confirm the record. A probe that finds multiple selectors is normal for any domain that uses more than one sender: Google Workspace, a transactional service, and a marketing tool will typically each have their own selector active simultaneously. A probe result showing a published TXT record with the key field truncated or empty (p= with no value) means the key has been revoked at the DNS level — the record still exists for backwards compatibility but no longer authenticates anything, which is a common state after a rotation that wasn’t fully cleaned up.
For environments where DKIM rotation, selector hygiene, and sender inventory need to stay current across many domains, Stack Harbor handles this discipline as part of cPanel/WHM management.