DKIM Selectors Cheat Sheet for Google, Microsoft, Mailgun, SendGrid, and More

This DKIM selectors cheat sheet helps agencies understand where to look when auditing DKIM records for client domains. A DKIM selector is the label that points receivers to the public key used to verify a signed message. It usually appears in DNS as a TXT or CNAME record under a name like selector._domainkey.example.com.

The short version: selectors are not universal. Google, Microsoft, Mailgun, SendGrid, and other email service providers use common patterns, but the exact selector can vary by account, domain, region, setup date, or custom configuration. Treat selector examples as starting points, not proof.

CertPilot's Inbox Pulse is a bulk email-authentication audit tool for agencies. It helps review DMARC, SPF, DKIM-related configuration risk, MTA-STS, TLS-RPT, and BIMI across multiple client domains. It does not replace a platform that continuously monitors DMARC RUA reports.

For broader SSL, DNS, and domain expiry context, run a free 10-domain agency audit. You can also browse all free agency tools at /tools.

DKIM selectors cheat sheet: practical examples

Use this table as a practical starting point. Always verify against the sending platform's admin panel and the actual email headers from a test message.

| Provider or system | Common selector examples | Notes for agencies | |---|---|---| | Google Workspace | google | Many domains use google._domainkey, but setup can vary. | | Microsoft 365 | selector1, selector2 | Often CNAME records pointing to Microsoft-controlled hosts. | | Mailgun | smtp, k1, custom values | Depends on account and domain setup. | | SendGrid | s1, s2 | Usually CNAME-based after domain authentication. | | Amazon SES | provider-generated selectors | SES usually gives multiple generated CNAME records. | | Postmark | provider-generated selector | Verify in the sender signature or domain settings. | | Klaviyo | kl, generated values | Varies by account and branded sending setup. | | HubSpot | generated values | Often multiple CNAME records. | | Salesforce Marketing Cloud | custom or generated selectors | Enterprise setups often vary widely. | | Website plugins | custom, provider, or none | Many plugin emails rely on the site or SMTP provider. |

This is not a complete vendor directory. The point is to help an agency know where to begin when a client says, "DKIM should already be configured."

What a DKIM selector does

DKIM signs an email message with a private key controlled by the sender. The receiving mail server uses the selector in the message header to find the matching public key in DNS.

A DKIM-Signature header may include a tag like:

s=selector1; d=example.com

That means the receiver should look up:

selector1._domainkey.example.com

If the public key record exists and the signature validates, DKIM can pass for that domain.

For agencies, the key detail is that you often cannot know the correct selector from DNS alone. You need the sending platform's setup screen or a real message header.

Why selectors are hard for agencies

DKIM selectors are difficult in agency work because clients rarely have a single sender.

A client may use:

• Google Workspace or Microsoft 365 for employee mail.
• Mailgun or SendGrid for transactional mail.
• Klaviyo or Mailchimp for marketing.
• HubSpot or Salesforce for CRM.
• Shopify, WooCommerce, or another ecommerce platform.
• A WordPress SMTP plugin.
• A helpdesk or booking platform.

Each sender may require its own DKIM setup. Some use TXT records. Some use CNAME records. Some rotate keys. Some show pending verification even when DNS looks correct because of propagation, wrong domain scope, or copied values.

The agency problem is not "what is DKIM?" The agency problem is inventory: which systems send mail for this client, which domain do they send from, and which selector does each system expect?

How to audit DKIM without guessing blindly

Use this workflow before changing DNS.

1. List actual senders

Ask the client where email comes from:

• staff inboxes
• newsletters
• invoices
• receipts
• password resets
• lead forms
• support replies
• CRM sequences

This matters because DKIM is configured per sending system, not magically for every service that uses the domain.

2. Open each sender's domain-authentication screen

Most providers show required DNS records. Copy from the provider, not from a random article. If the provider gives CNAME records, use those exact names and values.

3. Send a test message

Send a message from the actual service. Inspect the message headers in a receiving mailbox and find:

• DKIM-Signature
• d=
• s=
• authentication results

The selector in the header is the selector that matters for that message.

4. Check DNS

Look up selector._domainkey.domain. Confirm the expected TXT or CNAME exists.

5. Check DMARC alignment

DKIM passing is not always enough for DMARC. The DKIM signing domain must align with the visible From domain, depending on DMARC alignment mode.

Use Inbox Pulse for a bulk configuration view, then verify real mail flows for domains that matter.

6. Record the evidence

Keep a short note for each sender. Include the sender name, domain, selector, DNS record type, verification date, and the account owner who can change it. This avoids repeated discovery work when the client changes agencies, platforms, or internal contacts.

For example:

| Sender | Domain | Selector | Evidence | |---|---|---|---| | Google Workspace | client.com | google | Test mailbox header passed DKIM. | | SendGrid | mail.client.com | s1, s2 | Sender dashboard verified CNAMEs. | | Klaviyo | news.client.com | account-specific | Awaiting client admin access. |

This small documentation habit is often more valuable than another DNS lookup. It gives the agency a durable handoff record and a clean place to note unresolved senders.

Common selector mistakes

Agencies often find these issues during inherited client audits:

| Mistake | What it looks like | Why it matters | |---|---|---| | Wrong selector copied | DNS has google, but sender uses selector1 | DKIM fails for that sender. | | Wrong domain level | Record added to www zone or wrong DNS provider | Receiver cannot find the key. | | Old vendor remains | DKIM exists for retired platform | Creates confusion during audits. | | DKIM present but not aligned | Vendor signs with its own domain | May not help DMARC. | | CNAME flattened incorrectly | Provider expected a CNAME | Verification may fail. | | Multiple senders undocumented | Nobody knows which selector belongs to which service | Troubleshooting slows down. |

The fix is usually documentation and verification, not clever DNS tricks.

Google Workspace selectors

Many Google Workspace domains use the selector google, which creates a DNS name like:

google._domainkey.example.com

However, agencies should still verify in the Google Admin console. Existing domains, migrated domains, or unusual setups can differ. A record existing in DNS does not prove it is active for every message.

When auditing Google Workspace:

• Confirm DKIM is enabled in the admin console.
• Confirm the domain is the client's sending domain.
• Send a test message from a user mailbox.
• Inspect the DKIM result and selector.

Microsoft 365 selectors

Microsoft 365 commonly uses selectors such as selector1 and selector2, often with CNAME records.

The DNS names commonly look like:

selector1._domainkey.example.com
selector2._domainkey.example.com

Do not assume TXT records are required. Microsoft setups often use CNAME targets generated for the tenant. The exact target value depends on the tenant and domain.

For agency work, verify inside the Microsoft 365 admin experience and then test real messages.

SendGrid, Mailgun, and transactional senders

Transactional senders often provide generated DNS records during domain authentication. Some use friendly selectors such as s1, s2, or smtp. Others generate account-specific values.

For these services, the safest rule is: copy the records from the sender dashboard and document which application uses them.

If a client has multiple products or subaccounts, selectors can differ between environments. Production, staging, and legacy apps may not share the same setup.

DKIM, DMARC, and agency reporting

DKIM is only one part of email authentication. A client can have DKIM configured for Google Workspace and still have DMARC problems if a marketing platform sends without aligned DKIM. Another client can pass SPF for a vendor but fail DMARC because the visible From domain does not align.

When reporting to a client, avoid saying "DKIM is fixed" unless you know which sender you verified.

Better wording:

• "Google Workspace DKIM is configured and passing for tested mailbox mail."
• "Marketing sender DKIM still needs verification."
• "DMARC alignment should be checked after sender records are updated."
• "This audit found configuration risk, not a guarantee of inbox placement."

That wording is accurate and keeps the scope clear.

When to revisit DKIM selectors

DKIM should not be treated as a one-time launch task. Agencies should revisit selectors when a client changes any part of the sending stack.

Good review moments include:

• onboarding a newly inherited client
• moving from one email platform to another
• changing the primary domain or From address
• launching a new marketing automation tool
• adding ecommerce or transactional email
• rotating DKIM keys inside a provider
• moving DNS to a new provider

The last item is easy to miss. DNS migrations can copy visible website records while missing obscure _domainkey records. A post-migration email-authentication check can catch that before a client notices campaign or invoice problems.

Where Inbox Pulse fits

Inbox Pulse helps with the first-pass agency audit. It can show which client domains need attention across email-authentication signals. It is especially useful before onboarding, before a campaign, or when a client reports mail problems.

For deeper sender-specific DKIM work, combine it with:

• provider admin screens
• DNS lookups
• real test messages
• email header review
• client sender inventory

For broader web operations, run Audit 10 Domains, review DNS drift guidance, and use Watchtower or 47-Day Renewal Pre-Flight where SSL renewal risk matters.

Related resources

• Inbox Pulse email authentication checker
• DMARC, SPF, and DKIM explained for agencies
• Google bulk sender DMARC agency checklist
• How CertPilot checks domains

Frequently Asked Questions

What is a DKIM selector?

A DKIM selector is the DNS label used to find the public key for a DKIM signature. It appears in the email header as s= and is looked up under _domainkey.

Are DKIM selectors the same for every Google or Microsoft account?

No. Some common patterns exist, but selectors and CNAME targets can vary. Always verify in the provider's admin panel and with a real test message.

Can a domain have more than one DKIM selector?

Yes. A domain can have multiple selectors for different senders, key rotations, or platforms.

Does DKIM guarantee inbox placement?

No. DKIM helps authenticate mail, but inbox placement depends on many factors. Do not treat DKIM as a deliverability guarantee.

How should agencies audit DKIM across clients?

Start with Inbox Pulse for a bulk configuration view, then verify each important sender with DNS records and real message headers. Use Audit 10 Domains for broader domain health.