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

Jordan’s DKIM audit starts with a familiar sentence: “DKIM is already set up.” The client believes Google handles employee mail, marketing believes SendGrid is configured, ecommerce uses its own sender, and a WordPress plugin sends form notifications through a mailbox nobody has documented.

A DKIM selectors cheat sheet helps the team know where to begin, but it should not become guesswork. 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.

Selectors are not universal. Google, Microsoft, Mailgun, SendGrid, Amazon SES, Postmark, Klaviyo, HubSpot, Salesforce, and other senders use common patterns, generated values, or custom setup. The only reliable answer is the sender’s admin screen plus a real test message header.

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

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 selector list as a practical starting point. Always verify against the sending platform's admin panel and the actual email headers from a test message.

Use this structured view:

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

Use this structured view:

• Sender: Google Workspace; Domain: client.com; Selector: google; Evidence: Test mailbox header passed DKIM.
• Sender: SendGrid; Domain: mail.client.com; Selector: s1, s2; Evidence: Sender dashboard verified CNAMEs.
• Sender: Klaviyo; Domain: news.client.com; Selector: account-specific; Evidence: 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:

Use this structured view:

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

Build the DKIM sender evidence record

A DKIM check is only useful when tied to a real sender. Do not document “DKIM present” as if the domain has one universal DKIM state.

For each sending source, capture:

• Sender name: Google Workspace, Microsoft 365, SendGrid, Mailgun, ecommerce platform, CRM, helpdesk, form plugin, or custom app.
• Visible From domain: the domain users see in the message.
• Envelope or bounce domain, if known: useful for SPF and DMARC context.
• Selector: the s= value from the real DKIM-Signature header or sender dashboard.
• Signing domain: the d= value from the header.
• DNS record name: selector._domainkey.domain or provider CNAME name.
• Record type: TXT or CNAME.
• Evidence source: sender dashboard, DNS lookup, or real message header.
• Alignment note: whether the DKIM signing domain appears aligned for DMARC purposes.
• Owner: who can change the sender setup.
• Last reviewed: date and reviewer.

This is the difference between a cheat sheet and an operating record. The cheat sheet helps Jordan find likely selectors. The evidence record proves which selectors matter for this client.

Selectors are evidence, not sender inventory

Finding a DKIM record in DNS does not tell you every system that sends mail. A client can have correct Google DKIM and still fail DMARC for marketing mail, invoices, password resets, or helpdesk replies.

Use selector checks together with a sending-source inventory:

• employee mailbox platform;
• marketing automation;
• transactional email provider;
• ecommerce platform;
• CRM or sales engagement tool;
• helpdesk or ticketing system;
• website forms and SMTP plugins;
• billing and invoicing tools;
• legacy systems still sending from the domain.

If a system sends mail from the domain, it needs an owner and evidence. If no one can identify the sender, DKIM troubleshooting becomes guesswork.

Review DKIM during DNS and platform changes

DKIM records are easy to lose during DNS migrations because they live under _domainkey and are often provider-generated. They are also easy to leave behind when a platform is retired.

Review selectors when:

• DNS moves to a new provider.
• Google Workspace or Microsoft 365 is activated.
• A marketing platform changes sending domain.
• A transactional email provider rotates keys.
• A client launches a new ecommerce, CRM, helpdesk, or form tool.
• An agency inherits a domain from another provider.
• A DMARC policy is moving from monitoring toward enforcement.

The goal is not to keep every historical selector forever. The goal is to know which selectors support active senders and which records are legacy clutter.

Client-safe wording for DKIM findings

Use precise language in reports:

• “Google Workspace DKIM passed for the tested mailbox message.”
• “SendGrid DKIM is configured in DNS, but a live test message is still needed.”
• “A DKIM record exists for a retired sender; confirm whether it can be removed.”
• “The sender signs with a provider domain, so DMARC alignment should be reviewed.”
• “DKIM evidence is incomplete because the sending-source inventory is incomplete.”

Avoid writing “DKIM is fixed” unless you know which sender, domain, selector, and alignment condition you verified.

How CertPilot helps

CertPilot helps teams see public email-authentication signals across monitored domains and keep sending-source notes close to the domain record. That supports a cleaner review of SPF, DKIM, DMARC, MTA-STS, TLS-RPT, BIMI, and DNS evidence before a management or client report.

CertPilot does not read mailboxes, inspect message headers automatically, configure sender dashboards, rotate DKIM keys, send email on the customer’s behalf, or guarantee deliverability. It gives operators a practical evidence layer and a place to track what still needs manual verification.

For broader context, connect DKIM selector work to the email authentication agency guide, the MTA-STS record check, and the Domain Health reporting workflow.

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.