Key Takeaways
- A DKIM selector is the s= value in the DKIM-Signature header that tells receiving mail servers where to find the corresponding public key in DNS.
- DKIM selectors make it possible to run multiple signing keys simultaneously across different ESPs like Microsoft 365, Google Workspace, HubSpot, and SendGrid.
- Proper selector management is essential for DKIM verification, DMARC alignment, key rotation, and maintaining email deliverability at scale.
- Common DKIM failures are usually caused by missing selectors, malformed DNS records, truncated 2048-bit keys, or DMARC alignment mismatches.
- Organizations using multiple ESPs should maintain a centralized inventory of active selectors, rotation schedules, and signing domains to avoid deliverability and compliance issues.
What Is a DKIM Selector?
A DKIM selector is a small text string included in a DKIM-signed email header that tells the receiving mail server where to find the corresponding public key in DNS. It is defined in the `s=` tag of the DKIM-Signature header.
Every DKIM signature includes a selector value. The selector, combined with the signing domain from the `d=` tag, forms a DNS query path that points to a specific TXT record containing the public key used to verify the signature.
Here is what the selector looks like inside an email header:
DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=selector1;
c=relaxed/relaxed; q=dns/txt; h=from:to:subject:date;
bh=abc123…=; b=xyz789…=
In this example, `selector1` is the DKIM selector. The receiving server will query `selector1._domainkey.example.com` to retrieve the public key.
Organizations often operate multiple signing keys simultaneously depending on their emailing requirements. Each key gets its own selector, so both can coexist under the same domain without conflict.
Selectors also make key rotation possible without downtime. You can publish a new key under a new selector while the old selector remains active, then cut over once propagation is complete.
How Do DKIM Selectors Work?
When a receiving mail server gets a DKIM-signed email, it reads the selector (`s=`) and domain (`d=`) from the email header, queries DNS at `{selector}._domainkey.{domain}`, retrieves the public key from the resulting TXT record, and uses that key to verify the cryptographic signature on the message.
Here is the step by step:
Step 1: The sending server signs the email
Before the email leaves the sending mail server (or ESP), the server uses its private key to generate a cryptographic signature over specified header fields and the message body. This signature, along with the selector value and signing domain, is added to the email as the `DKIM-Signature` header.
Step 2: The receiving server extracts the selector and domain
When the email lands in the inbox, the receiving server parses the `DKIM-Signature` header and pulls two values:
- The selector from `s=`
- The domain from `d=`.
Step 3: The receiving server queries DNS
The server constructs a DNS query by combining the selector, the fixed string `_domainkey`, and the domain: {selector}._domainkey.{domain} → TXT record
For example, if `s=google` and `d=example.com`, the DNS query is: google._domainkey.example.com
Step 4: DNS returns the public key
The TXT record at that DNS path contains the public key and associated parameters:
v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAO…
Step 5: The receiving server verifies the signature
The server uses the public key to verify the cryptographic signature in the email header.
- If the signature matches, DKIM passes.
- If the key is missing, the record is malformed.
- If the signature does not match, DKIM fails.
The selector connects the email header to the DNS record because without the DNS record, the receiving server would not have a way to locate the correct public key, especially when a domain publishes multiple DKIM keys for different services.
DKIM Selector Syntax and Format
DKIM selectors must conform to specific syntax rules defined in RFC 6376.
Allowed characters:
- Alphanumeric characters (a–z, A–Z, 0–9)
- Hyphens (-)
- Periods (.) for subdomain-style selectors
Constraints:
- Selectors are case-insensitive in DNS resolution, though lowercase is standard practice.
- There is no defined maximum length in RFC 6376, but practical DNS limitations apply. Most implementations keep selectors under 63 characters (the maximum DNS label length).
- Selectors cannot start or end with a hyphen.
- Periods in selectors create subdomain hierarchies in the DNS query. For example, `2024.jan._domainkey.example.com` is a valid query path if the selector is `2024.jan`.
The DNS TXT record format at the selector’s path contains the following tags:
| Tag | Significance | Description |
|---|---|---|
| v= | Recommended | Version (must be DKIM1) |
| k= | Optional | Key type (defaults to ‘rsa’; also supports ‘ed25519’) |
| p= | Required | Base64-encoded public key (empty value revokes the key) |
| t= | Optional | Flags (e.g., ‘t=s’ for strict domain alignment, ‘t=y’ for testing mode) |
| h= | Optional | Acceptable hash algorithms |
| s= | Optional | Service type (defaults to ‘*’, meaning all services |
Note: 2048-bit RSA keys produce public key strings that exceed the 255-character limit for a single DNS TXT string. DNS handles this through multi-string TXT records, where the value is split across multiple quoted strings that the resolver concatenates per RFC 6376. However, not all DNS management interfaces handle this efficiently, which is a common source of DKIM failures
How to Find Your DKIM Selector
There are four reliable methods to discover the DKIM selectors in use for a given domain. Each has different strengths depending on whether you control the domain, have access to email headers, or are auditing from outside.
Method 1: Inspect Email Headers
Inspecting email headers is the most direct approach. Open a message sent from the domain in question and view the full email headers.
- In Gmail: Open the message → click the three-dot menu → “Show original.”
- In Outlook: Open the message → File → Properties → “Internet headers.”
- In Apple Mail: View → Message → All Headers.
Look for the `DKIM-Signature` header and locate the `s=` tag. That value is the selector.
If the email passed through multiple signing services, you may see more than one `DKIM-Signature` header, each with a different selector.
Method 2: Use a DKIM Lookup Tool
If you know the selector name, you can query the DKIM record directly at selector._domainkey.example.com. PowerDMARC’s DKIM record lookup, MXToolbox, or command-line DNS queries like dig and nslookup can return the TXT record published for that selector.
Using dig:
bash
dig TXT selector1._domainkey.example.com +short
Using nslookup:
bash
nslookup -q=TXT selector1._domainkey.example.com
This method requires you to already know the selector name, or to try common defaults.
PowerDMARC’s DKIM lookup can also auto-detect selectors for many domains, validate DKIM syntax, identify missing or malformed records, and help troubleshoot common DKIM configuration issues.
Method 3: Check Your ESP’s Admin Console
Most email service providers display the DKIM selector and public key in their authentication settings. For example:
- Google Workspace: Admin Console → Apps → Google Workspace → Gmail → Authenticate email
- Microsoft 365: Defender portal → Policies & rules → Threat policies → Email authentication → DKIM
- Mailchimp: Website → Domains → Authentication → DKIM settings
Method 4: DMARC Aggregate Reports
This is the most powerful method for discovering -all selectors actively signing mail for your domain, including ones you may not know about.
DMARC aggregate reports (RUA reports) include the DKIM authentication results for every message received by reporting mail servers. Each result includes the selector used, the signing domain, and the pass/fail status.
If your organization runs multiple ESPs or if third-party services are signing on your behalf, DMARC reports will surface selectors you might not find through header inspection alone. This is especially valuable for uncovering shadow IT email services that were authorized once and never decommissioned.
PowerDMARC’s DMARC analyzer parses these aggregate reports automatically and surfaces all active DKIM selectors per domain in a single dashboard, eliminating the need to manually extract and cross-reference XML data from multiple reporting sources.
Note: There is no DNS wildcard or enumeration method to discover all selectors under `_domainkey.{domain}`. DNS does not support listing all subrecords of a zone from the outside. You cannot brute-force all possible selectors. The four methods above are the practical options.
5. ESP Default DKIM Selectors: 2026 Reference Table
One of the most common tasks in DKIM management is identifying which selector belongs to which email service. The table below lists the default DKIM selectors used by 14 major ESPs as of early 2026.
Important: ESPs can change default selectors at any time, and some platforms assign account-specific or randomized selectors. Always verify the selector shown in your own ESP admin console against this table.
| ESP/Mail Platforms | Default Selector(s) | Key Type | Note |
|---|---|---|---|
| Google Workspace | RSA 2048-bit | Configurable via Admin Console | |
| Microsoft 365 | `selector1`, `selector2` | RSA 2048-bit | Uses two selectors for automated rotation. Rotation can take up to 96 hours to fully propagate |
| Amazon SES | Format varies by region, e.g., `224i4yxa5dv7c2xz3..` | RSA 2048-bit | Unique per configuration set. Verify in the SES console |
| Mailchimp | `k1` | RSA 2048-bit | Verify in account domain authentication settings |
| SendGrid (Twilio | `s1`, `s2` | RSA 2048-bit | Automated key rotation between `s1` and `s2` |
| Postmark | Date-based, e.g., `20221121 | RSA 2048-bit | CNAME-based; selector changes on rotation |
| Salesforce Marketing Cloud | Varies by account configuration | RSA | SFMC DKIM setup varies significantly by account type, SAP configuration, and sending domain setup. Verify against your specific account |
| Hubspot | `hs1`, `hs2` | RSA 2048-bit | Configured via domain connection settings |
| Zohomail | `zoho` | RSA 1024-bit default | 1024-bit by default; upgrade to 2048-bit is available in admin settings |
| Constant Contact | Verify in account settings | RSA | Selector naming may vary by account. Confirm in your authentication dashboard |
| Klaviyo | Verify in account settings | RSA | Selector naming may vary. Confirm in Klaviyo's domain authentication settings |
| Active Campaign | Verify in account settings | RSA | Selector naming may vary. Confirm in your account's email authentication page |
| Brevo (formerly Sendinblue) | Verify in account settings | RSA | Confirm selector in Brevo's domain settings panel |
| Mimecast | `mimecast20190104` (example format) | RSA 2048-bit | Date-stamped format. Actual selector issued during onboarding |
If your domain sends email through three or four of these platforms simultaneously, you will have three or four active DKIM selectors in your DNS, and each one of them needs to be tracked, verified, and rotated independently.
Managing multiple DKIM selectors across several ESPs becomes difficult at scale, especially when each platform has different rotation schedules, selector formats, and DNS requirements.
PowerDMARC Hosted DKIM helps centralize selector management through a single dashboard, making it easier to add, rotate, validate, and monitor DKIM selectors without repeatedly modifying DNS records manually.
Naming Conventions and Best Practices
DKIM selectors can be named almost anything within the syntax rules. Without a consistent naming convention, selector management degrades quickly as services are added and keys are rotated.
Recommended Naming Patterns
A structured naming approach makes it much easier to identify ownership, track rotations, troubleshoot failures, and avoid operational confusion later on.
Pattern 1: ESP + Date
Examples:
- google-2026q1
- sendgrid-202601
- hubspot-2025q4
This is the most operationally useful pattern. At a glance, you can identify which service owns the key and when it was last rotated. During an audit, you can immediately flag any selector with a date more than 12 months old.
Pattern 2: Service function + Sequence
Examples:
- marketing-01
- transactional-01
- corporate-01
Useful when multiple ESPs serve the same domain and you want selectors organized by mail stream rather than vendor.
Pattern 3: ESP default (no custom naming)
Many ESPs do not allow custom selector naming. Google Workspace always uses `google`. Microsoft 365 uses `selector1` and `selector2`. In these cases, you work with what the platform provides and track the mapping externally.
Naming Practices to Avoid
Poorly structured or overly generic names can create confusion during audits, troubleshooting, and key rotations, especially in environments with multiple ESPs and large numbers of active selectors. Avoid the following naming practices:
- Generic names with no context: `key1`, `test`, `dkim` provide no information about the ESP or rotation state.
- Selectors containing sensitive information: Do not embed internal infrastructure details, server hostnames, or employee identifiers in selector names. Selector names are publicly visible via DNS.
- Excessively long selectors: While technically allowed up to 63 characters, selectors over 30 characters add unnecessary complexity to DNS records and lookup commands.
A single-domain, single-ESP setup is simple. You generate a key pair, publish the public key under the ESP’s selector, and you’re done. The operational challenge begins when that same domain sends email through multiple platforms.
A Practical Management Framework
The following five-stage lifecycle provides a structured approach to selector management:
Stage 1: Inventory
Document every active DKIM selector for every domain you manage, including the ESP, key length, date published, and the person or team responsible. DMARC aggregate reports are the fastest way to build this inventory because they reveal every selector currently signing mail for your domain, including the ones nobody remembers setting up.
Stage 2: Validate
For each selector in your inventory, query DNS to confirm the public key is published and correctly formatted. Run a test email through each ESP and verify DKIM passes. Check key lengths, and flag any selector using a 1024-bit key.
Stage 3: Standardize
Adopt a naming convention and apply it to every selector you control. For ESPs that use fixed selector names, document the mapping clearly. Decide on a rotation schedule and assign ownership.
Stage 4: Monitor.
Use DMARC aggregate reports to continuously monitor DKIM pass/fail rates per selector. A sudden failure rate spike on a specific selector usually points to a DNS change, a key expiration, or a configuration change at the ESP.
Stage 5: Decommission
When you stop using an ESP, revoke its DKIM key by publishing an empty `p=` value in the selector’s DNS record. Do not simply delete the DNS record. An empty `p=` value explicitly tells receiving servers the key has been revoked. Deleting the record entirely results in a DNS lookup failure, which is ambiguous and can be interpreted differently by different receivers.
PowerDMARC provides a centralized dashboard that maps all active DKIM selectors across every domain in your account, pulling data from DMARC aggregate reports and DNS monitoring simultaneously. For MSPs managing large client portfolios, this replaces the spreadsheet-based tracking that becomes unmanageable beyond a few dozen domains.
DKIM Key Rotation and Selector Strategy
DKIM key rotation means generating a new key pair and publishing the new public key under a new (or updated) selector, then configuring the sending service to sign with the new private key.
A DKIM private key that remains unchanged for years represents a growing risk. If the key is compromised through a server breach, an insider threat, or a vulnerability in the key storage system, an attacker can sign emails that pass DKIM authentication on behalf of your domain. Regular rotation limits the window of exposure.
How to Rotate DKIM Keys Without Downtime
The standard rotation process uses two selectors in sequence:
- Generate a new key pair: Create a new 2048-bit RSA (or Ed25519) key pair.
- Publish the new public key under a new selector: For example, if your current selector is `google-2025q3`, publish the new key under `google-2026q1`.
- Wait for DNS propagation: Allow 24 to 48 hours for the new TXT record to propagate globally. For Microsoft 365 specifically, allow up to 96 hours to fully propagate.
- Update the signing configuration: Configure the ESP or mail server to sign outgoing messages using the new private key and new selector.
- Verify: Send test messages and confirm DKIM passes with the new selector.
- Revoke the old key: After a transition period (typically 7 to 14 days, to allow in-flight messages signed with the old key to be delivered), publish an empty `p=` value for the old selector.
DKIM Key Rotation in Multi-ESP Environments
Each ESP has its own rotation mechanism:
- Microsoft 365: provides built-in selector rotation between `selector1` and `selector2`. Initiate rotation through the Defender portal.
- SendGrid: rotates automatically between `s1` and `s2`.
- Google Workspace: requires manual key regeneration through the Admin Console.
- Most marketing platforms: require manual rotation through their domain authentication settings.
Rotating all selectors on the same day creates a concentrated risk window and makes troubleshooting harder if something breaks. Spread rotations across different weeks or months.
PowerDMARC’s hosted DKIM feature handles key generation, DNS publishing, and selector rotation for all domains in your account, with configurable rotation schedules per domain and per ESP.
Common DKIM Selector Errors and How to Fix Them
When DKIM fails, the cause almost always traces back to one of a handful of selector or DNS configuration errors. The table below covers the most common failures, their symptoms, and how to resolve them.
| Error | Symptom | Cause | Fix |
|---|---|---|---|
| Selector not found | DKIM result: `permerror` or `none`; DNS query returns NXDOMAIN | The selector's DNS TXT record does not exist or is published under the wrong path. | Verify the full DNS path: `{selector}._domainkey.{domain}`. Check for typos in the selector name and domain. Confirm the record exists using `dig TXT {selector}._domainkey.{domain}`. |
| Public key is empty | DKIM result: `fail` | The TXT record exists but contains `p=` with no value, indicating a revoked key | This is intentional for decommissioned selectors. If the key should be active, republish the full public key value. |
| Public key is truncated | DKIM result: `fail`; the `p=` value appears cut off | 2048-bit RSA keys produce base64 strings that exceed the 255-character DNS TXT string limit. Some DNS management interfaces silently truncate long values instead of splitting them into multi-string records per RFC 6376. | Verify your DNS provider correctly handles multi-string TXT records. The public key value must be split across multiple quoted strings within a single TXT record (e.g., `"v=DKIM1; k=rsa; p=MIIBIjAN..." "BgkqhkiG9w0B..."`). Some DNS providers require you to enter the value as a single unbroken string and handle the splitting automatically. Others require manual splitting. Test with `dig TXT` and confirm the full key is returned. If your DNS provider silently truncates, consider switching providers or using a CNAME-based DKIM setup where the ESP hosts the TXT record. |
| Key type mismatch | DKIM result: `fail` | The `k=` tag in the DNS record specifies a different algorithm than what the signing server used. For example, `k=rsa` in DNS but the email was signed with Ed25519 | Ensure the `k=` tag matches the signing algorithm. If you're running both RSA and Ed25519, each needs its own selector and corresponding DNS record |
| Syntax error in TXT record | DKIM result: `permerror` | Missing semicolons, extra spaces inside tag values, or incorrect tag names in the DNS TXT record | Compare your record against the spec. Each tag-value pair must be separated by a semicolon. The `p=` value must contain only valid base64 characters with no spaces or line breaks inside the encoded string |
| Wrong domain alignment | DKIM passes but DMARC fails | The `d=` domain in the DKIM signature does not align with the `From:` domain. The selector and key are fine, but the signing domain is wrong for DMARC purposes. | |
| CNAME not resolving | DKIM result: `temperror` or `none` | Some ESPs use CNAME records to point the selector path to the ESP's own DNS infrastructure. If the CNAME is broken or the destination record is missing, the lookup fails | Verify the CNAME resolves correctly: `dig CNAME {selector}._domainkey.{domain}`. Then verify the destination TXT record exists and contains the public key |
The 2048-Bit Truncation Problem in Detail
When organizations upgrade from 1024-bit to 2048-bit DKIM keys ( given that 1024-bit RSA is considered weak for DKIM purposes), the base64-encoded public key roughly doubles in length. The resulting string typically exceeds 400 characters.
DNS TXT records have a 255-character limit per string within the record. The solution, defined in RFC 6376, is to split the value across multiple strings within a single TXT record. Receiving mail servers concatenate these strings automatically.
Most of the popular DNS management interfaces do not handle this efficiently:
- Some interfaces silently truncate the value at 255 characters without warning.
- Some interfaces reject the entry entirely with a vague error message.
- Some interfaces require the administrator to manually split the string and wrap each segment in quotes.
If you publish a 2048-bit key and DKIM immediately starts failing, check the actual DNS response using `dig` or `nslookup`. Compare the returned `p=` value against the full public key from your key pair. If the returned value is shorter, your DNS provider truncated it.
To avoid this:
- Use a DNS provider that natively supports long TXT records (Cloudflare, AWS Route 53, and most enterprise DNS platforms handle this correctly).
- Use CNAME-based DKIM, where the selector DNS path points to a CNAME hosted by the ESP. The ESP manages the TXT record on their infrastructure, avoiding the issue entirely.
- If you must use a provider that requires manual splitting, split the key into strings of 250 characters or fewer, each enclosed in quotes, within a single TXT record.
DKIM Selectors and DMARC Alignment
DKIM and DMARC are separate protocols, but they interact in a way that catches many administrators off guard. DKIM can pass while DMARC still fails. When that happens, the cause is almost always a domain alignment mismatch tied to how the selector’s signing domain relates to the `From:` header domain.
How DMARC Alignment Works with DKIM
DMARC requires that at least one authentication mechanism (SPF or DKIM) both passes and aligns with the domain in the `From:` header.
For DKIM alignment specifically, the `d=` domain in the DKIM-Signature header must match the domain in the `From:` header. The selector itself is not evaluated for alignment. Alignment is based solely on the `d=` domain.
DMARC supports two alignment modes:
| Mode | Requirement | Example |
|---|---|---|
| Relaxed (default) | The `d=` domain must be the same as, or a subdomain of, the `From:` domain (or vice versa) | `d=mail.example.com` aligns with `From: [email protected]` |
| Strict | The `d=` domain must exactly match the `From:` domain. | | `d=mail.example.com` does **not** align with `From: [email protected]` |
The Two Scenarios Where DKIM Passes but DMARC Fails
One of the most confusing email authentication outcomes is seeing DKIM pass while DMARC still fails. This usually happens when the signature itself is valid, but the signing domain does not align correctly with the visible From: domain used in the message.
Scenario 1: Third-party ESP signs with its own domain
Some ESPs, when DKIM is not explicitly configured for your domain, will sign outgoing messages with the ESP’s own domain in `d=`. For example, an email sent on behalf of `[email protected]` might carry a DKIM signature with `d=esp-provider.com`.
DKIM verification passes (the signature is valid), but DMARC fails because `esp-provider.com` does not align with `example.com`.
Configure DKIM signing in the ESP to use your own domain in the `d=` tag. This typically involves adding the ESP’s DKIM selector as a DNS record under your domain and enabling custom DKIM signing in the ESP’s settings.
Scenario 2: Subdomain signing with strict DMARC alignment
If your DMARC policy uses strict alignment (`adkim=s`) and your ESP signs with `d=sub.example.com` while the `From:` address uses `example.com`, DMARC will fail even though DKIM passes.
Either switch to relaxed alignment (`adkim=r`, which is the default) or ensure the `d=` domain in the DKIM signature exactly matches the `From:` domain.
Auditing Alignment Across Multiple ESPs
In multi-ESP environments, each sending platform may sign with different `d=` domains. One ESP might sign with your root domain, another with a subdomain, and a third might default to its own domain until you configure custom signing.
DMARC aggregate reports show the `d=` domain and alignment result for every DKIM-signed message. Review these reports to identify any ESP that is signing with a misaligned domain. PowerDMARC’s DMARC reports highlight alignment failures per sending source, making it straightforward to identify which ESP needs reconfiguration.
Conclusion
The organizations that treat selector management as a continuous operational practice, rather than a one-time setup task, are the ones that maintain consistent deliverability, pass audits cleanly, and respond to incidents quickly.
If you manage more than a handful of domains or work with multiple ESPs, centralizing your DKIM selector visibility is worth the investment.
PowerDMARC provides that centralized view, combining DMARC aggregate report analysis, DNS monitoring, and hosted DKIM management into a single interface designed for exactly this kind of operational complexity.
Manage DKIM selectors across multiple ESPs with ease. Sign up for a trial to monitor DKIM records, improve DMARC alignment, and protect email deliverability.
FAQs
How do I find my DKIM selector?
You can find your DKIM selector by viewing an email’s full headers and locating the DKIM-Signature field. The value after s= is the selector. For example, in s=google, the selector is google.
How many DKIM selectors can a domain have?
There is no technical limit on the number of DKIM selectors a domain can have. Organizations commonly use multiple selectors simultaneously for different email providers, departments, or key rotation periods.
Can multiple ESPs use different DKIM selectors on the same domain?
Yes. Each email service provider typically uses its own DKIM selector. For example, Google Workspace, SendGrid, and Mailchimp can all have separate selectors under the same domain without conflict.
What’s the difference between a DKIM selector and a DKIM key?
The selector is the label used to locate the DKIM record in DNS, while the DKIM key is the actual cryptographic public/private key pair used to sign and verify emails.
Why does DKIM pass but DMARC still fail?
This usually happens because of DMARC alignment failure. The DKIM signature may validate successfully, but the d= domain in the DKIM signature does not align with the From: domain used in the email.
How often should DKIM selectors and keys be rotated?
Security best practices recommend rotating DKIM keys every 6–12 months. During rotation, both the old and new selectors should remain active temporarily to avoid validation failures during DNS propagation.
- What Is a DKIM Selector and How to Manage It Across Multiple ESPs? - May 26, 2026
- Exchange SPF Check: How to Verify, Publish, and Fix SPF Records in Exchange - May 20, 2026
- How to Set Up an SPF Record for Gmail - February 17, 2026
