DKIM Selector: Setup, Lookup, and Troubleshooting

You usually notice a dkim selector only when mail starts failing authentication, Gmail starts pushing messages into spam, or a vendor asks you to publish a weird-looking TXT record like tm1._domainkey.example.com. That’s the problem. The selector looks minor, but if it’s wrong, DKIM breaks. When DKIM breaks, DMARC often breaks with it. And when that happens, deliverability drops fast.

It gets worse when you run multiple senders on one domain. Your main mailbox host signs with one key. Your marketing tool signs with another. Your CRM signs with a third. If you don’t understand the dkim selector, you can’t tell which system owns which signature, which DNS record to rotate, or why one mail flow passes while another fails. If you need the broader setup context, start with business email.

Here’s the fix: treat the dkim selector as a routing label for DKIM keys. Once you know how the selector maps to DNS, setup and debugging become mechanical instead of mysterious.

What is a DKIM selector?

A dkim selector is the label in a DKIM signature that tells the receiving server which public key to fetch from DNS. It lets one domain publish multiple DKIM keys at the same time for different systems, different streams, or key rotation.

A dkim selector is not the key itself. It is the lookup hint. In the DKIM-Signature header, the selector appears in the s= tag. The signing domain appears in the d= tag. The receiver combines them into a DNS query like selector._domainkey.example.com and retrieves the public key from that TXT record.

RFC 6376 defines this directly: the verifier uses the domain from d= and the selector from s= to find the public key record. That’s the whole mechanism. No selector, no key lookup. Wrong selector, wrong key lookup. Either way, DKIM fails.

If a message has d=example.com and s=tm1, the receiver looks up tm1._domainkey.example.com.

What does a dkim selector actually do?

A dkim selector tells receivers which DKIM public key to use for one specific message. It exists so you can run more than one key under the same domain without collisions.

That matters for three operational reasons.

1. It separates senders. Your help desk platform can use one dkim selector while your transactional app uses another.
2. It enables key rotation. You can publish a new dkim selector, switch signing to it, then retire the old one after mail in flight clears.
3. It reduces blast radius. If one vendor key is compromised or revoked, you don’t have to touch every other sender on the domain.

This is why serious mail setups rarely use a single forever-key. They use multiple DKIM records, each with its own dkim selector, and they manage them like any other credential.

Where do you find the dkim selector?

You find the dkim selector in the message headers or in your sending provider’s DNS instructions. In live mail, it appears in the DKIM-Signature header as the s= value.

Open the raw headers of a delivered message and search for DKIM-Signature:. You’re looking for two tags:

• d= shows the signing domain.
• s= shows the dkim selector.

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

In this case, the dkim selector is tm1. The DNS record you need to inspect is:

tm1._domainkey.example.com TXT

If you’re setting up a new sender, the provider usually gives you the selector name and either the TXT value or a CNAME target. TrekMail shows the required DNS records in the domain workflow and verifies them live in the dashboard. The docs for required DNS records and checking DNS status are the fastest path if you need exact field placement.

How do you publish a dkim selector in DNS?

You publish a dkim selector by creating a DNS record at selector._domainkey.yourdomain.com. The value is usually a DKIM TXT record or, with some providers, a CNAME that points at the provider’s managed key.

The two common patterns look like this.

TXT-based DKIM:

Host: tm1._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ...

CNAME-based DKIM:

Host: tm1._domainkey
Type: CNAME
Value: tm1.example-com.dkim.vendor.net.

Do not invent the selector name. Use the exact one your sender gives you. If the vendor says s1, publish s1._domainkey. If TrekMail shows dkim._domainkey for your domain in the dashboard, use that exact host and value. The live setup flow in Custom SMTP (BYO) is useful here if you run your own outbound provider on the Nano plan.

How do you test whether a dkim selector works?

You test a dkim selector by checking that the DNS record resolves and then verifying that real messages are signed with the same selector and pass DKIM.

Start with DNS. Query the record directly:

dig +short TXT tm1._domainkey.example.com
nslookup -type=TXT tm1._domainkey.example.com

If DNS returns nothing, the record is missing, still propagating, or published at the wrong host.

Then send a real message and inspect the headers:

Authentication-Results: mx.google.com;
 dkim=pass header.i=@example.com header.s=tm1 header.b=...
 spf=pass smtp.mailfrom=example.com;
 dmarc=pass header.from=example.com

This is what you want:

• dkim=pass
• header.s=tm1 matches the published dkim selector
• header.i or d= aligns with your From domain for DMARC purposes

If you forward mail a lot, read email forwarding too. SPF breaks on forwarded mail all the time. DKIM is what usually saves delivery.

Why does a dkim selector fail?

A dkim selector usually fails because the DNS host is wrong, the key value is malformed, the sender is signing with a different selector than the one you published, or a relay modified the message after signing.

These are the failures I see most often in production.

1. Wrong DNS host. You published _domainkey.tm1 instead of tm1._domainkey.
2. Wrong domain. The mail signs with d=mg.example.com, but you published the dkim selector under example.com.
3. Split DNS mistakes. The record exists on one nameserver set, not the authoritative one.
4. Truncated key. The TXT value was cut off by a bad DNS UI copy-paste.
5. Old selector still in use. You rotated keys, but the sender still signs with the previous dkim selector.
6. Message mutation after signing. Forwarders or gateways changed protected headers or body content.

Google’s current sender guidance is blunt: bulk mail that fails DKIM can be rate limited or blocked. Google also notes that forwarding often breaks SPF, which is why maintaining a working dkim selector matters so much for real-world delivery.

How should you name a dkim selector?

A dkim selector should be simple, stable, and tied to an operational purpose. Good names make incident response faster because you can tell who owns the key without digging through three vendor panels.

Bad selector names look random forever: default, key1, test. They work, but they age badly. Better patterns:

• tm1 for TrekMail managed sending
• ses2026q1 for Amazon SES rotation
• crm1 for a CRM platform
• mktg2026a for marketing traffic

Use names that answer two questions at a glance: who owns this key, and when was it introduced? That makes audits easier when you operate many domains, especially in a multi domain email hosting setup.

How do you rotate a dkim selector safely?

You rotate a dkim selector by publishing a new key under a new selector, switching signing to the new selector, waiting for old mail to clear, and only then removing the old record.

Do not overwrite an active key in place unless your provider explicitly requires it. Safer process:

1. Create a new dkim selector, such as moving from tm1 to tm2.
2. Publish the new DNS record.
3. Wait for DNS to propagate.
4. Switch the sender to sign with the new dkim selector.
5. Send test mail and confirm dkim=pass on the new selector.
6. Keep the old record live for a buffer period.
7. Remove the old record only after you are sure nothing still signs with it.

This matters more when you use several outbound systems. The old way is sharing one long-lived key across everything and hoping nobody forgets where it is. The new way is assigning each sender its own dkim selector, rotating on schedule, and keeping changes isolated.

How does TrekMail handle the dkim selector?

TrekMail exposes the DNS records you need, checks them live, and supports both managed sending on paid plans and BYO SMTP on the Nano plan. That cuts the usual guesswork around selector placement and DNS health.

For inbound hosting and mailbox management, TrekMail gives you one dashboard for domains, pooled storage, invite-based provisioning, mailbox forwarding, and built-in IMAP migration. For outbound mail, you choose the operating model:

• Paid plans can use TrekMail Managed SMTP, which signs mail with your domain’s DKIM key.
• The Nano plan uses BYO SMTP, so your outbound provider controls the active dkim selector and signing behavior.

That distinction matters. If your outbound provider signs mail, the active dkim selector usually comes from that provider’s DNS instructions. If TrekMail Managed SMTP signs mail, the dashboard-generated DKIM record is the one that matters. Starter begins at $3.50 per month, paid plans have a 14-day free trial with a credit card, and the Nano plan stays free with no trial. If you want the flat-rate model instead of per-user pricing, see TrekMail pricing.

DKIM selector troubleshooting checklist

If a dkim selector is failing, follow a fixed checklist: confirm the selector in the message header, confirm the DNS record at the exact host, confirm the sender is using that selector, and confirm nothing in transit is breaking the signed content.

1. Inspect a real delivered message and note s= and d=.
2. Query selector._domainkey.domain directly in DNS.
3. Check the authoritative nameservers, not just your registrar UI.
4. Verify whether the provider expects TXT or CNAME.
5. Compare the From domain with the signing domain for DMARC alignment.
6. Retest after forwarding, gateways, or list software if mail changes in transit.

If mail sent directly passes but forwarded mail fails, the issue may not be the dkim selector itself. It may be the forwarder breaking the signature. Google’s forwarding guidance is explicit about that, and it matches what operators see in the field. If forwarding is part of your stack, also read forward domain email to Gmail.

Final answer: what should you remember about a dkim selector?

A dkim selector is the label that tells receivers which DKIM public key to fetch from DNS. If you remember that one sentence, most DKIM troubleshooting gets easier.

When you publish the right dkim selector at the right DNS host, and your sender signs with that same selector, DKIM works. When it doesn’t, check the message header first, DNS second, and mail-path mutations third. Keep selectors separate by sender. Rotate with new names, not risky in-place edits. And if you want a simpler operating model for multi-domain email, TrekMail gives you the hosting layer, DNS checks, migration tooling, and flat-rate pricing without per-user fees.