DKIM Selector Example: How Selectors Work and What to Publish

A DKIM selector is the small label that tells mailbox providers which public key to fetch. The selector is not the whole domain and it is not the TXT value. It is the part that usually appears before ._domainkey.

Why selectors confuse people

For DKIM selector example searches, the reader often has a provider screen open and a DNS editor open at the same time. One screen says something like s1, google, k1, or scph0324; the other asks for a host name. The mistake is pasting the wrong piece into the wrong field.

Example anatomy

selector: s1
domain: example.com
full_host: s1._domainkey.example.com
DNS host field in many providers: s1._domainkey
TXT value: v=DKIM1; k=rsa; p=PUBLICKEY...

If the DNS provider automatically appends the root domain, entering the full host can create s1._domainkey.example.com.example.com. That is why selector examples need to show both the selector and the final lookup name.

Provider examples

Google Workspace

Google commonly uses a selector such as google. The final lookup is google._domainkey.yourdomain.com. The selector identifies Google’s key, not your brand.

Email service provider

An ESP may give multiple selectors such as s1 and s2. Publish both if the provider asks for both. Rotating keys later becomes easier when each selector has a clear owner.

Sequenzy sending domain

A Sequenzy setup should display the selector, host, and TXT value separately. Operators should not have to reverse-engineer the record from one long string.

Checks before calling it done

• Query the final selector._domainkey.domain.com host.
• Confirm the TXT value starts with v=DKIM1 when expected.
• Make sure there is no duplicated root domain.
• Wait for DNS propagation before re-verifying.
• Keep old selectors until the sender has fully rotated to the new key.

Sequenzy setup

Sequenzy should treat selectors as owned keys. The UI can explain what to paste, while the verification job checks the final DNS name. Agents can help diagnose a selector mismatch, but they should never invent the public key.

Decision tables

Related guides

• email deliverability guide
• email authentication setup
• high-deliverability tools

Implementation checklist

• Confirm the exact trigger before writing copy or rules. DKIM Selector Example should map to a real event, not a vague campaign idea.
• List the data fields the message depends on and decide what happens when each field is missing.
• Add suppression rules for customers who already resolved the issue, unsubscribed from optional messaging, or should receive a different path.
• Preview the message with realistic customer data, including empty fields and edge cases.
• Track the business result, not only opens. Use replies, recoveries, completed actions, support deflection, or delivery confirmation depending on the use case.

Data to verify

Before this goes live, validate DNS, authentication, and mailbox-provider checks. The best version of this page should help an operator decide whether the message is safe to send, not just whether the copy sounds polished.

When the source data is uncertain, the safer choice is usually a softer message, a manual review task, or no send at all. That rule matters because automated email becomes risky when stale attributes, expired links, or resolved customer states continue to trigger messages.

Common mistakes

• Treating the page as generic copy instead of a workflow with inputs, checks, and exit conditions.
• Using one template for every recipient state even when the customer context changes the right next step.
• Hiding operational details such as links, identifiers, delivery state, or billing status behind vague language.
• Sending follow-ups after the customer already completed the action.
• Measuring success with open rate alone instead of the outcome the email exists to produce.