How to Find Your DKIM Selector and Check the Record

To look up a domain's DKIM record you need two things: the domain and the selector. The selector is a label the sending service picks, and the public key is published under it at selector._domainkey.example.com. DNS has no way to list every selector a domain uses, so you have to find the right one first.

How to find your DKIM selector in an email header

The most reliable source is a message you have actually sent. Open it in the recipient's mailbox and view the original or raw message: "Show original" in Gmail, "View message source" in Outlook. Find the DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=google;
        h=from:to:subject:date; bh=…; b=…

• s= is the selector, google here.
• d= is the signing domain. For DMARC to pass on DKIM, it must match the domain in the From address (or share its organizational domain).

A message can carry several signatures, for example one from your domain and one from the sending platform's own domain. The one that matters for DMARC is the one whose d= is your domain.

The Authentication-Results header in the same message shows whether each signature verified: look for dkim=pass header.d=example.com header.s=google.

Default DKIM selectors for Google Workspace, Microsoft 365 and others

If you don't have a message to hand, the provider's default is a good guess:

Providers can change their defaults, and many let you choose a custom selector, so confirm with a real header when it matters.

How to check a DKIM record

With the selector known, look up the TXT record:

dig TXT google._domainkey.example.com +short

Many services publish a CNAME at that name pointing to a record they host, so they can rotate keys for you. dig follows it automatically. A working record looks like:

"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA…"

The SPF, DKIM and DMARC checker does this for you. Enter one or more selectors, or leave the field empty to try the common ones, and it reports whether each key exists, parses correctly and is long enough.

Problems you may find

• No record at the selector. The selector is wrong, the record was never published, or it sits under the wrong name. Some DNS panels add your domain automatically, so entering google._domainkey.example.com as the name creates google._domainkey.example.com.example.com. Enter just google._domainkey.
• An empty key (p=). The key has been deliberately revoked. Mail signed with it will fail.
• A broken key. A key pasted with stray spaces, quotes or line breaks won't parse. Long keys are split into several quoted strings in one TXT record, which is correct. Splitting them into separate TXT records is not.
• A short key. Use 2048-bit RSA keys. 1024-bit keys still verify at most receivers but are considered weak.

A valid record doesn't prove mail is signed

The DNS record only publishes the key. Whether messages are actually signed with it is set in the sending service. In Google Workspace and Microsoft 365, for example, you must also switch DKIM signing on after publishing the record. Confirm with a real message's Authentication-Results header, or your DMARC aggregate reports. For how DKIM fits with SPF and DMARC, see SPF, DKIM and DMARC explained.