How to find your DKIM selector

Method 1: read it from a message you actually sent

This is the authoritative method, and it takes about a minute. Send a message from the platform in question to any mailbox you control, open the raw source, and find the DKIM-Signature header. The s= tag in it is the selector, and the d= tag is the domain the key is published under.

It is authoritative because it is not a guess about configuration — it is what the signing system actually did on a real message. If a platform signs with different selectors for different message types, which some do, this is the only method that will show you that.

To get the raw source: in Gmail, open the message's three-dot menu and choose "Show original". In Outlook on the web, open the message menu and choose "View" then "View message source". In Apple Mail, View then Message then Raw Source. Every serious client has an equivalent.

If the message is signed more than once — common when a platform signs and then a gateway signs again — you will see several DKIM-Signature headers. Each has its own s= and d=, and each is verified independently.

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=selector1;
    h=from:subject:date:to:mime-version;
    bh=2jmj7l5rSw0yVb/vlWAYkK/YBwk=;
    b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSb...

; d= is the signing domain, s= is the selector
; the key is published at  selector1._domainkey.example.com

Method 2: look in the sending platform's own settings

Every platform that signs mail shows you the DNS records it wants published, and the selector is in the name of each of those records. This is where to look when you have not yet sent any mail — during setup, or when verifying that DNS matches what the platform expects.

The place is usually called something like "domain authentication", "sender authentication", "verified domains" or simply DKIM, under the account or domain settings. What you are looking for is a record whose name contains _domainkey; everything to the left of that label is the selector.

This method has one failure mode worth knowing: platforms sometimes show you the record they wanted rather than the record you published. If the two have drifted — you published it, then someone edited the zone — the settings page can still show a green tick from a check run months ago. Confirm against DNS rather than against the page.

Method 3: test the known defaults

If you have no message and no access to the platform, testing likely selector names is the remaining option. It is a guess, and it should be treated as one: finding nothing proves nothing.

Our DKIM checker does this automatically against a list of documented platform defaults, and it reports the distinction honestly — it tells you it probed a set of known selectors and found none, which is not the same claim as "this domain does not sign mail". Any tool that collapses those two into a red cross is telling you something it does not know.

You can do the same by hand with dig. A published selector returns a TXT record beginning v=DKIM1; an unpublished one returns nothing at all.

for s in google selector1 selector2 s1 s2 k1 mail dkim; do
  out=$(dig +short "$s._domainkey.example.com" TXT CNAME)
  [ -n "$out" ] && printf '%-10s %s\n' "$s" "$out"
done

Selectors by platform

The table below records what each vendor documents as of 2026-09-13. Treat it as a dated snapshot: selectors are a vendor implementation detail and they do change, which is precisely why methods 1 and 2 are ranked above this one.

• Google Workspace — selector google by default, published as a TXT record at google._domainkey. The prefix is configurable in the admin console, so a domain that changed it will not answer at the default.

• Microsoft 365 — selector1 and selector2, both published as CNAMEs rather than TXT records, pointing into Microsoft's infrastructure so they can rotate the underlying key without you editing DNS. Two selectors exist so that rotation can alternate between them. Note that Microsoft changed the CNAME target format in May 2025: domains onboarded since then point at a …-v1.dkim.mail.microsoft target, while older domains keep the previous onmicrosoft.com form, and Microsoft states the two formats cannot coexist for one selector.

• Amazon SES, Easy DKIM — three CNAME records whose names are generated tokens rather than a fixed selector, each pointing at a target under dkim.<region>.amazonses.com. There is no memorable selector to guess; you must read these from the SES console or from a signed message.

• SendGrid — s1 and s2 as CNAMEs when automated security is enabled, or a single m1 TXT record when it is not.

• Mailgun — pdk1 and pdk2 as CNAMEs under automatic sender security. A manually configured domain uses a selector you chose, with no documented default.

• Postmark — a date-stamped TXT selector, in the form of a timestamp followed by pm, such as 20230601...pm. It is not guessable and must be read from the account or a message.

• Klaviyo — CNAMEs with a prefix that encodes the stream: km1 and km2 for marketing, kt1 and kt2 for transactional, ks1 and ks2 for service, and kl1 and kl2 on older accounts. The numbering extends for additional sending domains, so treat it as a pattern rather than a fixed list.

• Zoho — zoho as a TXT record in Zoho's own documented example, though the selector is chosen by the administrator at setup.

• Brevo — mail as a TXT record.

• Mailchimp's transactional product uses mte1 and mte2 as CNAMEs. Its marketing product's selectors are shown only inside the logged-in interface and are not published in its documentation, so we do not list a value we cannot source.

What a selector lookup tells you once you have found it

Finding the selector is the beginning. Fetch the record and there are three things worth reading in it.

The p= tag holds the public key. An empty p= is not a broken record — it is the standard way to revoke a key while keeping the selector in place, and it makes every signature under that selector fail deliberately. If you find one unexpectedly, someone revoked it, and that is a question for whoever did.

Key length is derivable from the key itself. RFC 8301 requires verifiers to treat keys below 1024 bits as invalid outright, so anything shorter is not weak, it is non-functional. 1024 bits is the floor and 2048 is the current recommendation; our checker warns at 1024 rather than failing it, because mail signed with a 1024-bit key does still verify.

A t=y tag means the domain is in testing mode, and asks receivers not to treat a failed signature as meaningful. It is meant to be removed after setup, and one left behind by a setup wizard quietly weakens DKIM for as long as it is there.

What commonly goes wrong

• Concluding a domain has no DKIM because the default selectors did not answer. Unless you have read a message or the platform's settings, you have not checked.

• Publishing a TXT record where the platform asked for a CNAME. Microsoft 365, SES, SendGrid's automated mode and Klaviyo all use CNAMEs so they can rotate keys on their side; replacing the CNAME with a copy of the key it currently resolves to works until they rotate, and then silently stops.

• Pasting a 2048-bit key into a DNS panel and losing part of it. A single DNS TXT string cannot exceed 255 characters, so a 2048-bit key must be split into several quoted strings within one record; a panel that truncates instead of splitting produces a record that looks present and fails verification.

• Looking for a selector under the wrong domain. The key is published under the d= domain from the signature, which for a bulk sender on a subdomain is not necessarily the domain in the From address.

• Removing an old selector immediately after switching platforms. Mail already in a sending queue can be delivered days later and will still be signed with the old key; leave the old record published until the retry window has passed.