DMARC Analyzer

TL;DR

• A DKIM selector is a short label that names a specific public key for a signing domain. Defined as the s= tag value in the DKIM-Signature header (RFC 6376 §3.1), the selector is what makes multiple active DKIM keys possible for a single domain.
• DNS location: the public key is published as a TXT record at the DNS name <selector>._domainkey.<domain>. The _domainkey infix is the canonical anchor defined in RFC 6376 §3.6.2. Example: selector1._domainkey.example.com.
• The s= tag in the DKIM-Signature header tells the verifier which selector to look up. Combined with the d= tag (signing domain), the verifier constructs the DNS query <s_value>._domainkey.<d_value> and retrieves the TXT record containing the public key (the p= tag in that record).
• The selector TXT record tags (RFC 6376 §3.6.1): v=DKIM1 (version, mandatory), k=rsa (key type, also k=ed25519 per RFC 8463), p=<base64-public-key> (mandatory), and the optional t=y (test mode), t=s (strict alignment between d= and i=), h=sha256, s=email, n=<notes>.
• Provider selector catalogues: Microsoft 365 uses selector1 and selector2 (CNAME-pointed at .onmicrosoft.com); Google Workspace uses google by default; Amazon SES Easy DKIM uses three CNAMEs ending in .dkim.amazonses.com; SendGrid uses em<n> and s1/s2; Mailgun uses k1 or mailo; Mailchimp uses k1; Postmark uses date-based labels; SparkPost uses scph<yyyymm>; Klaviyo uses klaviyo1; HubSpot uses hs1-<...>; Brevo uses mail.
• The dual-selector rotation pattern depends on selectors enabling zero-downtime key changes: publish the new selectors public key in DNS, switch the signer to use the new selector, wait for the cache TTL to drain on the old selector, then retire the old selector. See DKIM key rotation for the full procedure.
• The seven most common selector failures: (1) NXDOMAIN (selector record never published or wrong DNS zone); (2) wrong selector name in the DKIM-Signature header; (3) stale selector after rotation; (4) 255-byte TXT-record split pitfall corrupting the base64 key; (5) CNAME-vs-TXT confusion at the DNS provider; (6) wildcard-mask interference (*.example.com A/AAAA records do not affect TXT but *._domainkey wildcards do); (7) DNS propagation lag immediately after publishing a new selector. Each is documented in section 10 with symptoms, diagnosis steps, and operational fixes.

1. Overview: why DKIM has selectors

DKIM signs outbound mail with a private key, and the receiver verifies the signature by fetching the corresponding public key from the senders DNS. The obvious DNS-only design would be to publish a single public key per signing domain at a fixed well-known name (e.g. _dkim.example.com). RFC 6376 deliberately chose a more elaborate scheme: the public key is published at <selector>._domainkey.<domain>, where the selector is a short label chosen by the signer. The DKIM-Signature header carries both the signing domain (d=) and the selector (s=); the verifier combines them with the _domainkey infix to construct the DNS query.

The selector level of indirection exists because a real-world domain almost always has more than one DKIM key in active use simultaneously:

1. Multi-vendor deployments. A typical mid-size business sends mail from Microsoft 365 (corporate mail), Mailchimp (marketing newsletters), SendGrid (transactional notifications), and an internal Postfix server (server-generated alerts). Each sender owns its own private key and signs with its own selector; each publishes the corresponding public key under the same root signing domain (e.g. example.com) at a different selector name. Selectors are the namespacing mechanism that allows the same d=example.com domain to host four independent public keys.
2. Zero-downtime key rotation. Cryptographic best practice requires regular key rotation to limit the blast radius of a key compromise and to keep up with evolving algorithm recommendations (RFC 8301 forbade rsa-sha1 and recommends RSA keys of at least 2048 bits; Ed25519 was introduced by RFC 8463). Rotating without downtime requires publishing the new key BEFORE switching the signer to use it — which means both the old and the new key must be in DNS simultaneously. Selectors enable this: the old key stays at the old selector, the new key is published at a new selector, the signer is switched, and the old selector retires only after the cache TTL drains. See DKIM key rotation for the full dual-selector procedure.
3. Per-purpose key isolation. Security-conscious operators issue distinct keys for distinct purposes (newsletter signing, transactional signing, corporate-mail signing). A compromise of one private key (a misconfigured marketing-automation vendors API key, a stolen SaaS-sender token) contains the blast radius to the one signer that owned that key; the corporate mail keeps signing with a separate key under a separate selector.
4. Per-region key separation. Multi-region operators sometimes separate signing infrastructure by region for latency or regulatory reasons (EU signing in EU servers, US signing in US servers). Each region gets its own selector; the signing domain stays the same; DMARC alignment continues to bind both selectors to the same From: organisational domain.
5. Per-message-class key isolation. Some operators issue per-application-tier selectors (production vs staging vs development). Staging mail never reaches the production selector, so a misconfigured staging signer cannot accidentally invalidate production signatures.

Without selectors, every one of these multi-key deployments would require some other namespacing mechanism. RFC 6376 chose to bake selectors into the protocol because every real-world deployment needs them.

The trade-off is mechanical: every selector lookup is one extra DNS query the receiver must perform during verification. In practice this is essentially free (the selector TXT cache locally per receiver), and the operational benefit of multi-key support vastly outweighs the lookup cost.

2. The <selector>._domainkey.<domain> DNS label tree

DKIM public keys live under a dedicated DNS label anchor: the _domainkey infix. RFC 6376 §3.6.2 chose the underscore-prefixed _domainkey label so the DNS namespace for DKIM keys is unambiguously distinguishable from ordinary hostnames (underscore-prefixed labels are reserved for protocol-defined service records — see also _dmarc, _smtp._tls, _mta-sts, _caa).

The canonical label structure:

<selector>._domainkey.<domain>.

A signer with d=example.com and s=selector1 publishes the public key at the DNS name selector1._domainkey.example.com. The verifier reads the DKIM-Signature header, extracts the d= and s= values, concatenates them with the _domainkey infix, and issues a DNS TXT query at that name.

Worked examples by signing scenario:

Notice the Mailgun row: when a provider signs mail under a subdomain (here mg.example.com, and likewise any service set up on a subdomain such as em1234.example.com) rather than the root domain, the d= tag is the subdomain and the selector is published under it. DMARC alignment uses the organisational domain (example.com) so the subdomain still aligns relaxed; strict alignment fails unless the From: address is in that same subdomain.

The label is case-insensitive (DNS labels are case-insensitive per RFC 4343), so Selector1._domainkey.example.com and selector1._domainkey.example.com resolve to the same record. By convention selectors are lowercase in both DKIM-Signature headers and DNS records.

3. The selector TXT record tags (RFC 6376 §3.6.1)

The published selector record is a TXT record (or a CNAME pointing to one) at <selector>._domainkey.<domain>. The TXT value is a sequence of tag=value pairs separated by semicolons. RFC 6376 §3.6.1 defines the tag set.

A canonical production selector TXT record looks like:

selector1._domainkey.example.com.  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAv5..."
                                          "...rest-of-base64-public-key=="

The TXT value is wrapped across two character-strings (each ≤255 bytes) which the resolver concatenates at the protocol layer. Operators publishing through a DNS provider UI must either paste the full value as one string (the UI handles segmentation transparently — Cloudflare, Route 53, Google Cloud DNS) or split the value into two quoted strings matching the BIND zone-file syntax shown above.

4. The s= and d= tags in the DKIM-Signature header

The verifier discovers which selector to use by reading the s= tag in the DKIM-Signature header. The signing domain comes from the d= tag. Both are mandatory per RFC 6376 §3.5.

A canonical production DKIM-Signature header:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=example.com; s=selector1;
        h=from:to:subject:date:message-id;
        bh=47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=;
        b=H8b...

Reading this header:

• d=example.com — the signing domain. The verifier uses this for DMARC alignment (the From: header organisational domain must match example.com for the DKIM verdict to align).
• s=selector1 — the selector. The verifier constructs the DNS query selector1._domainkey.example.com and retrieves the TXT record containing the public key.
• c=relaxed/relaxed — canonicalization (see DKIM canonicalization).
• a=rsa-sha256 — algorithm. Confirms the verifier should expect an RSA key under the selector (a k=rsa public key at selector1._domainkey.example.com).
• bh=... — body hash (see DKIM canonicalization).
• b=... — signature over canonicalized headers + bh=.

The verifier algorithm is straightforward: parse the d= and s= tags from the DKIM-Signature header, issue a DNS TXT query at <s>._domainkey.<d>, parse the response for the p= public key, recompute the body hash with the canonicalization declared in c= using the algorithm declared in a=, verify the signature against the public key, and emit the verdict.

Why the selector is in the signature header (not derived from the domain): a single signing domain can have many selectors. The DKIM-Signature header is the ONLY place the message itself can declare which selector signed it — without an explicit s= tag, the verifier would not know which of the many possible selector keys to use.

5. The eight selector-naming patterns operators encounter

RFC 6376 §3.1 specifies the syntax of a selector name (a DNS label sequence) but does not prescribe a naming convention. Over time eight broad naming patterns have emerged. Recognising the pattern tells operators what the selector probably means and how to rotate it.

5.1 The numbered-pair pattern (selector1 / selector2)

Pattern: two selectors numbered sequentially; one is active at any given time, the other is the rotation buffer.

When to use: any deployment where the operator wants a clean dual-selector rotation workflow. Microsoft 365 follows this pattern as the default; many self-hosted OpenDKIM operators copy it.

Operator workflow: at rotation time, generate a new key, publish at the non-active selector, switch the signer to use the non-active selector, retire the previously-active selector after the cache TTL drains.

Pitfalls: the numbered-pair pattern requires DISCIPLINE about which selector is currently active — operators sometimes lose track. A label like n=Microsoft 365 active selector as of 2026-01-15 in the TXT helps.

5.2 The date-based pattern (20240301 / jan2026 / mar2026)

Pattern: the selector name is the rotation date (ISO-8601 20240301, short mar24, or descriptive mar2026).

When to use: self-hosted signers with a regular rotation cadence (quarterly, semi-annual, annual). Postmark uses this pattern for its provider-managed selectors.

Operator workflow: name the new selector after the rotation date; the date is the audit log entry — anyone reading jan2026._domainkey.example.com in a DKIM-Signature header knows the key was deployed in January 2026.

Pitfalls: the date naming pattern creates noise over years (a long-lived domain accumulates many old jan2024, jul2024, jan2025 records). Retire old selectors aggressively after the rotation cache TTL drains.

5.3 The provider-named pattern (google / mailgun / mailchimp)

Pattern: the selector name is the name of the provider that owns the key.

When to use: any multi-vendor deployment where operators want the DKIM-Signature header to be self-documenting — reading s=google on a message tells the reader Google Workspace signed it.

Operator workflow: generate a selector named after the provider when onboarding that provider; retire when offboarding the provider.

Pitfalls: the provider-named pattern encodes the vendor relationship into DNS, which creates a small information disclosure (anyone enumerating _domainkey records can see which providers you use). For most operators this is not a concern; for security-conscious operators consider opaque selector names.

5.4 The short-letter pattern (s1 / s2 / k1 / k2 / em1)

Pattern: a short prefix letter followed by a number. SendGrid uses s, Mailgun uses k, Mailchimp uses k, some legacy signers use dk.

When to use: provider-managed deployments where the provider chose the convention — operators inherit the pattern from the provider.

Operator workflow: follow the providers documented value; the provider will tell you to publish s1._domainkey.example.com (SendGrid) or k1._domainkey.example.com (Mailgun) and gives you the corresponding CNAME or TXT value.

Pitfalls: short-letter selectors are easy to mistype; selector1 vs selecter1 typos cause NXDOMAIN failures.

5.5 The opaque-identifier pattern (Amazon SES abcdef1234567890; SparkPost scph0717)

Pattern: a long alphanumeric string that the provider generates and the operator does not interpret. Amazon SES Easy DKIM uses three 16-hex tokens per signing domain; SparkPost uses scph<yyyymm>.

When to use: provider-managed deployments where the provider rotates keys transparently and the operator does not need to track which selector is active.

Operator workflow: publish the three CNAMEs the provider gives you (Amazon SES) or the single TXT the provider gives you (SparkPost); the provider rotates without operator intervention.

Pitfalls: the operator cannot inspect the selector to determine what it is for — the opaque identifier needs operator-side documentation linking it to the vendor relationship.

5.6 The purpose-based pattern (newsletter / transactional / corporate)

Pattern: the selector name describes the mail stream the key signs.

When to use: security-conscious operators who want per-purpose key isolation (compromise of the newsletter key does not affect transactional signing).

Operator workflow: issue one selector per mail stream; route each stream through a signer configured to use only its assigned selector.

Pitfalls: requires consistent routing discipline — if your transactional mail accidentally goes through the newsletter signer, the receiver sees an unexpected selector and DMARC alignment may differ.

5.7 The Microsoft-365-style hyphenated pattern (selector1-example-com)

Pattern: a Microsoft-365 specific convention where the CNAME target encodes the customer domain into the selector name with dots replaced by hyphens (so selector1._domainkey.example.com CNAMEs to selector1-example-com._domainkey.<tenant>.onmicrosoft.com).

When to use: only relevant if you operate Microsoft 365 — Microsoft mandates this pattern as the CNAME target.

Operator workflow: at custom-domain onboarding, the Defender portal generates the correct CNAME target with the hyphen substitution pre-computed. Operators copy-paste the CNAME values without computing the hyphenated form themselves.

Pitfalls: only applies inside Microsoft 365; do not reproduce this pattern in self-hosted deployments.

5.8 The hosted-service prefix pattern (HubSpot hs1-<...>; Klaviyo klaviyo1)

Pattern: the selector includes the provider name as a prefix plus a sequence or hash suffix. HubSpot uses hs1-<customer-tenant-id>; Klaviyo uses klaviyo1.

When to use: provider-managed deployments where the provider needs to multi-tenant the selector under your domain.

Operator workflow: publish the selector the provider gives you; the prefix tells you which provider published it.

Pitfalls: as with provider-named selectors, the prefix exposes the vendor relationship via DNS.

6. The provider selector catalogue

A catalogue of the selector names operators encounter in the major email-sending providers. Use this table when reading an unfamiliar DKIM-Signature header to identify the signer, or when onboarding a new provider to know which CNAME or TXT records to publish.

The DMARC Analyzer Domain Security Checker automatically resolves the published selectors for a domain and identifies which provider each selector belongs to — useful for auditing a deployment after a vendor change or for surfacing forgotten selectors from past vendors.

7. The multi-selector / multi- vendor deployment model

Almost every production domain runs more than one DKIM-signing path simultaneously. The selector mechanism is the namespacing primitive that makes multi-vendor coexistence possible.

A canonical multi-vendor deployment for a typical mid-size business sending under example.com:

All four signers share the same d= domain (example.com) but each uses a distinct selector. The _domainkey.example.com subtree accommodates all four selector records without conflict. Receivers verify each message by reading the s= tag and fetching the corresponding selector record.

The DMARC implications:

• One DMARC policy at _dmarc.example.com covers all four signers. The policy applies to the From: header organisational domain, not per-signer.
• DKIM alignment is per-signature. A message signed by Microsoft 365 with d=example.com and s=selector1 aligns with From: someone@example.com in relaxed and in strict mode, because the domains are identical. A message signed by Mailchimp with d=example.com and s=k1 aligns identically. The selector itself is not involved in alignment — the d= tag is.
• SPF and DKIM both contribute to alignment. SPF authorises the sending IP; DKIM authorises the cryptographic signature. Multi-vendor deployments typically rely on DKIM alignment for the bulk of senders because each vendor needs IP space SPF cannot tractably include (DKIM has no 10-lookup limit problem).

See DMARC alignment explained for the full alignment semantics, and SPF lookup limit explained for why multi-vendor deployments typically rely on DKIM alignment more than SPF alignment.

8. The dual-selector zero-downtime rotation pattern

Rotating a DKIM key without breaking signature verification on in-flight mail requires publishing the new key BEFORE switching the signer to use it. The selector mechanism is the protocol primitive that enables this — the new key gets published at a new selector, the signer is switched to the new selector, and the old selector retires only after the cache TTL drains.

The canonical six-step procedure:

1. Generate the new key pair. Self-hosted: openssl genrsa 2048 or opendkim-genkey -s newselector -d example.com. Provider-managed: rotate inside the providers admin console (Microsoft 365 Defender portal, Google Workspace Admin Console, etc.).
2. Choose the new selector name. Follow the pattern (numbered-pair if the current is selector1, date-based if the current is jan2026, etc.).
3. Publish the new selectors public key at <new-selector>._domainkey.example.com. Verify the TXT record resolves with dig +short TXT <new-selector>._domainkey.example.com.
4. Wait for DNS propagation. Typically 5-15 minutes, capped at the parent zone TTL. Confirm propagation by querying from multiple recursive resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, your local resolver).
5. Switch the signer to the new selector. OpenDKIM: update KeyTable and SigningTable to reference the new selector, reload OpenDKIM. Provider-managed: toggle the active selector in the providers admin console.
6. Retire the old selector after the cache TTL drains. Wait at least 2 × max(TTL) for in-flight signatures to propagate (typical: 24-48 hours is conservative). Delete the old selector TXT record. Verify the signer no longer references it.

The DMARC Analyzer DKIM key rotation page documents the full procedure with per-provider variants and the emergency single- selector hot-swap. The key insight here is that the selector mechanism is the protocol primitive underlying the entire rotation playbook — without selectors, zero-downtime rotation would not be possible.

9. The seven most common selector failures

Every selector-related DKIM verification failure falls into one of seven canonical patterns. Recognising the pattern accelerates diagnosis from hours of guesswork to minutes of targeted investigation.

9.1 Selector NXDOMAIN

Symptom: the verifier reports dkim=permerror or dkim=none in the Authentication-Results header with a reason like (no key for signature) or (selector not found). The receivers DNS query for <selector>._domainkey.<domain> returns NXDOMAIN.

Diagnosis: run dig +short TXT <selector>._domainkey.<domain>. If the answer is empty, the record does not exist at the authoritative resolver. If dig +trace shows NXDOMAIN at the authoritative server, the selector was never published or was published at the wrong zone. If dig +short returns a valid record from the authoritative server but the receivers resolver still sees NXDOMAIN, suspect a transient DNS-provider propagation lag or a stale negative cache.

Fix: publish the TXT (or CNAME) at the correct DNS name. Verify with dig +short TXT from multiple recursive resolvers. If a stale negative cache is suspected, wait the SOA negative-cache TTL (typically 5 minutes to 1 hour).

9.2 Wrong selector name in the DKIM-Signature header

Symptom: the verifier reports NXDOMAIN, but dig +short TXT <canonical-selector>._domainkey.<domain> returns a valid record. The mismatch is between what the signer emitted (s=<typo>) and what was published in DNS.

Diagnosis: read the s= tag in the failing message DKIM-Signature header. Compare to the actual selector name in DNS. Typos are common — selecter1 vs selector1, googel vs google, scph0717 vs scph717.

Fix: correct the signer configuration. OpenDKIM: fix the KeyTable entry. Provider-managed: the provider control panel typically prevents typos at UI entry, so a typo at the signer-side usually indicates a misconfigured custom signer.

9.3 Stale selector after rotation

Symptom: the verifier reports NXDOMAIN immediately after a key rotation. The signer is using the new selector but the new selectors public key has not propagated yet (or was never published).

Diagnosis: read the DKIM-Signature header on a failing message. Verify the s= tag matches the new selector you intended to use. Verify dig +short TXT <new-selector>._domainkey.<domain> returns the new key. If not, the rotation procedure skipped step 3 (publish the new selectors public key) or step 4 (wait for DNS propagation) — the signer switched before the key was reachable.

Fix: publish the new selectors public key, then wait for propagation, then verify with dig, THEN switch the signer. Follow the six-step procedure in section 8.

9.4 The 255-byte TXT-record split pitfall

Symptom: the verifier reports dkim=permerror with a reason like (key parse error) or (invalid public key). The selector record exists and returns content, but the base64-decoded public key is corrupted.

Diagnosis: run dig +short TXT <selector>._domainkey.<domain>. Look for the base64 p= value. If the base64 string is shorter than expected (less than 300 characters for RSA-2048) or has a clear truncation point, the DNS provider UI silently truncated the TXT at the 255-byte boundary. Some older DNS provider UIs accept a single string longer than 255 bytes and silently truncate; modern UIs either reject or wrap into multiple character-strings correctly.

Fix: at the DNS provider UI, paste the full TXT value as multi-string (each ≤255 bytes, wrapped in double quotes per the BIND zone-file convention). At Cloudflare and Route 53 the UI handles segmentation transparently — paste the full value as one string and the provider multi-segments correctly. At older or legacy DNS providers, manual segmentation is required.

9.5 CNAME-vs-TXT confusion at the DNS provider

Symptom: the operator published a record at the correct name but chose the wrong record type. Either a TXT was published where the provider expected a CNAME (Microsoft 365: published a TXT containing the CNAME target string instead of a CNAME pointing at the target), or a CNAME was published where the provider expected a TXT.

Diagnosis: query dig +short CNAME <selector>._domainkey.<domain> and dig +short TXT ... separately; many servers no longer give a useful answer to ANY queries. Compare the published record type to what the provider documentation specifies. A common Microsoft 365 failure is publishing the CNAME target as a TXT value, which makes the receiver see a TXT containing a hostname instead of the expected key value.

Fix: delete the wrong-type record; publish the correct-type record. For Microsoft 365 and providers using CNAME-based selectors, this means a literal CNAME pointing at the provider-supplied target — not a TXT containing the CNAME target as text.

9.6 Wildcard-mask interference

Symptom: the verifier reports dkim=permerror with a reason indicating a TXT record was retrieved but the content is not a valid DKIM record (no v=DKIM1 prefix, no p= public key).

Diagnosis: run dig +short TXT *._domainkey.<domain>. If the response matches a configured wildcard (*.example.com TXT or *._domainkey.example.com TXT), the wildcard is shadowing the selector. The receivers DNS resolver returns the wildcard-matched TXT instead of an authoritative NXDOMAIN.

Fix: remove the wildcard TXT under _domainkey.example.com. Wildcards do not shadow records that are explicitly defined, so publishing the explicit selector TXT also resolves the issue — but the wildcard at *._domainkey is almost never useful and is best removed.

9.7 DNS propagation lag immediately after publishing

Symptom: a newly-published selector works at the authoritative resolver (dig +short TXT at the authoritative server returns the record) but fails at downstream recursive resolvers (Gmail, Microsoft 365 mailbox receiving end). The verifier sees NXDOMAIN for the first few minutes to hours after publishing.

Diagnosis: run dig +short TXT <selector>._domainkey.<domain> @ns<n>.<ns-provider> against the authoritative server directly. If the answer is valid, the issue is propagation — wait for the parent zone TTL to expire across all caching resolvers.

Fix: wait for DNS propagation (typically 5-15 minutes for small TTLs; up to 24 hours for legacy 86400-second TTLs). Do NOT switch the signer to a new selector until propagation is confirmed across at least three recursive resolvers (Cloudflare 1.1.1.1, Google 8.8.8.8, Quad9 9.9.9.9). The DNS propagation deep dive covers the cache-behaviour mechanics.

10. FAQ

What is a DKIM selector?

A DKIM selector is a short label that names a specific public key for a signing domain. RFC 6376 section 3.1 defines the selector as the s= tag value in the DKIM-Signature header, and the verifier uses the selector together with the signing domain (the d= tag value) to construct a DNS query for the corresponding public key. The DNS label structure is <selector>._domainkey.<domain> with the public key published as a TXT record at that name. Selectors exist so a single signing domain can publish multiple public keys simultaneously (one per selector), which enables multi-sender deployments (each sender gets a unique selector and the sender owns the corresponding private key), zero-downtime key rotation (publish the new selector first, switch the signer to use it, then retire the old selector after the cache TTL drains), and per-vendor key isolation (a compromise of one vendors selector private key does not affect the others). A selector is the operator-meaningful name (selector1, google, s1, k1, mailo, scph0717) operators see in DKIM-Signature headers and DNS — the s= tag value.

What is the s= tag in a DKIM-Signature header?

The s= tag in the DKIM-Signature header is the selector identifier. Defined in RFC 6376 section 3.5, the s= tag tells the verifier which selector to look up. Together with the d= tag (signing domain), the verifier constructs the DNS query <s_value>._domainkey.<d_value> and retrieves the TXT record containing the public key (the p= tag in that record). The s= tag value is a domain-style label (lowercase letters, digits, hyphens, dots) and is the operator-visible name of the key the signer used. Reading a DKIM-Signature header, the s= tag is one of the first things to identify — the selector tells you which key signed the message and (combined with d=) where to find the public key in DNS. Modern DKIM-Signature headers always include an explicit s= tag; there is no default.

Where in DNS is a DKIM selector published?

A DKIM selector is published as a TXT record at the DNS name <selector>._domainkey.<domain>. RFC 6376 section 3.6.2 specifies the _domainkey infix as the canonical anchor under the signing domain. For example, a signer with d=example.com and s=selector1 publishes the public key at selector1._domainkey.example.com. The TXT record contains the selector tags: v=DKIM1, k=rsa (or k=ed25519 per RFC 8463), p=<base64-encoded-public-key>, and optionally t= (flags), h= (allowed hash algorithms), s= (service type), n= (notes). Many provider deployments use a CNAME from <selector>._domainkey.<your-domain> to a provider-managed selector hostname instead of a TXT — Microsoft 365 selector1._domainkey.yourdomain.com CNAMEs to selector1-yourdomain-com._domainkey.tenant.onmicrosoft.com; SendGrid s1._domainkey.yourdomain CNAMEs to s1.domainkey.u<n>.wl.sendgrid.net; Amazon SES Easy DKIM uses three CNAMEs ending in .dkim.amazonses.com. CNAME-based selectors avoid the manual TXT-rewrite operators would otherwise need at each provider key rotation.

What does selector1 mean in Microsoft 365 DKIM?

In Microsoft 365 (Exchange Online), selector1 and selector2 are the two managed selectors Microsoft uses for every DKIM-signing tenant. Only one of them signs at any given time, and the other is needed for key rotation; the administrator starts a rotation, and Microsoft then switches signing to the other selector. The DNS pattern operators publish is two CNAMEs: selector1._domainkey.<your-domain> CNAMEs to selector1-<your-domain-with-hyphens>._domainkey.<tenant>.onmicrosoft.com, and selector2._domainkey.<your-domain> CNAMEs to selector2-<your-domain-with-hyphens>._domainkey.<tenant>.onmicrosoft.com. The hyphen substitution rule is the Microsoft 365 onmicrosoft.com mapping: a custom domain example.com becomes example-com in the target hostname (dots become hyphens). Once both CNAMEs are published and Microsoft has enabled DKIM signing in the Defender portal (Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM), Microsoft 365 signs outbound mail with the active selector, and the verifier resolves the CNAME chain to retrieve the public key Microsoft manages.

How do I add a new DKIM selector for a new sender?

The four-step procedure for adding a new selector for a new sender. Step 1: Decide the selector name. Most providers pick the name for you (Microsoft 365 selector1 / selector2, Google Workspace google, SendGrid s1/s2, Amazon SES Easy DKIM domainkey-based CNAMEs); for self-hosted signers you pick a name following the recommended pattern (date-based 20240101, or sequenced k1 / k2, or sender-named newsletter / transactional). Step 2: Generate or obtain the public/private key pair. Self-hosted signers generate RSA-2048 or Ed25519 keys with openssl genrsa 2048 or opendkim-genkey; provider-managed signers expose a copy-paste DNS record value from the provider control panel. Step 3: Publish the public key in DNS as a TXT record (or CNAME for provider-managed) at <selector>._domainkey.<your-domain>. Step 4: Wait for DNS propagation (typically 5-15 minutes, capped at the parent TTL), then enable the signer to use the new selector. The DMARC Analyzer Domain Security Checker verifies the public key is reachable and well-formed; verify the new selector with a test send to a mailbox you control and inspect the DKIM-Signature header for s=<new-selector-name>.

Why does my DKIM verification fail with selector NXDOMAIN?

A selector NXDOMAIN (no such domain) means the verifier issued a DNS query for <selector>._domainkey.<domain> and the authoritative name server returned NXDOMAIN — no record exists at that name. The five canonical causes: (1) the selector TXT or CNAME record was never published (most common — the operator generated the key but forgot to publish it); (2) the record was published at the wrong DNS zone (publishing at sub._domainkey.example.com when the signer uses sub._domainkey.subdomain.example.com); (3) the record was published with a typo in the selector name (Microsoft 365 selector1 vs selecter1 — the receiver queries the correct name and gets NXDOMAIN); (4) the record was deleted during a maintenance window or DNS provider migration and not restored; (5) the DNS provider is rate-limiting or returning NXDOMAIN for transient reasons (rare — usually a real misconfiguration). The diagnostic command is dig +short TXT <selector>._domainkey.<domain> at the receivers resolver — if dig returns nothing, the verifier sees NXDOMAIN. The fix is to publish the selector record at the correct name.

Can I have multiple DKIM selectors for the same domain?

Yes — multiple DKIM selectors per domain is the canonical pattern for almost every production deployment. The selector mechanism is explicitly designed so a single signing domain (d=example.com) can publish multiple selector TXT records simultaneously, one per active key. Common multi-selector scenarios: (1) multi-vendor deployments where each sender (Microsoft 365 + Mailchimp + SendGrid + an internal Postfix) publishes its own selector under the same domain (selector1 / selector2 / k1 / mlsend1 / postfix1); (2) zero-downtime key rotation using a dual-selector pattern (old selector remains until the cache TTL drains, then new selector replaces it); (3) per-purpose key isolation (newsletter signer uses one selector, transactional uses another, corporate mail uses a third — compromise of one private key contains the blast radius); (4) per-region key separation (signing infrastructure in EU vs US uses different selectors). The only constraint is that each selector name must be unique under the same _domainkey. parent — you cannot reuse selector1 for two different keys.

What is the difference between selector and signing domain?

The selector and the signing domain are two distinct identifiers in a DKIM-Signature header. The signing domain is the d= tag value — the DNS domain that owns the key, and the domain the verifier uses for DMARC alignment. The selector is the s= tag value — the specific public key under that domain. The verifier combines them with the _domainkey label to construct the DNS query for the public key: <s_value>._domainkey.<d_value>. The signing domain corresponds to organisational identity (which company signed this message); the selector corresponds to which key (newsletter vs transactional, January 2026 vs March 2026, Microsoft 365 selector1 vs Mailchimp k1). DMARC alignment depends on the d= tag matching the From: header organisational domain (strict or relaxed adkim) — selectors are not involved in alignment. A single domain can have many selectors; a selector is meaningless without the signing domain.

What is the 255-byte TXT record pitfall for DKIM selectors?

DNS TXT records are limited to 255 octets per individual character-string segment, but the record itself can contain multiple segments concatenated at the DNS protocol layer (RFC 1035 §3.3.14). A DKIM selector public key (especially RSA-2048 or larger) base64-encodes to roughly 392 characters and therefore must be split across two or more 255-byte segments inside the TXT record. The pitfall is at the DNS provider UI: some providers (Cloudflare older UI, some legacy panels) accept a single string longer than 255 bytes in the input box and silently truncate it at the 255-byte boundary, producing a corrupted public key that DKIM verifiers cannot use. The detection signature is a DKIM verification failure where the receiver retrieved the selector TXT but the base64-decoded public key fails to parse as a valid RSA SubjectPublicKeyInfo structure. The fix at most modern providers is to wrap each 255-byte segment in double quotes in the TXT record input (the BIND zone file syntax), which the provider accepts as the multi-string TXT format the resolver concatenates correctly. Verify with dig +short TXT <selector>._domainkey.<domain> — the output should show the full base64 key without truncation.

11. Related guides

• DKIM explained — DomainKeys Identified Mail (RFC 6376). The pillar page covering DKIM end-to-end: signatures, the eight tag-by-tag record reference, key rotation, replay considerations, examples. Read first if you are new to DKIM.
• DKIM canonicalization — the byte-level reference covering the four RFC 6376 §3.4 canonicalization combinations (simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed) declared by the c= tag. The selector is one half of the (selector, canonicalization) DKIM-Signature configuration; both are needed to verify a signature.
• DKIM signatures explained — the DKIM-Signature header byte-layout sibling whose s= tag THIS page documents — the DKIM-cluster sibling that documents the full DKIM-Signature header byte-layout in which the s= selector tag this page describes is one of fourteen tags (v, a, b, bh, c, d, h, i, l, q, s, t, x, z). Where THIS page documents the s=<selector> tag's eight naming conventions, the per-provider selector catalogue (Microsoft 365's selector1 / selector2, Google Workspace's google, cPanel's default, SendGrid's s1 / s2, etc.), the dual-selector rotation pattern, and the seven selector-publication failure modes, the signatures-explained spoke documents the LARGER container the s= tag lives in — the DKIM-Signature header itself, the tag-grammar per RFC 6376 §3.5 that the s= tag obeys, the operationally-load-bearing interaction between s= and the d= signing-domain tag (together they form the DNS lookup target <s>._domainkey.<d> the verifier resolves to fetch the public key), and the position of s= in the canonical operator-published tag order (v=1; a=...; c=...; d=...; s=...; h=...; bh=...; b=...). Read the signatures-explained spoke when an operator asks "where exactly in the DKIM-Signature header does the s= tag live, and what other tags interact with the selector choice" — the spoke is the authoritative DKIM-Signature-header byte-layout sibling of the selector-publication deep dive on this page. Closes the DKIM-cluster sibling-orphan parity gap between dkim_selectors_explained (the s=-tag selector reference) and dkim_signatures_explained (the DKIM-Signature-header byte-layout reference).
• DKIM key rotation — operational deep dive on DKIM key rotation defined by RFC 6376 and updated by RFC 8301. The dual-selector rotation pattern documented in section 8 of this page is the protocol primitive underlying the full rotation playbook.
• DKIM cryptography basics — the RSA / Ed25519 / SHA-256 signing-math deep dive. The selector is the DNS-discoverable public key; cryptography_basics covers the signing math that uses the key.
• DKIM best practices — the DKIM-SELECTOR-NAMESPACE-PRIMITIVE- CONSUMER-OF-DKIM-KEY-CRYPTOGRAPHY-AND- SIGNING-HYGIENE-OPERATOR-REFERENCE companion reference. Where THIS page documents the DKIM selector-namespace primitive (<selector>._domainkey.<domain> TXT-record namespace + per-provider canonical selector names + per-rotation dual-selector overlap mechanics), the dkim_best_practices spoke is the OPERATOR-HYGIENE INVARIANT canonical reference defining the per-selector lifecycle disciplines the selector- namespace primitive on THIS page operationalizes. FOUR structurally- distinct DKIM-SELECTOR-NAMESPACE- BEST-PRACTICES-CONSUMER dimensions the operator-hygiene spoke defines that this selector-namespace primitive page structurally consumes: (i) per-selector RFC 8301 2048-bit RSA key-size discipline AS THE PER- SELECTOR p=-tag publication invariant the selector- namespace primitive operationalizes per-selector — the dkim_best_practices spoke documents the RFC 8301 2048-bit RSA floor as the per-selector publication invariant (the per-selector p=<base64>-tag MUST encode ≥2048-bit RSA SubjectPublic KeyInfo to survive cross-receiver weak- key-deprecation pressure documented in the operator-hygiene spoke); the per-selector key-size invariant the selector-namespace primitive on THIS page operationalizes IS the per- selector publication invariant the operator-hygiene reference defines — every selector this page catalogues (M365 selector1/selector2, Workspace google, cPanel default, SendGrid s1/s2) MUST publish the 2048-bit-RSA floor at the per-selector publication level; (ii) per-selector RFC 6376 §3.6.1 k=/h= signing-algorithm discipline AS THE PER-SELECTOR algorithm-tag publication invariant the selector-namespace primitive operationalizes per- selector — the dkim_best_practices spoke documents the cross-selector algorithm-tag discipline (per-selector k=rsa + h=sha256 as the receiver-canonical default; per- selector k=ed25519 per RFC 8463 as the next-generation alternative requiring per-receiver verifier-support assessment); the per-selector algorithm-tag the selector-namespace primitive on THIS page operationalizes IS the per- selector algorithm publication invariant the operator-hygiene reference defines (when authoring a new selector per the namespace- primitive procedures on THIS page, the operator inherits the algorithm- tag discipline the operator-hygiene spoke catalogues); (iii) per- selector custody-isolation discipline AS THE SELECTOR-NAMESPACE INVARIANT forbidding selector-reuse across operator-distinct signers — the dkim_best_practices spoke documents the cross-signer custody- isolation discipline (one selector per signer-infrastructure instance; no selector-reuse across operator- distinct signers; selector-retirement- on-no-traffic discipline); the selector-namespace primitive on THIS page operationalizes this invariant at the namespace level (the per- provider selector catalogue THIS page enumerates explicitly NAMES the per- signer selectors that MUST remain custody-distinct across the multi- signer organisational domain — M365's selector1 ≠ Workspace's google ≠ SendGrid's s1 ≠ cPanel's default); (iv) per-selector RFC 6376 §3.6.1 overlap-window rotation discipline AS THE DUAL-SELECTOR ROTATION PROCEDURE the selector- namespace primitive on THIS page documents at the procedure level — the dkim_best_practices spoke documents the per-rotation overlap-window discipline (publish new selector ≥7 days before retiring the old; per-rotation per-receiver DKIM-pass- rate monitoring; per-rotation t=y-tag-emission discipline for test-mode validation); the dual-selector rotation procedure the selector-namespace primitive on THIS page documents (section 8: the dual-selector publishing-window / cutover-window / retirement-window sequence) IS the operational instantiation of the operator- hygiene spoke's overlap-window discipline at the per-selector namespace level. Read the dkim_best_practices spoke alongside this selector-namespace primitive page when authoring a cross-provider DKIM-deployment posture — the operator-hygiene spoke is the cross-selector invariant reference; the selector-namespace primitive on THIS page is the per-selector operational reference. Every per- provider selector this page catalogues MUST inherit the four operator-hygiene invariants the dkim_best_practices spoke defines.
• DKIM DNS record syntax (TXT-record byte reference) — the byte-by-byte reference for the TXT record this selector page resolves to. Where THIS page documents the s=<selector> tag, its naming conventions, the per-provider selector catalogue, and the dual-selector rotation procedure, the DNS-syntax page documents the byte-level rules for the TXT record published at <selector>._domainkey.<d-domain> — the actual record receivers fetch when the signature header points them at a selector: the v=DKIM1 version-tag floor, the k=rsa / k=ed25519 algorithm tag (RFC 8463 added Ed25519 in 2018), the p=<base64-public-key> tag carrying the DER-encoded SubjectPublicKeyInfo (or p= empty as the official key-revocation signal per RFC 6376 §3.6.1), the optional t=y testing-mode flag and t=s strict-alignment flag, the g= granularity tag (deprecated in RFC 6376 but still seen in legacy records), the h= hash-algorithm restriction tag, the n= notes tag for operator comments, the s=* service-type-wildcard tag, the 2048-bit-floor encoding constraint with the split-string TXT-record concatenation rule (DNS UDP limits each TXT string to 255 bytes; 2048-bit RSA public keys exceed that and must be split across multiple quoted strings that the resolver concatenates — Cloudflare auto-splits, GoDaddy requires manual chunking, BIND requires the ("..." "...") concatenation form), and the canonical examples for a freshly-generated selector record. Read this once you have chosen a selector name from the catalogue above and need the byte-level reference for the actual TXT record you publish at the <selector>._domainkey label.
• DKIM replay attacks — the capture-and-rebroadcast attack class and the RFC 9103 x= expiration tag. Replay defence does not depend on selector design directly, but per-purpose selector isolation reduces the blast radius of a compromised key.
• DKIM troubleshooting — the symptom-driven debugging companion that most often resolves to a selector-configuration issue. The canonical selector-related DKIM failure modes — DNS lookup for <selector>._domainkey.<d-domain> returns NXDOMAIN (wrong selector name in the DKIM-Signature header, or selector record never published / accidentally deleted), TXT record present but wrong (split-string concatenation broke the 2048-bit public key at the registrar, or a copy-paste error introduced whitespace), provider auto-rotated the selector and the sender is still signing with the previous one (M365 dual-selector rotation midpoint, Workspace new-record-generated-but-old-record-active burn-in), CNAME chase that doesn't resolve to a TXT record (M365 CNAME-delegated DKIM where the tenant DNS has the CNAME but Microsoft hasn't published the target TXT yet) — all map to specific symptom paths in the troubleshooting page. Read this when the selector configuration documented in this page is in place but receivers report dkim=permerror (no key found) or dkim=fail (wrong key found).
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-DUAL-SELECTOR- CNAME-DELEGATED-DEPLOYMENT-AS-SELECTOR- NAMESPACE-PRIMITIVE-CONSUMER companion to this DKIM selector-namespace pillar. Where THIS page documents the selector-naming-convention contract (the <selector>._domainkey.<d- domain> DNS-label format, the per-provider selector-naming catalogue with M365's selector1 / selector2 alongside Workspace's google + provider-specific defaults, the per- purpose selector-isolation discipline, the multi-selector overlap-window rotation pattern) — i.e. the DKIM- SELECTOR-NAMESPACE-PRIMITIVE side of the DKIM-protocol-protocol-layer — the M365- DKIM spoke is the M365-TENANT-SPECIFIC- SELECTOR-DEPLOYMENT-CONSUMER companion documenting the structural concrete deployment topology a Microsoft 365 tenant induces against the selector- namespace primitive THIS page documents. Concretely, the spoke documents FOUR M365-DKIM-selector-deployment-consumer dimensions: (i) the M365 tenant publishes the dual-selector selector1._domainkey + selector2._domainkey CNAME records at the customer-vanity-domain DNS zone — the M365-tenant operator publishes two <selector>._domainkey.<d- domain> DNS-label entries exactly per the selector-naming- convention THIS page documents, where the <d-domain> is the customer-vanity-domain and the <selector> is the M365-tenant-specific selector1 / selector2 pair, structurally consuming the selector-namespace primitive THIS page documents; (ii) the M365 tenant DKIM record is a CNAME pointing to the Microsoft-managed target zone rather than a TXT record published directly at the customer-vanity-domain DNS zone — the M365-tenant operator's CNAME targets selector1-<tenant>._ domainkey.<tenant>.onmicrosoft.com (and the parallel selector2 target) where Microsoft publishes the authoritative TXT record with the v=DKIM1; k=rsa; p=<public- key> record body, an operationally-distinct DKIM-key- publication topology from the provider-publishes-TXT-directly-at- customer-domain pattern THIS page documents as the baseline; (iii) the Microsoft-managed dual- selector rotation cadence operates on the selector pair the M365 tenant publishes — Microsoft rotates the active signing selector between selector1 and selector2 on a managed cadence (typically several months), and the M365-tenant operator does NOT manually rotate selectors per the overlap-window discipline THIS page documents but instead observes the Microsoft-managed rotation through the s= tag in outbound DKIM- Signature headers — a managed-rotation consumption of the operator-controlled overlap-window rotation pattern; and (iv) the M365 spoke documents the selector-deployment-troubleshooting playbook specific to the M365 dual- selector CNAME-delegated topology — common failure modes (CNAME published but Microsoft-managed target TXT not yet provisioned causing dkim= permerror, customer-vanity-domain DNS provider stripping the CNAME query causing CNAME-chase failure, M365 tenant-rename de-coupling the existing selector CNAMEs from the new tenant backing) all map to specific symptom paths in the M365 spoke, which read AGAINST the canonical selector- troubleshooting decision tree THIS page documents. Read the DKIM-for-Microsoft- 365 spoke alongside this DKIM-selectors pillar when designing or troubleshooting DKIM selector deployment on an M365- hosted publishing domain — the M365- tenant-specific dual-selector CNAME- delegated topology the spoke documents is the load-bearing selector-deployment consumer-role whose Microsoft-managed rotation cadence and CNAME-delegation topology directly operationalize the selector-namespace primitive THIS page documents.
• DKIM for Google Workspace — the WORKSPACE-TENANT-DKIM-SINGLE- SELECTOR-OPERATOR-PUBLISHED-TXT-RECORD- DEPLOYMENT-AS-SELECTOR-NAMESPACE- PRIMITIVE-CONSUMER companion to this DKIM selector-namespace pillar. Where THIS page documents the selector- naming-convention contract (the <selector>._domainkey.<d- domain> DNS-label format, the per-provider selector-naming catalogue, the per-purpose selector-isolation discipline, the multi-selector overlap- window rotation pattern) — i.e. the DKIM-SELECTOR-NAMESPACE-PRIMITIVE side of the DKIM-protocol-protocol-layer — the Workspace-DKIM spoke is the WORKSPACE-TENANT-SPECIFIC-SELECTOR- DEPLOYMENT-CONSUMER companion documenting the structural concrete deployment topology a Google Workspace tenant induces against the selector- namespace primitive THIS page documents, STRUCTURALLY DIFFERENT from the M365 dual-selector CNAME-delegated topology the sibling M365-DKIM spoke documents. Concretely, the spoke documents FOUR Workspace-DKIM-selector-deployment- consumer dimensions: (i) the Workspace tenant publishes a SINGLE google._domainkey (or operator-chosen custom selector name) TXT record at the customer-vanity- domain DNS zone — the Workspace-tenant operator publishes ONE <selector>._domainkey. <d-domain> DNS-label entry exactly per the selector-naming- convention THIS page documents, STRUCTURALLY SIMPLER than the M365 dual-selector pair the sibling M365- DKIM spoke documents — Workspace uses ONE selector at a time, with the Admin-Console-driven rotation moving the active selector forward sequentially rather than alternating between two pre-published selectors; (ii) the Workspace tenant DKIM record is a TXT record published DIRECTLY at the customer-vanity-domain DNS zone with operator-controlled key material, rather than a CNAME pointing to a provider-managed target zone — the Workspace-tenant operator publishes the actual v=DKIM1; k=rsa; p=<public- key> record body at the customer-vanity-domain DNS zone with the Workspace-Admin-Console-generated 2048-bit public key directly in the TXT record, an operationally-distinct DKIM-key-publication topology from the provider-managed CNAME-delegated target-zone pattern the M365-DKIM spoke documents; (iii) the operator-controlled single-selector manual rotation cadence operates on the Workspace-published selector namespace — the Workspace- tenant operator manually rotates the active signing selector through the Workspace Admin Console workflow (typically 6-12 month cadence per operator hygiene discipline), AND manually coordinates the per-selector overlap-window pattern THIS page documents (publish new selector TXT record, wait for DNS propagation, switch active selector in Admin Console, retain old selector TXT record for the overlap-window-duration receiver-side cache TTL) — an operator-controlled rotation consumption of the per-selector overlap-window rotation pattern THIS page documents; and (iv) the Workspace spoke documents the selector-deployment-troubleshooting playbook specific to the Workspace single-selector TXT-published topology — common failure modes (Workspace Admin Console generates new key but operator forgets to publish the TXT record at the customer-vanity-domain DNS zone causing dkim=permerror, registrar-side TXT-record split-string concatenation breaking the 2048-bit public key, Workspace-Admin-Console- side selector-rotation midpoint window where the new-record-generated-but- old-record-active state requires the operator to manually retain the old TXT record for the overlap-window- duration) all map to specific symptom paths in the Workspace spoke, which read AGAINST the canonical selector- troubleshooting decision tree THIS page documents. Read the DKIM-for- Google-Workspace spoke alongside this DKIM-selectors pillar when designing or troubleshooting DKIM selector deployment on a Workspace-hosted publishing domain — the Workspace- tenant-specific single-selector operator-published TXT-record topology the spoke documents is the load-bearing selector-deployment consumer-role whose operator-managed rotation cadence and TXT-publication topology directly operationalize the selector-namespace primitive THIS page documents.
• DMARC for cPanel & shared hosting (deployment guide) — the OPERATOR'S DEPLOYMENT EXAMPLE for the default._domainkey selector convention this page catalogues among the eight canonical naming patterns. Where this page enumerates selector-naming conventions abstractly (date / sequence / hash / purpose / tenant / environment / version / opaque), the cPanel deployment guide is the concrete operator-facing reference for the Exim-based shared-hosting class where cPanel auto-generates a single default._domainkey selector at account creation (the cPanel convention, distinct from Workspace's google._domainkey and M365's dual-selector selector1 / selector2 CNAME model documented above). The cPanel guide documents the WHM Exim DKIM signing configuration (server-wide vs per-account signer), the Email Deliverability page's Install Suggested Record flow (cPanel's end-user UI for republishing the default selector when the public key drifts from the published TXT), the rotation gotchas under cPanel's single-selector convention (no dual-selector overlap window unless WHM admin manually intervenes — a structural rotation-discipline regression vs the dual-selector pattern documented in section 8 above), the per-account vs server-wide key sharing implications (every domain on the same Exim signer shares the same default private key by default — a multi-tenant cross-domain reputation risk distinct from the per-tenant signer isolation in Workspace and M365), the provider-managed SPF-include patterns the same operators couple with DKIM (include:_spf.bluehost.com, include:_spf.hostgator.com, include:_spf.siteground.net, etc.), and the Feb 2024 Gmail/Yahoo bulk- sender requirement compliance procedure on shared-IP cPanel hosting. Read this page (the abstract selector reference) with the cPanel deployment guide (the operator-facing per-provider example) when standing up DKIM on an Exim/cPanel/WHM-based shared-hosting stack — particularly when migrating from the multi-vendor dual-selector pattern documented in section 7 above to or from the cPanel single-selector convention.
• DMARC for transactional email — the PER-TRANSACTIONAL-ESP companion cataloguing how the eight canonical transactional-ESP platforms each impose a platform-specific selector-naming convention at the customer-vanity-domain DNS zone the tenant publishes: SendGrid publishes s1._domainkey + s2._domainkey CNAME records delegating to s1.domainkey.uXXXXX.wlYYY.sendgrid.net (CNAME-delegated dual-selector pattern); Mailgun publishes mailo._domainkey (legacy) or k1._domainkey (current) TXT record published directly at the customer-domain zone (operator- published direct-TXT pattern); Postmark publishes YYYYMMDDdd._domainkey with a date-stamped per-account selector and CNAME-delegated target; Amazon SES publishes three CNAME records <token1>._domainkey + <token2>._domainkey + <token3>._domainkey delegating to <token>.dkim.amazonses.com (per-region per-identity triple-CNAME rotation pattern); SparkPost / Mailjet / Mandrill / Resend publish similar per-platform-specific CNAME-delegated or direct-TXT selectors whose per-ESP naming-namespace divergence the per-tenant DNS-zone publication discipline must reconcile. The transactional-email spoke documents the per-ESP selector-rotation-window coordination (per-ESP-managed rotation cadence vs per-tenant-managed rotation cadence), the per-ESP selector-namespace- conflict-detection discipline (a tenant running two transactional ESPs simultaneously must verify the per-ESP-suggested selector tokens do not collide), and the per-ESP-vs- per-tenant d=<ESP-domain> vs d=<customer-domain> signing-identity choice whose alignment- outcome determines whether the per-message DMARC verdict resolves to dkim=pass aligned. Read the transactional-email spoke alongside this DKIM-selector reference when provisioning a new ESP, when migrating between ESPs, when consolidating two ESPs' selector publication onto a single customer-domain zone, or when decoding per-message auth_results/dkim/selector values to attribute aggregate-report rows to specific ESP-platform tenant accounts.
• DMARC alignment explained — the identifier-alignment deep dive (strict vs relaxed for both adkim and aspf). DKIM alignment binds the d= domain (which selectors are scoped under) to the From: header organisational domain.
• DMARC record tags explained — the DMARC tag-by-tag reference (p, sp, np, pct, rua, ruf, adkim, aspf, fo, ri, rf).
• DMARC myths & misconceptions — the SELECTOR-ROTATION-AS-WIDESPREAD- DMARC-MISCONCEPTION-DEBUNK-REFERENCE companion. Where THIS page is the DKIM-selector-namespace publication reference (the <selector>._domainkey.<d> naming primitive, the eight per-provider canonical-selector catalogues, the dual-selector overlap-window rotation cadence, and the seven common selector failure modes), the dmarc_myths_and_misconceptions spoke is the DEBUNK CATALOGUE that documents the per-myth correction of FOUR structurally-distinct DKIM-selector-related DMARC misconceptions the operator-author MUST unlearn before authoring per-selector publication: (i) the "rotating DKIM selectors invalidates DMARC" myth (selector rotation is the canonical operator-hygiene primitive, NOT an anti-pattern); (ii) the "wildcard *._domainkey selector" myth (wildcards are explicitly excluded from the RFC 6376 selector grammar); (iii) the "missing selector produces DMARC permerror" myth (the DMARC composite verdict downgrades to DKIM-fail, NOT a permerror); (iv) the "single selector is enough" myth (single-selector deployments cannot execute the dual-selector zero-downtime rotation pattern this page documents at section 8). Read the dmarc_myths_and_misconceptions spoke ALONGSIDE this selector-publication reference to inoculate the operator against the four canonical selector- misconception classes BEFORE publishing per-selector records.
• DMARC reporting pipeline — the DKIM-SELECTOR-AS-FAILURE- DISAMBIGUATION-INPUT-TO-RUA-INGESTION companion documenting how the selector publication mechanics THIS page catalogues become the disambiguation primary-key dimension fed into the receiver-generated RUA aggregate-report ingestion pipeline at the operator side. Where THIS page documents the selector PUBLICATION mechanics (the eight naming conventions, the per-provider catalogue, the dual- selector rotation pattern, the v=DKIM1; k=rsa; p=<public-key> TXT-record byte layout, and the seven selector-publication failure modes), the reporting-pipeline spoke documents the end-to-end transport-and-ingestion path — receiver-side report-generator → DNS resolution of the publisher's rua= URI → MIME-attached SMTP / HTTPS delivery → operator-side inbound mailbox / webhook → MIME-part extraction → gzip-or-zip decompression → XML schema-validation → row-by-row ingestion into the analyzer's dmarc_records table — that turns every per-selector DKIM authentication-result into a queryable per-(selector, source-IP, day) RUA row the operator can join against the selector catalogue this page maintains. The selector is the FAILURE- DISAMBIGUATION PRIMARY KEY that the ingestion pipeline carries from the receiver-side DKIM verifier (which stamps the per-message Authentication-Results header with dkim=pass header.d=<d> header.s=<selector> or the corresponding fail-class verdict) through the aggregate-report aggregator (which groups per-message verdicts by the (selector, source-IP, disposition) tuple into a per-day count) into the operator-side RUA XML row whose <auth_results><dkim><selector> sub-element preserves the selector identity end-to-end. Without selector identity carried through the ingestion pipeline, the operator cannot tell from the aggregate report which of the eight-naming-convention selectors this page documents (date / sequence / hash / purpose / tenant / environment / version / opaque) is the one rotating-out prematurely, which of the per-provider selectors (M365 selector1 / selector2, Workspace google, cPanel default, SendGrid s1 / s2) is misconfigured, which of the dual-selector rotation pattern's OLD / NEW pair has the publication drift, or which of the seven selector-publication failure modes (NXDOMAIN, split-string truncation, CNAME-chase failure, copy-paste drift, 2048-bit overflow, etc.) is producing the receiver-side dkim=permerror / dkim=temperror / dkim=fail stamps. Read the reporting-pipeline spoke alongside this selector reference to understand the end-to-end carrier of selector identity from the receiver-side DKIM verifier to the operator-side per-day aggregate-row — the pipeline is the OBSERVATION-INFRASTRUCTURE that makes the selector-publication mechanics documented on this page operationally- diagnosable at scale. Closes the DKIM-cluster ↔ DMARC-reporting-pipeline bridge whereby the per-selector signature-failure-rate signal the operator surfaces from RUA records is the END-CONSUMER of every selector- publication mechanic this page documents.
• DMARC aggregate (RUA) reports — the PER-MESSAGE-DKIM-SELECTOR-AS- PER-ROW-AUTH_RESULTS-EVIDENCE-DIMENSION companion to this DKIM-selector publication reference. Where THIS page documents the per-publisher per-domain DKIM selector publication discipline (the <selector>._domainkey.<d-domain> TXT record naming convention, the rotation discipline pairing two live selectors, the per-selector key- material publication, and the per- message s= tag-value emission that points the receiver-side resolver at the public-key TXT record), the DMARC-aggregate-reports spoke documents the RFC 7489 §7.2 XML schema at four per-selector-publication-to- per-row-auth_results-evidence coupling dimensions: (i) per-row <auth_results><dkim><selector> child as direct per-row materialisation of the per-message s= tag — the RFC 7489 §7.2.1.5 auth_results element carries a per-row <dkim> child with <domain>, <selector>, and <result> sub-elements — the <selector> sub-element IS the wire-format echo of the per-message s=<selector> tag THIS page documents the publication discipline of; (ii) per-selector DKIM-aligned-pass-rate as RUA-aggregated per-row evidence dimension — the per-publisher per-domain per- selector DKIM-aligned-pass-rate baseline the operator monitors during a DMARC rollout from p=none → p=quarantine → p=reject is computed by aggregating per-row policy_evaluated.dkim=pass counts GROUPED BY the per-row auth_results.dkim.selector — the per-selector publication discipline THIS page documents is the primary-key dimension along which the per-row aggregate-report evidence partitions for rollout-gate evaluation; (iii) per-selector rotation boundary observability via per-selector per-day per-row count divergence — the dual-selector rotation discipline THIS page documents (active selector s=selector1, standby selector s=selector2, atomic cutover via per-message s= tag-value transition) is observable at the per-tenant DMARC RUA-aggregate-report stream as a per-day per-selector per-row count divergence (pre-cutover: 100% s=selector1 rows; post-cutover: 100% s=selector2 rows; the boundary day exhibits the cutover ratio) — the per-row auth_results.dkim.selector evidence the DMARC-aggregate-reports spoke documents is the observability surface for the rotation procedure THIS page documents the operational discipline of; (iv) per-selector per-receiver per-row evidence as cross-receiver selector-coverage audit dimension — the per-tenant DKIM-selector publication discipline THIS page documents produces per-message DKIM signatures that may resolve differently at different receiver-side recursive resolvers (NXDOMAIN at one receiver, valid TXT at another due to DNS propagation lag); the per-receiver per-row aggregate-report stream the DMARC-aggregate-reports spoke documents is the cross-receiver per-selector per-row coverage audit dimension that surfaces propagation-defect attribution per-receiver per-selector. Read the DMARC-aggregate-reports spoke alongside this DKIM-selector publication reference when the operator is designing the per-tenant per-selector publication + rotation discipline whose downstream empirical evidence stream lives in the RFC 7489 §7.2 XML report rows the DMARC-aggregate-reports spoke documents the byte-by-byte schema of.
• DMARC multi-domain strategy — the PER-DOMAIN-DKIM-SELECTOR-NAMESPACE- AT-PORTFOLIO-SCALE companion documenting the structurally-distinct portfolio-level selector-authoring challenge that emerges when a single org publishes DKIM keys across many portfolio domains (primary brand, secondary brands, parked domains, legacy-acquisition domains, redirector domains, sub-brand SaaS domains) and each portfolio domain inherits its own independent <selector>._domainkey.<d-domain> namespace but the org's portfolio-wide DKIM-key-rotation discipline must coordinate selector-naming, key-rotation cadence, and dual-selector overlap windows across every brand. Where THIS page enumerates the eight canonical selector-naming patterns abstractly (date / sequence / hash / purpose / tenant / vendor / brand / multi-selector) and the multi-selector concurrent-key publication mechanics for a single domain, the multi-domain-strategy spoke is the PORTFOLIO-COMPOSITION-AND-COORDINATION companion documenting how the operator structures the org-wide DKIM selector posture across N portfolio domains: (i) PER-BRAND-SELECTOR-NAMING-CONVENTION (each portfolio domain SHOULD use a brand-specific selector prefix — e.g. brand1-202601._domainkey.brand1.example, brand2-202601._domainkey.brand2.example — so that even when the operator coordinates rotation simultaneously the per-brand selector namespaces remain independent and rotation-window incidents on one brand do not impair signing on sibling brands), (ii) PER-BRAND-KEY-ROTATION-CADENCE coordination (when the org performs portfolio-wide rotation the operator must coordinate the OLD-and-NEW dual-selector overlap window across all portfolio siblings simultaneously so that signers on every brand can transition in lockstep without inadvertently leaving one portfolio sibling on the previous selector while another has moved to the new one, exposing the lagging brand to a signing-key-mismatch dkim=permerror failure mode), (iii) PER-SHARED-SIGNING-INFRASTRUCTURE selector allocation (when the org uses a shared transactional-mail signing service — Postmark, Mailgun, SES, SendGrid — across multiple portfolio brands, the per-brand selector convention plus the vendor's tenant-isolation guarantees determine whether the brand-portfolio's DKIM signatures remain cryptographically-distinct across brands or get cross-contaminated via shared signing-key reuse), (iv) PARKED-DOMAIN-NULL-DKIM-PUBLICATION portfolio-default posture (the canonical *._domainkey.parked-domain.example wildcard v=DKIM1; p= empty-key publication establishes the "no legitimate DKIM signature for this portfolio sibling — every dkim=pass row is forged" auditable assertion for the portfolio-default posture across every non-sending sibling). Read the multi-domain-strategy spoke alongside this selector reference when scoping the portfolio-level DKIM authoring posture — the per-domain selector mechanics documented here become the BUILDING-BLOCK repeated across every portfolio sibling, and the multi-domain-strategy spoke provides the PORTFOLIO-WIDE-SELECTOR-NAMESPACE- AND-ROTATION-CADENCE meta-discipline preventing portfolio-sibling selector collision, rotation-window misalignment, and parked-sibling DKIM-publication drift.
• SPF explained — Sender Policy Framework (RFC 7208). The IP-authorisation layer; complements DKIMs cryptographic signing.
• SPF mechanisms explained — the canonical SPF mechanism / qualifier / modifier reference. Sibling to this page in the SPF + DKIM mechanism-vocabulary cluster.
• include vs ip4 vs a vs mx — the SPF-FOUR-MECHANISM-DECISION-VS- DKIM-SELECTOR-NAMESPACE companion to this DKIM-selector publication-discipline reference. Where THIS page documents the per-publisher per-domain DKIM selector- namespace primitive (per-selector <selector>._domainkey.<d> publication discipline whose per-selector p=-tag RSA-2048 / Ed25519 public-key publication is the cryptographic- trust-material lookup substrate receivers resolve at per-message DKIM verification time), the include-vs-ip4-vs-a-vs-mx four-mechanism decision-view spoke documents the per-publisher per-domain SPF authorization-set-derivation discipline whose receiver-side lookup algorithm is structurally parallel to the DKIM selector-namespace receiver-side lookup algorithm at FOUR coupling dimensions: (i) the receiver-side lookup-locus decision — the SPF evaluator chooses between four authorization-set lookup loci (include:<vendor> delegates to a vendor-managed SPF record at a separate DNS zone; ip4:<cidr> inlines the literal authorised CIDR at the publisher's own SPF record; a[:<domain>] looks up the A/AAAA RR-set of the named domain; mx[:<domain>] looks up the MX RR-set then resolves each MX target's A/AAAA), structurally parallel to the DKIM evaluator's per-selector <selector>._domainkey lookup-locus decision (per-selector publication at the customer-domain DNS zone via direct TXT-RR vs CNAME-delegated to a vendor-managed zone vs per-tenant custody isolation per selector); (ii) the 10-DNS-lookup permerror cliff coupling — RFC 7208 §4.6.4 caps SPF evaluation at 10 DNS lookups; include + a + mx each consume from the budget, while ip4 is FREE (zero lookups); the per-publisher per-domain decision to prefer ip4:<cidr> literals over include: / a: / mx: tokens is the canonical lookup-budget preservation discipline — structurally parallel to the DKIM per-selector publication discipline where the per-selector custody-isolation choice (CNAME-delegated to vendor selector vs direct TXT-RR publication at customer- domain zone) governs the per-selector cryptographic-trust-material custody- boundary the receiver resolves at verification time; (iii) the delegation-vs-direct-publication topology coupling — include:<vendor> delegates SPF authorization-set publication to the vendor-managed zone (the vendor updates their SPF record; the publisher's record inherits the change at next receiver-side cache eviction) structurally parallel to the DKIM CNAME-delegated selector pattern (the publisher CNAMEs selector1._domainkey.<publisher> to selector1-<tenant>._domainkey.<vendor>; the vendor manages key rotation; the publisher's TXT lookup inherits the rotated key at next receiver-side cache eviction); (iv) the per-publisher per-domain authorization-pillar composition coupling — the SPF four-mechanism decision is one of two per-publisher per-domain authorization- pillar primitives (SPF authorises by IP address; DKIM authorises by cryptographic signature attached to per-message d= identity); receivers compute the per-message DMARC verdict as the OR of SPF-aligned-pass and DKIM-aligned-pass per RFC 7489 §3.1, so the per-publisher per-domain choice between SPF authorization-mechanism topology and DKIM selector-namespace topology is jointly load-bearing for per-message DMARC-aligned-pass rate at every receiver. Pair this decision-view spoke with the selector-publication discipline THIS page documents when designing the per-publisher per-domain authentication-pillar topology — the DKIM selector namespace governs the cryptographic-signature authorization pillar's trust-material lookup, while the SPF four-mechanism decision view governs the IP-address authorization pillar's authorization-set lookup, two structurally-parallel receiver-side- lookup-decisions whose per-publisher per-domain choices compose at the per- message DMARC-aligned-pass-rate boundary.
• SPF lookup limit explained — RFC 7208 §4.6.4 10-DNS-lookup limit. Multi- vendor deployments often rely on DKIM alignment more than SPF because DKIM has no lookup-limit problem; the multi-selector pattern in section 7 is the canonical multi-vendor pattern.
• DNS propagation — cache-behaviour mechanics for new and modified DNS records. Relevant to selector publication (the rotation step 4 wait-for- propagation).
• Email authentication ecosystem — the cluster-intro pillar surveying SPF + DKIM + DMARC + BIMI + MTA-STS + TLS-RPT + CAA + ARC interlocking.
• Email authentication glossary — the term-of-art reference covering selector, signing domain, _domainkey, s= tag, d= tag, p= tag, public key, private key, and every other vocabulary item this page uses.
• DKIM failures explained — the SELECTOR-PUBLICATION-DRIFT-AS-FAILURE-ROOT-CAUSE companion to this selector reference — the SELECTOR-PUBLICATION-DRIFT-AS-FAILURE- ROOT-CAUSE companion documenting how the selector publication mechanics THIS page documents map directly onto the receiver- side DKIM-failure diagnostic taxonomy. Where THIS page documents the selector PUBLICATION mechanics (the selector._domainkey.<d> TXT record naming convention, the v=DKIM1; k=rsa; p=... tag list, the 255-byte string-chunking rule that forces RFC 1035 §3.3.14 quoted-string concatenation for keys above 2048 bits, the CNAME-delegation pattern Microsoft 365 and SaaS platforms use for tenant-managed signing), the failures spoke catalogues the receiver-side Authentication-Results stamp signature each selector-publication mistake produces: dkim=permerror (selector TXT record doesn't decode — RSA key bytes truncated by accidental single-string TXT publication, base64-chunk boundary mid-byte, or copy-paste byte loss), dkim=temperror (selector published with a CNAME instead of TXT and DNS resolver doesn't follow the chain, or the CNAME target's TXT record hasn't yet propagated to the receiver's recursive resolver), dkim=fail signature-verify (signer is using selector s2 while the published TXT still has the s1 key — a transposition that happens when the per-tenant CNAME delegation publishes the wrong target), and dkim=neutral no-signature (selector was removed before the signer was reconfigured, leaving signed in-flight mail without a verifiable selector record). Read THIS selector-publication page WITH the failures reference when troubleshooting a freshly-deployed selector — the failures spoke names the four diagnostic signatures whose Authentication- Results stamps in receiver RUA aggregate reports localise the publication mistake to a specific selector mechanic this page documents.
• Email spoofing — the SELECTOR-ROTATION-AS-COMPROMISED-KEY- SPOOFING-CONTAINMENT-LAYER companion to this selector-DNS-anatomy deep dive. Where THIS page documents the <selector>._domainkey.<domain> DNS-name binding the public key the receiver's DKIM verifier fetches against the s=<selector> tag in the DKIM-Signature header (RFC 6376 §3.6.1 the selector TXT record format, v=DKIM1; k=rsa; p=<base64-key> publication, the multi-selector parallel- publication / atomic-cutover / staged deprecation lifecycle the operator orchestrates on DNS-propagation timescales), the email- spoofing spoke is the ATTACKER-PERSPECTIVE companion documenting the COMPROMISED-KEY- SPOOFING attack class against which the selector-rotation discipline is the SOLE STRUCTURAL CONTAINMENT LAYER: (i) the attack vector — an attacker exfiltrates the publisher's DKIM private key from an insufficiently-protected signing host (an unprotected MTA configuration file, a misconfigured key-management vault, a compromised CI/CD secret store, a leaked backup tarball) and uses it to sign arbitrary messages with the publisher's d= identity from attacker- controlled infrastructure (residential proxies, freshly-rented VPSes, free-tier cloud instances) — every such message passes DKIM verification at the receiver because the publisher's TXT-published public key successfully verifies the attacker's signed messages, and every such message passes DMARC alignment because the attacker uses the publisher's d= in alignment with the forged From:; (ii) the DKIM protocol has NO REVOCATION mechanism analogous to TLS certificate CRLs or OCSP — the only way to invalidate a compromised DKIM key is to either DELETE the selector TXT record (which immediately breaks LEGITIMATE outbound DKIM signing on the affected selector across ALL of the publisher's mail flow) or to PUBLISH a NULL key (v=DKIM1; p=;) which is the RFC-6376-§3.6.1 explicit signal "this selector is revoked"; (iii) the operational containment discipline — a publisher operating selector- rotation on a fixed cadence (quarterly / semi-annually / annually) STRUCTURALLY BOUNDS the maximum attack-window duration from key-compromise to key-revocation, AND positions the publisher to execute emergency-rotation atomically (mint new selector, publish new key, switch outbound signing in minutes, null-publish old key, invalidate all attacker-held key material across all receivers within DNS-propagation latency); (iv) at publishers without rotation discipline, a compromised DKIM key may remain attacker- usable for the entire remaining lifetime of the publisher's domain — attacker-signed messages continue passing DKIM verification and DMARC alignment at every receiver until the publisher eventually rotates or null-publishes the compromised selector, which without established rotation discipline typically does NOT happen until a security incident forces it. Read the email-spoofing catalogue when authoring the DKIM-selector- rotation operational rationale — selector rotation is not just a key-hygiene best practice, it is the SOLE STRUCTURAL CONTAINMENT for the compromised-key spoofing attack class against which DMARC / SPF / receiver-side anti-spoofing heuristics provide ZERO defense (the attacker's signed messages pass every authentication check by construction).
• Why SPF alone is insufficient — the DKIM-SELECTOR-PUBLICATION-AS-PER- MESSAGE-CRYPTOGRAPHIC-DEFENSE-FILLING-FOUR- STRUCTURAL-SPF-ENVELOPE-LAYER-FAILURE-MODES companion to this DKIM-selector-publication reference. Where THIS page documents the s=<selector> tag's eight naming conventions + the per-provider selector catalogue + the dual-selector rotation pattern, the SPF-alone-insufficient thesis page is the STRUCTURAL-PROTOCOL-LEVEL companion that articulates the four canonical failure modes of the SPF-envelope-layer alone — failure modes the per-message DKIM-selector publication mechanism this page documents STRUCTURALLY FILLS at four orthogonal cryptographic-defense dimensions: (i) FORWARDING-PATH SURVIVABILITY — DKIM signature published at the <selector>._domainkey.<d> DNS owner-name survives mailing-list rewrites, ARC-sealed forwards, alias-redirects, and simple forwarding services where SPF's envelope-MAIL-FROM binding to authorised IPs STRUCTURALLY COLLAPSES to fail at the forwarder's source-IP substitution — the per-selector public-key publication is the receiver-side resolvable cryptographic anchor that re-establishes DMARC-pass alignment on the forwarded message where SPF's envelope-IP binding cannot survive the per-hop forwarder- rewrite; (ii) PER-MESSAGE- CRYPTOGRAPHIC-PROOF — the <selector>._domainkey.<d> public-key publication enables the verifier to VERIFY MESSAGE-CONTENT INTEGRITY via the per-message body-hash + signed-header-list cryptographic computation, where SPF only AUTHORISES the connecting IP without validating message content — at shared-IP-pool hosts (cPanel shared hosting, SaaS-ESP multi-tenant egress) the per-selector DKIM publication is the SOLE structural defense against a compromised neighbouring tenant spoofing from the shared-IP-pool envelope SPF blesses; (iii) SOURCE-IP- INDEPENDENCE — the per-selector DKIM publication verifies regardless of which outbound IP delivered the message, complementing SPF's hard binding to a finite enumerated IP allow-list — for publishers whose outbound sender catalogue exceeds the 10-DNS- lookup SPF budget ceiling (the multi-vendor publisher class M365 + Mailchimp + SendGrid + Salesforce + Amazon SES + Marketo + Zendesk), per-selector DKIM publication is the structural mechanism that AUTHENTICATES senders whose IPs cannot fit within the SPF lookup-budget ceiling; (iv) DOMAIN-OWNED-KEY- PUBLICATION — the per-selector key custody at <selector>._domainkey.<d> gives the publisher CRYPTOGRAPHIC SOVEREIGN CUSTODY of authentication evidence, structurally distinct from SPF's lookup-budget-constrained IP-allowlist enumeration — the publisher's per-selector dual-selector rotation cadence (rotate selector1, publish new selector2 key, advance signing to selector2, null-publish selector1, then rotate back) is the operational footprint of the DOMAIN-OWNED-KEY-CUSTODY model the SPF-alone- insufficient thesis page argues SPF cannot provide. Read the SPF-alone-insufficient thesis page alongside this selector-publication reference when authoring the operator's rationale for publishing DKIM AT ALL — the thesis page is the first-principles argument WHY per-selector DKIM publication is non- optional, and THIS page is the operational execution-layer reference for the actual selector-naming + publication + rotation discipline that operationalises the DKIM defense the thesis page argues for.
• Email deliverability — the DKIM-SELECTOR-COVERAGE-AS-INBOX- PLACEMENT-INPUT companion to THIS selector- publication reference. Where THIS page documents the per-sender DKIM-selector naming conventions (Google google._domainkey / Microsoft selector1._domainkey + selector2._domainkey / SendGrid s1._domainkey + s2._domainkey / Mailgun k1._domainkey / SES <random-token>._domainkey) plus the publication + rotation lifecycle each selector goes through, the deliverability spoke documents the BUSINESS- OUTCOME contract whose per-tenant DKIM-pass coverage across every legitimate sending source depends ENTIRELY on the selector- publication discipline this page is the operational reference for. Four SELECTOR- PUBLICATION-VS-DELIVERABILITY axes the deliverability spoke documents that THIS page is the operational foundation for: (1) per-tenant DKIM-pass-coverage gap — the deliverability spoke's "rua-stream dkim=none on transactional tenant" coverage-gap symptom traces the per-record auth-result back to the missing-selector publication root cause this page catalogues per-ESP (the operator provisioned the third-party ESP but failed to publish the ESP-required selector at the tenant's apex); (2) per-selector DKIM-permerror as inbox-placement disqualifier — the deliverability spoke's "rua-stream dkim=permerror across all sources" symptom traces the per-record auth-result back to the wrong-selector- lookup root cause this page documents (the sender's signing-side s= tag names a selector NOT published at <selector>._domainkey.<d-domain> in the authoritative zone); (3) dual-selector rotation discipline as deliverability-stability — the deliverability spoke's "DKIM rotation window deliverability dip" symptom traces the per-message dkim=fail-during-rotation cascade back to this page's dual-selector zero-downtime rotation procedure (publish new selector → switch signing → wait receiver-cache aging window → retire old selector); (4) per-receiver selector-lookup-cache divergence — the deliverability spoke's "per-receiver DKIM-pass-rate divergence across Microsoft vs Gmail vs Yahoo" symptom traces the per-receiver public-key-resolver-cache divergence back to the per-selector TXT- record TTL this page's selector-publication discipline documents the operational defaults of. Read THIS page when DESIGNING the selector-publication strategy for a multi-ESP tenant; read the deliverability spoke to UNDERSTAND how per-tenant per-selector publication coverage translates into the per-source DKIM-pass-rate the major mailbox providers consume as reputation input.
• ARC explained (RFC 8617 Authenticated Received Chain) — the FORWARDER-RELAY-PUBLISHES-PER-HOP- ARC-SEAL-SELECTOR-AT-DOMAINKEY-NAMESPACE- USING-DKIM-FORMAT-SELECTOR-CONVENTION companion to this DKIM selector-publication reference. Where THIS page documents the per-publisher selector-publication discipline (the per-publisher <selector>._domainkey.< publisher-domain> namespace convention, the per-selector RSA-2048 / Ed25519 public-key TXT-record publication, the per-tenant per-ESP selector-naming convention catalogues — google for Workspace, selector1/selector2 for M365, ESP-CNAME-delegated selectors like s1 for SendGrid, krs for Mailgun, scph0825 for Amazon SES), the ARC-explained spoke documents how every per-hop forwarder-relay in a multi- hop transit chain publishes its OWN per-hop ARC sealer-selector under the IDENTICAL DKIM-format selector-publication convention across FOUR per-hop ARC-sealer- selector-publication dimensions: (i) per-hop ARC sealer publishes its own selector at <sealer-selector >._domainkey.<sealer-domain> using DKIM-format TXT-record byte encoding — when Gmail's MTA re-signs a forwarded message with its ARC-Message-Signature, the AMS s=-tag value points to a Google-published selector at the <selector>._domainkey.google.com namespace; when Outlook's MTA seals a forwarded message, the AS s=-tag points to a Microsoft-published selector at the <selector>._domainkey.outlook.com namespace — the per-hop sealer-selector- publication discipline THIS page documents at the per-publisher signing layer materialises ONCE PER FORWARDER-HOP in the chain at the per-hop ARC sealer's organisational-domain namespace; (ii) per-hop ARC sealer-selector key- algorithm inheritance from DKIM algorithm-strength discipline — the per-hop ARC sealer's published selector publishes a per-RFC-8301 RSA- 2048-minimum / per-RFC-8463 Ed25519 public key using the IDENTICAL k=-tag / p=-tag selector-TXT-record encoding THIS page documents at the per-publisher selector- publication layer — the per-hop ARC signature verification at the next-hop receiver consumes the per-hop sealer's published public key using the SAME RSA-2048-or-stronger algorithm-strength gate the per-publisher DKIM signature verification uses; (iii) per-hop ARC sealer-selector rotation discipline parallels per-publisher DKIM selector- rotation discipline — each per-hop ARC sealer (Gmail / Outlook / Mailman / corporate gateway) rotates its published selector at a per-sealer- organisation cadence (monthly / quarterly / annually) using the IDENTICAL dual- selector overlap-window rotation discipline THIS page documents for the per-publisher DKIM-signing operator — the per-hop sealer publishes the new per-sealer selector at the per-sealer namespace, transitions outbound ARC sealing to the new selector, then revokes the prior per-sealer selector after a propagation grace period; and (iv) receiver-side chain- validator selector-lookup walks every per-hop ARC-AMS + ARC-AS selector in instance-order using DKIM selector-DNS- publication mechanics — the final-hop receiver's ARC-chain validator walks the cumulative chain in instance-order (i=1 → i=2 → i=n), reading each per-hop AMS/AS s=-tag + d=-tag combination and performing an RFC 6376 §3.6.2 DKIM-format selector lookup at <s-tag>._domainkey.< d-tag> to retrieve each per- hop sealer's published public key — the per-hop validator then verifies each per- hop AMS/AS signature using the same DKIM signature-verification primitives THIS page's selector-publication discipline feeds at the per-publisher level. Pair THIS DKIM selector-publication reference with the ARC-explained spoke when designing the per-hop forwarder-relay sealer-selector publication strategy for a forwarding-gateway or mailing-list- mediator deployment — the per-publisher selector-publication discipline THIS page documents IS the per-hop publication contract every per-hop ARC sealer materialises at its own per-sealer organisational-domain namespace in the forwarder-relay chain.
• Email Header Analyzer — the DMARC Analyzer tool that parses a raw message and surfaces every DKIM-Signature tag (c=, a=, d=, s=, h=, bh=, b=, l=) plus the Authentication-Results verdict.
• Domain Security Checker — verifies the DKIM selector DNS record (which publishes the public key the verifier uses) plus the full SPF / DMARC / BIMI / MTA-STS / TLS-RPT / CAA stack.
• DNS Record Generator — the DKIM record-generator wizard (Enterprise plan). Generates a syntactically- correct selector record with the public key in the canonical p= format.
• DKIM alignment with DMARC — the PER-SELECTOR-NAMESPACE-AS- DOWNSTREAM-FEEDER-OF-D-EQUAL-IDENTIFIER- PUBLICATION-DISCIPLINE-CONSUMED-BY-DMARC- ALIGNMENT-VERDICT companion to this DKIM selectors reference. Where THIS page documents the per-selector publication discipline (the <selector>._domainkey.<d-tag> TXT-RR namespace, the per-key-rotation selector retirement workflow, the multi- tenant selector partitioning), the DKIM- alignment-with-DMARC spoke documents how the per-selector publication this page catalogues sits ONE LAYER UPSTREAM of the d= signing-domain identifier that the receiver-side DMARC-alignment evaluator consumes as alignment-candidate input. Concretely, the spoke documents FOUR per-selector-to-DMARC-alignment-coupling dimensions: (i) the <selector>._domainkey.<d-tag> namespace as the publication anchor of the d= identifier the receiver compares to From: — the spoke documents how each selector this page catalogues is published UNDER a specific organisation-domain (the d-tag in the DNS namespace), making the publication- side selector-and-domain choice the ONE-LAYER-UPSTREAM precondition to the d=/From: alignment check the receiver- side DMARC evaluator performs; (ii) the per-tenant selector partitioning discipline as the multi- d= signing-identity DMARC-alignment- candidate-set publication dimension — the spoke documents how the per-tenant selector partitioning this page documents (each tenant publishing under its own selector + its own d= identifier) maps onto a per-d= DMARC- alignment-candidate-set the receiver evaluator consumes independently per signature; (iii) the relaxed- vs-strict adkim= mode as the organisational-domain-vs-exact-match selector-publication-discipline constraint dimension — the spoke documents how the publisher's adkim= alignment-mode choice (relaxed default vs strict opt-in) constrains the per-selector publication discipline this page catalogues — strict adkim forces the d= identifier to MATCH the From: header domain exactly, which constrains the selector-publication topology this page documents to per- From-domain-exact selector partitioning; and (iv) the selector-retirement- and-key-rotation workflow as the per- DMARC-alignment-verdict-stability publication discipline dimension — the spoke documents how the selector- retirement workflow this page catalogues (overlap-window dual-selector publication, post-rotation old-selector cleanup) must preserve the d= identifier continuity across rotations so that the receiver- side DMARC alignment verdict stays stable through the cryptographic key- rotation event. Read the DKIM-alignment- with-DMARC spoke alongside this selectors reference when the per- selector publication discipline this page documents needs to be sequenced into the d=/From: DMARC-alignment verdict the brand-protection programme depends on.
• CAA records explained — the per-publisher per-domain CAA-record publication-discipline companion to this DKIM-selectors reference. Where THIS page documents the per-publisher per-selector DKIM key-record TXT publication discipline (the <selector>._domainkey.<d-domain> per-selector authoritative-DNS TXT-RR publication, the dual-selector overlap- window rotation discipline, the per-selector RSA-2048 / Ed25519 cryptographic-algorithm choice publication, the per-selector retirement workflow), the CAA-records spoke is the PER-PUBLISHER-PER-DOMAIN-RFC-8659-CA- ISSUANCE-AUTHORIZATION-PUBLICATION reference documenting the per-publisher per-domain <domain> CAA 0 issue "<ca>" / 0 issuewild "<ca>" / 0 iodef "mailto:<reporter>" per-CA-authorisation publication discipline at the per-publisher per-domain authoritative-DNS zone apex. Four PER- PUBLISHER-AUTHORITATIVE-DNS-PUBLICATION- DISCIPLINE-COUPLING dimensions the CAA- records spoke documents: (i) per-publisher authoritative-DNS- zone publication discipline parallel — both the per-publisher per-selector DKIM TXT publication and the per-publisher per- domain CAA-record publication are authored at the publisher's authoritative-DNS zone, so the same per-zone change-management workflow + per-zone DNSSEC signing discipline + per-zone TTL choice applies to both publication primitives; (ii) per-publisher per-domain cryptographic-trust-anchor-publication discipline parallel — DKIM publishes WHICH per-selector public key authorizes per-message cryptographic verification for the d= domain, while CAA publishes WHICH per-CA authorizes per-domain TLS cert issuance — both are per- publisher per-domain cryptographic-trust- anchor publication primitives at distinct cryptographic layers (per-message DKIM signing vs per-domain TLS cert chain); (iii) per-publisher per-selector rotation-overlap-window vs per-publisher per-domain CAA-record change-window coupling — the per-selector dual- publication overlap-window discipline this page documents (publish new selector, wait for DNS propagation + receiver-side caching to flush, retire old selector) structurally parallels the per-domain CAA-record change- window discipline (publish new CAA issue value, wait for receiver- CA-side DNS caching to flush, retire old CAA value); both are per-publisher per-domain DNS-propagation-aware publication-discipline primitives; (iv) per-publisher per- domain explicit-revocation-publication- discipline parallel — DKIM's p= empty-public-key revocation publication (per-selector key explicitly retired) structurally parallels CAA's 0 issue ";" empty per-CA authorization-set publication (NO CA may issue certs for the domain) — both are per- publisher per-domain explicit-revocation- publication-discipline primitives at the authoritative-DNS publication boundary. Read the CAA-records spoke alongside this DKIM- selectors reference when the per-publisher per-selector DKIM-publication-discipline this page documents needs to be coordinated with the per-publisher per-domain CA- issuance-authorization publication- discipline at the same per-publisher authoritative-DNS zone-apex publication boundary.
• BIMI explained — the PER-PUBLISHER-PER-DOMAIN-BIMI-LOGO- RENDERING-DISCIPLINE-AS-LOAD-BEARING- DOWNSTREAM-CONSUMER-OF-PER-SELECTOR-DKIM- PUBLICATION-AND-ROTATION-CADENCE companion to this per-selector DKIM-publication-and- rotation reference. Where THIS page documents the per-publisher per-domain per-selector DKIM publication discipline (the <selector>._domainkey.<domain> TXT-record publication topology, the dual- selector selector1 + selector2 rotation overlap window, the per-tenant Workspace google._domainkey single- selector vs the per-tenant M365 selector1-<tenant> + selector2-<tenant> dual-CNAME selector convention), the BIMI spoke documents the FOUR PER-PUBLISHER-PER- DOMAIN-BIMI-LOGO-RENDERING DIMENSIONS structurally gated on THIS page's per- selector publication-and-rotation discipline: (i) per-publisher per-receiver per- message BIMI-rendering ELIGIBILITY ANCHORED on per-selector DKIM-aligned-pass — the receiver-side BIMI-rendering decision requires a per-message DKIM-aligned-pass verdict that THIS page's per-selector publication topology directly produces; a per-selector TXT-record retrieval failure (per-selector NXDOMAIN, per-selector SERVFAIL, per-selector public- key parsing error) defeats per-receiver per-message BIMI-rendering eligibility regardless of the per-publisher per-domain BIMI-record publication state; (ii) per-publisher per-domain BIMI- rendering CONTINUITY across per-selector DKIM-key-rotation OVERLAP WINDOW — the per-publisher per-domain BIMI- rendering continuity discipline requires the per-selector dual-selector rotation overlap window THIS page documents to sustain a per-receiver per-day DKIM-aligned- pass-rate floor across the rotation overlap window, because per-receiver per-day DKIM- aligned-pass-rate dips during single- selector rotation defeat per-publisher per- day per-receiver BIMI-rendering eligibility; (iii) per-publisher per-domain BIMI VMC certificate-binding cryptographic- attestation co-gated on per-selector DKIM publication topology — the per- publisher per-domain BIMI VMC (Verified Mark Certificate) chains its per-publisher mark- binding cryptographic attestation through the per-domain BIMI record whose per-receiver per-message verification cascade is co- gated on the per-selector DKIM-aligned-pass verdict produced by THIS page's per-selector publication topology — a per-selector publication topology drift (per-tenant Workspace single-selector → multi-selector migration, per-tenant M365 selector1/ selector2 CNAME-delegation drift) breaks the joint per-message BIMI-VMC-verification + DKIM-aligned-pass cryptographic-evidence stream; (iv) per-publisher per- domain BIMI l=-tag logo-URL publication CADENCE COORDINATION with per- selector DKIM-key-rotation cadence — the per-publisher per-domain BIMI l=-tag logo-URL publication cadence (typically per-brand-refresh, per-quarter-marketing-rotation) MUST be coordinated with the per-selector DKIM-key- rotation cadence THIS page documents so the joint per-receiver per-day per-publisher BIMI-logo-rendering observability stream remains coherent across both publication cadences. Read the BIMI spoke ALONGSIDE this per-selector DKIM-publication-and- rotation reference whenever the per- publisher per-domain operator EVALUATES the per-domain BIMI-logo-rendering publication investment as a downstream consumer of the per-selector DKIM-aligned- pass-rate continuity discipline THIS page's publication topology directly produces.
• DMARC forensic (failure / RUF) reports — the DMARC forensic-reports spoke documents the RFC 6591 ARF + RFC 7489 §7.3 + RFC 8460 per-message failure-envelope grammar whose per- signature DKIM-diagnostic block carries per-selector attribution evidence at the per-publisher per-domain per-receiver per-day evidence granularity that empirically validates the per-publisher per-domain per-selector publication-and- rotation operator-discipline THIS page documents. Four PER-SELECTOR-PUBLICATION- VS-FORENSIC-DIAGNOSTIC-BLOCK coupling axes the forensic-reports spoke documents: (i) per-publisher per-domain per- selector overlap-window rotation cadence (concurrent deprecating-and-incoming selector both verifying for at least 7 days) is empirically validated through the per-failure ARF envelope's policy.dkim-domain=<deprecating- selector> + dkim=permerror evidence-row ABSENCE during the overlap window — the absence of per-deprecating- selector permerror evidence at the per- publisher per-domain per-receiver per-day evidence granularity is the canonical operator-discipline validation signal that the rotation overlap-window was honoured; (ii) per-publisher per-domain per- selector revocation-via-empty-p= publication after a key compromise is empirically validated through the per- failure ARF envelope's dkim=fail +policy.dkim-domain=<revoked- selector> evidence-row emission when an attacker attempts to reuse the compromised key after the revocation publication propagates through the per- receiver verifier-side resolver-cache warm-up cycle — the forensic-reports spoke catalogues per- revoked-selector dkim=fail rows as the canonical operator-discipline validation signal that the revocation publication achieved its intended per-receiver verifier-side rejection objective; (iii) per-publisher per-domain per- selector dual-algorithm signing posture (RSA-2048 + Ed25519 per RFC 8463) is empirically validated through the per- failure ARF envelope's per-signature attribution evidence at the per-publisher per-domain per-receiver per-day evidence granularity — per-publisher per-domain dual-algorithm deployments populate the per-failure ARF envelope with per-signature dkim=pass / dkim=fail / dkim=neutral rows whose per- algorithm attribution evidence is the canonical operator-discipline validation signal that the per-publisher per-domain verifier-coverage divergence-mitigation rule is operating as designed across the heterogeneous per-receiver verifier population; (iv) per-publisher per-domain per-selector CNAME-delegation operator-discipline (M365 selector1 / selector2 → onmicrosoft.com, Workspace google._domainkey TXT, ESP CNAME chains) is empirically validated through the per-failure ARF envelope's dkim=permerror + policy.dkim-domain=<dangling- CNAME-target> evidence-row ABSENCE during the per-tenant CNAME- delegation steady-state — the forensic-reports spoke catalogues per-CNAME-delegation-target dangling- chain permerror evidence as the canonical operator-discipline regression signal that a per-tenant selector CNAME chain has fallen out of the delegating publisher per-tenant DNS-zone publication discipline. Read THIS page when AUTHORING the per- publisher per-domain per-selector publication-and-rotation operator- discipline; read the forensic-reports spoke when CONSUMING the per-publisher per-domain per-failure ARF envelope per- signature DKIM-diagnostic-block per- selector attribution evidence that empirically validates per-rotation per- revocation per-dual-algorithm per-CNAME- delegation operator-discipline compliance at the per-publisher per-domain per- receiver per-day evidence granularity.
• DMARC for SaaS senders — the SaaS-multi-tenant-relay companion to this DKIM-selector partitioning-model reference. Where THIS page documents the RFC 6376 §3.6.1 <selector>._domainkey.<d-tag> per-tenant per-publisher namespace reference + the per-selector publication discipline + the per-selector rotation cadence + the per-selector CNAME- delegation pattern, the SaaS-senders spoke documents the CANONICAL DOWNSTREAM SaaS-multi-tenant-relay deployment topology where the per-selector partitioning-model is the load-bearing per-customer per-vendor authentication- infrastructure primitive. The DKIM- SELECTOR-VS-SAAS-RELAY cross-reference establishes FOUR coupling dimensions: (i) per-customer per-SaaS-vendor CNAME-delegated-selector publication substrate parallel — the per-customer CNAME at <vendor-selector>._domainkey.<customer-domain> delegates the per-selector public-key publication to the SaaS-vendor's managed-zone; this is the canonical per-customer per-vendor deployment-topology proof-case for the per-selector partitioning-model THIS page documents; (ii) per-customer per-vendor selector-rotation cadence transfer — SaaS-vendor managed rotation of the per-customer CNAME-delegated selector follows the per-selector rotation discipline this page documents at the per-publisher per-domain scope; the SaaS spoke documents the per-customer per-vendor managed- rotation discipline whose per-tenant operational invisibility to the per- customer-domain operator is the per- SaaS-vendor managed-service value proposition; (iii) per-customer per-vendor multi-selector cohort publication — major SaaS-vendor deployments publish MULTIPLE per- customer CNAME-delegated selectors (e.g., s1._domainkey + s2._domainkey) to enable zero-downtime per-customer per-vendor key rotation; the SaaS spoke documents the per-customer per-vendor dual-selector cohort publication discipline whose per-tenant overlap- window operational discipline this page's per-selector rotation cadence catalogue anchors; (iv) per- customer per-vendor per-selector dkim= pass verdict gating DMARC alignment for the per-customer From-header organisational domain — the per-customer CNAME-delegated selector's per-message DKIM-pass verdict is the load-bearing per-customer per-vendor upstream cryptographic-pass primitive every per-customer DMARC ramp depends on; the SaaS spoke documents the per- customer per-vendor per-selector dkim= pass + DMARC-alignment-check sequence whose per-selector-namespace- partitioning model this page documents at the per-publisher per-domain scope. Read the SaaS-senders spoke alongside this DKIM-selector partitioning-model reference when operating a per-SaaS- vendor per-customer-domain CNAME- delegated-selector deployment topology.
• TLS-RPT record syntax explained — the RFC 8460 §3 _smtp._tls.<d> TXT-record byte-grammar reference covering the v=TLSRPTv1 version-token prefix and the rua=mailto: / rua=https:// per-publisher per-domain reporting-endpoint-token publication discipline. THIS page documents the per- publisher per-selector DKIM public-key TXT- record byte-grammar at the RFC 6376 §3.6.1 per-selector-key-record publication layer (v=DKIM1; k=rsa; p=<base64-public-key> token catalogue authored at the <selector>._domainkey.<d> per-publisher per-selector publication boundary as the cryptographic-anchor whose per-receiver retrieval validates the per- message DKIM-Signature header); the TLS-RPT- record-syntax spoke is the cross-protocol message-layer-vs-transport-layer TXT-record byte-grammar publication peer documenting the per-publisher per-domain transport-layer observability reporting-channel-endpoint registration TXT-record byte-grammar token catalogue (v=TLSRPTv1; rua=mailto: per-domain terminal-mailbox-endpoint token, rua=https:// per-domain JSON-POST- endpoint token, the per-token ; delimiter discipline at the RFC 8460 §3 record-grammar level). Both DKIM-per-selector TXT publication and TLS-RPT TXT publication share the per-publisher per-domain DNS-zone- editor publication substrate, the per- publisher per-domain RFC-published byte- grammar authoring discipline, and the per- publisher per-domain rotation-aware DNS- propagation overlap-window operational cadence — DKIM AUTHORS the per-publisher per- selector message-layer cryptographic-anchor TXT-record and TLS-RPT AUTHORS the per- publisher per-domain transport-layer observability reporting-channel-endpoint TXT-record. Read the TLS-RPT-record-syntax spoke alongside this DKIM-selector partitioning-model reference when authoring the per-publisher per-domain DNS-zone-file commit batch that publishes BOTH the per- selector DKIM public-key TXT records AND the per-domain TLS-RPT record as the unified per- publisher per-domain message-layer- cryptographic-anchor + transport-layer- observability dual-TXT-RR publication discipline.
• How attackers bypass weak DMARC — the WEAK-DMARC-ATTACK-SURFACE-CATALOGUE companion to this DKIM-selector publication and rotation reference. Where THIS page documents the per-selector DNS label structure (<selector>._domainkey.<domain>), the every-tag selector record reference (v=DKIM1, k=rsa, p=, t=y, t=s, h=sha256, s=email, n=), the dual- selector zero-downtime rotation pattern, the multi-selector multi-vendor deployment model, and the seven most common selector- related failures (NXDOMAIN, wrong selector in signature, stale selector, 255-byte TXT split, CNAME-vs-TXT confusion, wildcard interference, DNS propagation lag), the DMARC-attacker-bypass spoke catalogues the per-attacker per-message DKIM-side bypass attack-variants the per-publisher per- domain per-selector key-rotation hygiene defends against — DKIM-replay attacks (signed-once messages re-delivered against unrotated selectors), DKIM-key-cryptanalysis against under-1024-bit RSA keys retained past their cryptographic shelf-life, selector-pinning attacks where the attacker registers a look-alike selector under the attacker-controlled domain, and selector- rotation-window exposure where an attacker- cached pre-rotation DKIM-Signature passes verification against the still-DNS-published pre-rotation public key. The per-publisher per-domain per-selector key-rotation cadence THIS page documents IS the per-publisher per-domain operational defence against the DKIM-side bypass attack-class catalogue at four DKIM-selector-key-rotation-discipline- vs-DMARC-attacker-bypass-surface coupling dimensions: (i) per-selector key-rotation cadence as per-publisher per-domain DKIM- aligned-pass-rate floor preservation — the rotation cadence defends against the DKIM- key-cryptanalysis attack-variant in the bypass catalogue by retiring under- cryptographic-shelf-life keys before attackers can factor them; (ii) dual- selector overlap-window publication discipline as DKIM-replay-attack defence — the overlap-window cadence bounded by the TTL of the retired selector closes the DKIM-replay window where attacker-captured pre-rotation signed messages remain verifiable against the still-DNS-published key; (iii) per-selector key-revocation discipline at suspected compromise — the per-selector empty-p=-tag revocation per RFC 6376 §3.6.1 closes the bypass-catalogue attack-variant where attacker-captured private key material is used to forge per-publisher per-domain DKIM-aligned-pass messages; and (iv) per- publisher per-domain DKIM key-size minimum as cryptographic-discipline floor — the per-publisher per-domain RSA-2048-minimum (per RFC 8301) or Ed25519 (per RFC 8463) key-size selection floor closes the DKIM- key-cryptanalysis bypass-catalogue attack- variant against weak-key per-selector keys. Read THIS page when AUTHORING the per- publisher per-domain per-selector DKIM record publication + rotation cadence; read the DMARC-attacker-bypass catalogue spoke when AUDITING the per-publisher per- domain DKIM posture against the DKIM-side bypass attack-class catalogue the per- publisher per-domain per-selector key- rotation hygiene THIS page documents structurally defends against at the per- receiver per-message DKIM verification boundary.
• SPF for Google Workspace — the per-Workspace-tenant per-custom- domain envelope-MAIL-FROM-layer SPF publication-discipline companion to this per-publisher per-selector DKIM selector reference. Where THIS page documents the per-publisher per-selector DKIM selector- naming convention (per-selector subdomain <selector>._domainkey.<domain> TXT-RR publication discipline, per- selector key-rotation cadence, dual- selector overlap-window zero-downtime rotation, per-selector v=DKIM1; k=rsa; p=... tag- vocabulary), the SPF-for-Google-Workspace spoke documents the per-Workspace-tenant per-custom-domain envelope-MAIL-FROM- layer SPF publication (v=spf1 include:_spf.google.com -all canonical baseline, per-tenant per- custom-domain Gmail-egress include:_spf.google.com macro expansion at ~3 nested include: sub-records, per- tenant per-third-party-sender SPF- flattening discipline against the RFC 7208 §4.6.4 ten-DNS-lookup ceiling). Four per-Workspace-tenant per-custom-domain authentication-leg-composition coupling dimensions matter at the per-tenant per- custom-domain composite authentication- publication boundary: (i) per-Workspace- tenant per-custom-domain google._domainkey CNAME- delegated DKIM selector publication vs per-tenant envelope-layer SPF — the per- tenant per-custom-domain google._domainkey.<custom-domain> CNAME publication delegated to dkim.google.com (the per- tenant DKIM signer-managed public key rotation) IS the per-tenant application- layer publication-discipline THIS page documents for the Workspace-tenant case; the per-tenant include:_spf.google.com SPF publication the SPF-for-Google-Workspace spoke documents IS the parallel per- tenant envelope-layer publication- discipline; both compose at the per- tenant per-custom-domain composite authentication-publication-portfolio boundary; (ii) per-Workspace-tenant per- custom-domain DKIM-aligned-pass OR SPF- aligned-pass DMARC composite-verdict cascade — the per-tenant per-custom- domain DMARC composite-verdict pass requires AT LEAST ONE aligned-pass leg per RFC 7489 §3.1; the per-tenant DKIM-aligned-pass leg the per- publisher per-selector DKIM-publication- discipline THIS page documents IS the per-tenant application-layer composite- verdict-attribution leg, the per-tenant SPF-aligned-pass leg the SPF-for-Google- Workspace spoke documents IS the per- tenant envelope-layer composite-verdict- attribution leg, both consumed at the per-tenant per-custom-domain composite- verdict-evaluation boundary; (iii) per- Workspace-tenant per-custom-domain forwarder-survivability discipline — per- tenant per-custom-domain forwarder- induced envelope-MAIL-FROM rewrite breaks per-tenant first-hop SPF verdict (per- tenant include:_spf.google.com no longer authorizes the forwarder's envelope sender), but per-tenant DKIM- Signature with c=relaxed/relaxed canonicalization SURVIVES forwarder-hop body-modification at-rest the per- publisher per-selector DKIM-publication- discipline THIS page documents; per- tenant DKIM-aligned-pass IS the per- tenant authentication-leg-of-last-resort when per-tenant SPF breaks at the per- tenant per-custom-domain forwarder-hop boundary; (iv) per-Workspace-tenant per- custom-domain composite authentication- publication-portfolio coordination — the per-tenant per-custom-domain composite SPF + DKIM + DMARC + ARC + MTA-STS + TLS- RPT publication-portfolio THIS page's per-publisher per-selector DKIM-selector- publication-discipline component IS the per-tenant application-layer publication-portfolio component, the SPF-for-Google-Workspace spoke's per- tenant per-custom-domain envelope-MAIL- FROM-layer publication-discipline IS the per-tenant envelope-layer publication- portfolio component, both consumed at the per-tenant per-custom-domain publication-portfolio-coordination floor. Read THIS page when AUTHORING the per- publisher per-selector DKIM-selector- publication-discipline; read the SPF-for- Google-Workspace spoke when AUTHORING the per-Workspace-tenant per-custom- domain envelope-MAIL-FROM-layer SPF publication that per-tenant per-custom- domain DKIM-selector-publication THIS page documents structurally coordinates with at the per-tenant per-custom-domain composite envelope-and-application-layer publication-portfolio coordination floor.
• DMARC for Office 365 hybrid — the M365-hybrid deployment spoke covering the per-hybrid-tenant per-customer-domain topology where the per-publisher per-selector DKIM-selector-naming-and-publication discipline THIS page documents must coordinate TWO independent selector-publication channels: (i) the on-prem Exchange-Edge-Transport operator-managed selector (operator-named, operator-published as a DNS-TXT-RR at the operator's authoritative server) and (ii) the EOP cloud-mailbox CNAME-delegated Microsoft- managed dual-selector (selector1._domainkey / selector2._domainkey CNAMEs delegated to the EOP per-tenant DNS infrastructure). Read the hybrid-deployment spoke when applying the per-publisher per- selector DKIM-selector-naming discipline THIS page documents to a hybrid topology that demands per-tenant per-customer-domain selector-rotation-cadence coordination across both independent publication channels to prevent per-receiver DKIM verification from retrieving a stale per-selector public-key during a mid-rotation propagation tail.
• DMARC troubleshooting — read the DMARC troubleshooting catalogue alongside this DKIM-selector publication spoke when DIAGNOSING per-publisher per- domain DMARC-aligned-pass-rate floor regression traceable to per-publisher per- selector publication drift, when AUDITING per-publisher per-selector overlap-rollover cutover-readiness before per-publisher per- domain DMARC enforcement-mode-ramp progression, or when AUTHORING the per- publisher per-domain DMARC-aligned-pass-rate floor preservation discipline against per- publisher per-selector key-rotation cadence misalignment the troubleshooting catalogue closes per-receiver per-day per-source-IP attribution-row root-cause traceability for.
• Business Email Compromise (BEC) defence stack — the per-publisher per-selector DKIM- publication-discipline-as-load-bearing-anti- BEC-application-layer-defence companion to this DKIM selectors pillar. Where THIS page documents the per-publisher per-selector DKIM TXT-RR publication-discipline (the <selector>._domainkey.<domain> DNS-publication-target namespace per RFC 6376 §3.6.1, the dual-selector overlap-rollover rotation cadence preserving DKIM-aligned-pass- rate floor through retirement-pass cleanup, the per-stream selector-namespace partitioning under multi-stream egress), the BEC defence- stack spoke documents the per-publisher per- domain anti-BEC application-layer defence boundary the per-selector publication- discipline underpins. Four coupling axes connect them: (i) per-publisher per-selector DKIM dual-selector overlap-rollover discipline IS the load-bearing anti-replay-spoofing- attack defence — attackers harvesting retired-selector DKIM-signed messages from archives + replaying against per-receiver re-verification windows are gated by the per-publisher per-selector retirement-pass cleanup discipline; (ii) per-publisher per- stream subdomain isolation (finance.<org> vs hr.<org> vs executive.<org>) under adkim=s strict-mode identifier- alignment IS the load-bearing anti-cousin- domain-spoofing + anti-display-name-spoofing defence — attackers registering flnance.<org> / hr-team.<org> lookalike domains for BEC pretext-emails are gated by strict-mode identifier-alignment requiring per-stream DKIM-Signature d=-tag-vs-RFC-5322-From:-header per-subdomain equality; (iii) per-publisher per-selector key-rotation cadence (RSA-2048 minimum per RFC 8301 + 6-month rotation recommendation) IS the load-bearing anti- compromised-account-spoofing defence — per-selector private-key compromise via stolen-credentials attack-surface is gated by per-selector key-rotation cadence limiting per-key per-attacker-window verdict-falsification exposure; (iv) per-publisher per-selector DKIM-Signature header coordination with ARC- Seal at forwarder-cascade boundaries IS the load-bearing anti-authenticated-replay- spoofing defence — attackers replaying legitimately-DKIM-signed BEC pretext-emails through forwarder cascades preserving the original DKIM-Signature are gated by per- forwarder-hop ARC-Seal addition surfacing in per-receiver Authentication-Results arc=pass/fail attribution. Read the BEC defence-stack spoke alongside this DKIM selectors pillar when AUTHORING per- publisher per-stream subdomain-isolation anti-BEC publication discipline, when AUDITING per-selector retirement-pass cleanup hygiene against per-selector archive-replay attack surface, or when PLANNING per-publisher per- selector key-rotation cadence against per-key per-attacker-window verdict-falsification exposure-budget.
• Email security glossary — the threat-actor / OSINT / defense-in-depth / incident-response / threat-modeling cybersecurity-vocabulary registry — per-publisher per-selector DKIM-selector naming and per-stream selector-segmentation publication-discipline THIS page documents materially depends on canonical operator-side terminology for DKIM-replay-attack threat-class, per-selector retirement-pass cleanup IR-playbook vocabulary, and per-attacker-window verdict- falsification threat-modeling vocabulary the security-glossary catalogues alongside the broader phishing-and-impersonation threat- taxonomy registry every per-publisher per- selector DKIM operator consumes for cross- protocol threat-and-defense terminology- disambiguation.
• DMARC deployment checklist — the PER-PUBLISHER-PER-SELECTOR-DKIM-SELECTOR-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-PHASE-1-DISCOVERY-PREREQUISITE-AND-PER-PHASE-EXIT-CRITERIA-GATE-FOR-PER-PUBLISHER-PER-DOMAIN-DMARC-FOUR-PHASE-OPERATOR-ACTIONABLE-DEPLOYMENT-PROGRESSION companion at four per-publisher per-selector DKIM-selector-publication-vs-DMARC-deployment-checklist coupling dimensions: (i) per-publisher per-selector DKIM <selector>._domainkey.<d> TXT-RR publication-discipline per RFC 6376 §3.6.1 THIS page documents the per-publisher per-selector publication-discipline of IS the load-bearing per-publisher per-domain Phase 1 Discovery prerequisite-floor whose per-publisher per-selector publication-completeness inventory the per-publisher per-domain DMARC deployment-checklist Phase 1 Discovery action-items reference enumerates as an authorised-sender-inventory enumeration gate; (ii) per-publisher per-selector DKIM-aligned-pass leg per RFC 7489 §3.1.1 surfacing as per-receiver per-day per-source-IP DMARC RUA aggregate-report policy_evaluated/dkim=pass attribution per RFC 7489 §6.6.2 IS the load-bearing per-publisher per-domain Phase 2 Triage attribution-baselining evidence stream the per-publisher per-domain DMARC deployment-checklist Phase 2 Triage per-phase-exit-criteria readiness-decision-discipline coordinates against as a per-leg pass-rate floor preservation reference; (iii) per-publisher per-selector DKIM dual-selector overlap-rollover publication-discipline + per-selector key-rotation cadence floor THIS page documents the per-publisher per-selector publication-portfolio hygiene of IS the load-bearing per-publisher per-domain operator-side resilience-and-survivability discipline whose per-publisher per-domain DKIM-aligned-pass-rate floor preservation cascades into per-publisher per-domain DMARC composite-verdict enforcement-mode publication-decision readiness the per-publisher per-domain DMARC deployment-checklist Phase 3 Quarantine + Phase 4 Reject terminal-stage enforcement-ramp coordinates against; (iv) per-publisher per-selector DKIM-selector publication-discipline drift (premature per-selector retirement-without-overlap-rollover surfacing as per-day per-receiver dkim=fail attribution distortion, or per-selector mis-published TXT-RR byte-grammar surfacing as per-day per-receiver dkim=permerror attribution distortion per RFC 6376 §3.9, or per-stream selector-naming collision under multi-stream egress surfacing as per-source-IP DKIM-aligned-pass-rate distribution distortion) directly opens per-publisher per-domain DMARC-aligned-pass-rate floor regression below the per-publisher per-domain DMARC deployment-checklist per-phase-exit-criteria evidence-driven readiness threshold the per-publisher per-domain DMARC deployment-checklist Phase 3 Quarantine + Phase 4 Reject terminal-stage enforcement-ramp publication-discipline THIS DMARC-deployment-checklist spoke documents the operator-actionable per-phase-exit-criteria of structurally depends on at the per-publisher per-domain composite cross-protocol DKIM-selector-publication-and-DMARC-deployment-ramp coordination boundary.
• DMARC for shared-hosting — the PER-PUBLISHER-PER-SELECTOR-DKIM-SELECTOR-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-PHASE-1-DISCOVERY-PREREQUISITE-FOR-PER-SHARED-HOSTING-TENANT-PER-CUSTOM-DOMAIN-DMARC-FIVE-STEP-DEPLOYMENT companion at four per-publisher per-selector DKIM-selector-publication-vs-shared-hosting-DMARC-deployment coupling dimensions: (i) per-shared-hosting-tenant per-custom-domain DKIM <selector>._domainkey.<custom-domain> TXT-RR publication-discipline per RFC 6376 §3.6.1 THIS page documents the per-publisher per-selector publication-discipline of IS the load-bearing per-tenant per-custom-domain Step 2 (Verify or publish DKIM) prerequisite-floor whose per-tenant per-custom-domain DKIM-selector publication-completeness inventory the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain DKIM-publication-discipline of structurally depends on; (ii) per-shared-hosting-tenant per-custom-domain DKIM-selector publication-discipline drift (per-tenant per-custom-domain default-vs-cPanel-WHM-default vs `<selector>._domainkey.<shared-host>` vs `default._domainkey.<custom-domain>` selector-naming confusion across the shared-IP-pool tenant population) surfaces in per-receiver per-message dkim=permerror verdict-class per RFC 8601 §2.7.1 whose per-tenant per-custom-domain root-cause attribution the shared-hosting DMARC-deployment page's troubleshooting + common-mistakes sections document the per-tenant per-custom-domain selector-publication-discipline triage-procedure of; (iii) per-shared-hosting-tenant per-custom-domain DKIM dual-selector overlap-rollover publication-discipline IS the load-bearing per-tenant per-custom-domain operator-side resilience-and-survivability discipline whose per-tenant per-custom-domain DKIM-aligned-pass-rate floor preservation cascades into per-tenant per-custom-domain DMARC composite-verdict enforcement-mode publication-decision readiness the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain Step 5 (Advance from `p=quarantine` to `p=reject`) terminal-stage enforcement-ramp publication-discipline of structurally depends on; (iv) per-shared-hosting-tenant per-custom-domain DKIM-selector publication-discipline drift (premature per-selector retirement-without-overlap-rollover surfacing as per-day per-receiver dkim=fail attribution distortion at the shared-IP-pool egress, per-tenant per-custom-domain mis-published TXT-RR byte-grammar at the per-tenant DNS-publication point surfacing as per-day per-receiver dkim=permerror attribution per RFC 6376 §3.9, per-tenant per-custom-domain selector-naming collision under multi-stream shared-hosting egress) directly opens per-shared-hosting-tenant per-custom-domain DMARC-aligned-pass-rate floor regression below the per-tenant per-custom-domain DMARC ramp-readiness evidence-driven readiness threshold the shared-hosting DMARC-deployment page documents the per-tenant per-custom-domain composite envelope-and-application-layer publication-discipline coordination boundary of, structurally underpinning the per-shared-hosting-tenant per-custom-domain composite cross-protocol DKIM-selector-publication-and-shared-hosting-DMARC-deployment-ramp coordination floor.
• DMARC for Google Workspace — the Google-Workspace-tenant deployment guide. Workspace publishes its DKIM key under the google selector at google._domainkey.<domain>; this guide walks through generating, publishing, and aligning that selector for a Workspace tenant — the per-provider application of the selector-publication discipline documented above.
• DMARC policy modes — the enforcement context the selector exists for. A correctly published selector keeps the DKIM-aligned-pass leg solid, which is what lets you move the DMARC policy from p=none to p=quarantine and on to p=reject; this spoke walks the three modes and the evidence-driven ramp between them.
• Phishing protection — the threat-context companion this selector discipline ultimately serves. A correctly published DKIM selector keeps the message-signature leg verifiable, and a solid DKIM-aligned-pass is exactly what lets DMARC reject the spoofed mail a phishing campaign sends — read the phishing-protection guide for the full threat model the per-selector publication discipline documented here defends against.
• SPF for Microsoft 365 — the envelope-MAIL-FROM-layer companion to this per-selector DKIM reference on the same M365 tenant. Where THIS page documents the selector1 / selector2._domainkey CNAME-delegated DKIM selector pair Microsoft 365 publishes, the SPF-for-M365 spoke documents the parallel include:spf.protection.outlook.com authorisation leg — the two authentication legs that BOTH feed the DMARC aligned-pass disjunction for an M365-sent message. Read the SPF-for-M365 spoke alongside this selector guide when standing up a tenant: the DKIM selector pair and the SPF include are published together, and a message needs at least one of the two legs aligned-passing to survive a p=reject DMARC policy.
• MTA-STS policy syntax — a DKIM selector publishes the signing key at <selector>._domainkey.<domain> to authenticate the message; the MTA-STS policy publishes transport-security rules via the _mta-sts.<domain> TXT record plus an HTTPS-served policy file. This reference dissects that file's version / mode / mx / max_age grammar — the transport-layer publication discipline that parallels the message-layer selector discipline this page documents.
• Microsoft SNDS + JMRP monitoring — a valid DKIM signature does not outrank a bad IP reputation at Outlook.com: SNDS shows how Microsoft's consumer network actually graded each sending IP (GREEN/YELLOW/RED) and JMRP surfaces the Junk clicks behind a degraded verdict.

12. Verify your DKIM selectors now

The fastest way to confirm every selector under your domain is reachable and well-formed:

1. Enumerate the selectors your senders use. List every active sender (Microsoft 365, Google Workspace, Mailchimp, SendGrid, your internal Postfix, etc.) and the selector each sender uses (from the provider admin console or your signer config).
2. Resolve each selector record with dig +short TXT <selector>._domainkey.<your-domain>. Confirm each returns the expected v=DKIM1; ...; p=<base64-key> value (or follows a CNAME for provider-managed selectors).
3. Use the Domain Security Checker to surface all currently- active selectors automatically — it queries the common provider selectors plus any selectors observed in inbound DMARC aggregate reports.
4. Inspect a real DKIM-Signature header with the Email Header Analyzer. Send a test message to a mailbox you control, copy the raw source, and paste into the analyzer — the DKIM-Signature panel shows the s= tag plus the verification verdict for each signed message.