DMARC Analyzer

TL;DR

• DKIM key rotation is the operational practice of periodically replacing the cryptographic keypair that signs outbound mail under a domain. Specified in RFC 6376; minimum key size mandated by RFC 8301 (2048-bit RSA minimum, 1024-bit deprecated).
• The industry-baseline cadence is annual rotation for production signing keys, with shorter cadences (3-6 months) for high-value brand domains and immediate emergency rotation on suspicion of key compromise.
• The canonical zero-downtime procedure is dual-selector rotation: publish the new public key under a fresh selector, wait for DNS propagation, switch the signer to the new selector, leave the old selector live for at least 7 days plus the longest receiver cache window, then remove the old selector.
• Single-selector hot-swap is the riskier emergency procedure: replace the public-key TXT record at the current selector with the new public key, simultaneously switch the signer to the new private key, and accept a 24-48 hour window of body-hash failures on in-flight mail.
• Managed providers automate rotation: Google Workspace Auto Key Rotation (quarterly, DNS-API or manual), Microsoft 365 selector1 / selector2 alternation (quarterly, CNAME-based), Amazon SES Easy DKIM (automatic on schedule), Mailgun (per-selector), Postmark (per-server- identifier).
• The 1024-bit RSA factoring risk documented by the 2012 Zach Harris research project plus the 2018 RFC 8301 deprecation mandate make 2048-bit RSA the operational minimum; RFC 8463 Ed25519 is the recommended migration target.
• The 255-byte TXT record limit is the most common operator-facing pitfall: 2048-bit RSA public keys exceed 255 characters and MUST be published as multiple quoted strings within one TXT record. Some DNS provider UIs silently truncate, producing a corrupted published key.
• The old public-key TXT record SHOULD be removed promptly after a key compromise; some operators prefer publishing a revocation record (p= empty value) at the compromised selector. The practical effect is identical because both routes leave the attacker with no valid DKIM signature.

1. Overview: what DKIM key rotation is and why every operator needs a rotation plan

DomainKeys Identified Mail (DKIM) authenticates email by attaching a cryptographic signature over selected message headers and the message body. The signing operation uses a private key held by the sender; the receiver fetches the matching public key from a DNS TXT record at {selector}._domainkey.{domain} and verifies the signature. Because the private key is the cryptographic anchor for every signed message, the operational integrity of DKIM hinges on the operator keeping the private key secret AND retiring keys on a sensible cadence before cryptographic advances erode their strength.

DKIM key rotation is the operational practice of periodically generating a fresh keypair, publishing the new public key in DNS, switching the mail signer to use the new private key, and retiring the old key. Rotation serves three distinct purposes that often get conflated:

1. Cryptographic hygiene - replacing keys before computational advances make them factorable. The 2018 RFC 8301 deprecation of 1024-bit RSA was the most recent collective recognition that older keys had crossed the threshold; the next such recognition is anticipated when 2048-bit RSA becomes economically factorable (currently projected post-2030).
2. Compromise recovery - immediately retiring a key that has been exposed, suspected of exposure, or whose signing host has been breached. This is the unscheduled emergency rotation path; every operator MUST be prepared to execute it without delay.
3. Compliance and audit - many regulated industries (financial services, healthcare, government contracting) require documented key-rotation procedures with defined cadences. Annual rotation is the most common compliance baseline.

This guide walks the cadence, the canonical zero-downtime dual-selector procedure, the riskier single-selector hot-swap procedure for emergency rotations, per-provider automation flows for Google Workspace + Microsoft 365 + Amazon SES + Mailgun + Postmark, the RSA-to-Ed25519 migration path, common operator mistakes, troubleshooting of TXT-record-size and body-hash issues, and answers to the most-searched DKIM rotation questions.

2. Why rotate: the security rationale

DKIM is unusual among email-authentication standards in that it does NOT have an automatic key-rotation protocol built into its DNS layer. RFC 6376 defines selectors and the public-key TXT record schema but explicitly leaves rotation policy to the operator. The practical consequence is that a published DKIM key remains valid until the operator removes the TXT record - no expiry, no automatic refresh, no DNSSEC-level signal.

Three distinct threat models motivate rotation:

2a. Cryptographic strength erosion

The 2012 Zach Harris research project demonstrated that 1024-bit RSA DKIM signing keys were factorable with then-available cloud computing resources at sub-thousand-dollar cost. Harris factored Google's, PayPal's, Twitter's, Yahoo's, and US-Bank's then-published 1024-bit DKIM keys as a proof of concept, demonstrating that an attacker willing to spend a few hundred dollars in compute could forge DKIM signatures for any message under those domains. The disclosure triggered an industry-wide upgrade to 2048-bit RSA, formalised in RFC 8301 (January 2018) which mandates a minimum of 1024 bits but recommends 2048 bits and warns that 1024-bit keys SHOULD NOT be used.

The current generation of 2048-bit RSA DKIM keys is considered safe through approximately 2030 per NIST SP 800-131A guidance on key-strength transition. Operators publishing 2048-bit keys today have a roughly 5-7 year cryptographic runway; longer-term operators should plan to migrate to RFC 8463 Ed25519 DKIM signing once major receivers universally support it (Gmail and Microsoft 365 both verify Ed25519 signatures as of 2024).

2b. Key compromise

The DKIM private key is held by every host that signs outbound mail. Compromise paths include:

• A breach of the signing-host operating system (private key on disk).
• Accidental commit of the private key to a version-control system (the most common small-business compromise path).
• An insider with administrative access taking a copy of the key on exit.
• A misconfigured backup that ships the private key to a third-party storage service in cleartext.
• A vulnerable signing implementation that leaks key material via timing side channels.

A compromised DKIM private key lets the attacker sign arbitrary messages under the victim domain that pass DKIM at every receiver. Combined with a published DMARC policy (which most receivers treat as legitimising the message), the attacker gains a forged-but-authenticated channel that bypasses every receiver-side anti-phishing control that respects DKIM authentication.

2c. Replay attacks

A signed DKIM message remains valid until the key is rotated or revoked. An attacker who captures a legitimately-signed message body (for example a marketing newsletter sent to thousands of recipients) can re-send that same body verbatim to additional recipients - the DKIM signature remains valid because the body bytes are unchanged. This is the DKIM replay attack class that the 2023 SMTP smuggling work brought back into focus. Rotation does not prevent replay during the key's lifetime, but it bounds the replay window: an attacker has only until the key is rotated to exploit a captured signature.

3. When to rotate: scheduled vs trigger-driven rotation

Rotation events fall into two categories: planned scheduled rotations on a calendar cadence, and unplanned trigger-driven rotations in response to a specific event.

3a. Scheduled rotation triggers

• Annual cadence - the industry baseline. Most regulated industries (PCI DSS, HIPAA, SOC 2) accept annual rotation as sufficient documentation for a key-management control.
• Quarterly cadence - the baseline used by Google Workspace Auto Key Rotation, Microsoft 365 selector1 / selector2 alternation, and Amazon SES Easy DKIM. The shorter cadence is well within reach when rotation is automated by the provider.
• Bi-annual or semi-annual - the middle-ground cadence for high-value brand domains where annual feels too long but quarterly is operationally burdensome.

3b. Trigger-driven (unscheduled) rotation triggers

• Confirmed compromise - the private key has been exposed (committed to a public repository, captured by an attacker, included in a breach disclosure). Execute emergency rotation immediately; the old key MUST be removed from DNS within hours.
• Suspected compromise - signs of unauthorised access to the signing host OR unusual outbound mail volumes attributable to the signing identity. Execute emergency rotation while the forensic investigation proceeds in parallel.
• Key-size upgrade - moving from 1024-bit RSA to 2048-bit RSA (the RFC 8301 mandate), from 2048-bit RSA to 4096-bit RSA (defensive depth), or from RSA to Ed25519 (RFC 8463 future-proofing). Treat as a scheduled rotation but use dual-selector to avoid downtime.
• Personnel changes - an administrator with access to the signing key has left the organisation under unfriendly terms.
• Mail-platform migration - switching mail-sending platforms (for example from self-hosted Postfix to Amazon SES, or from Mailgun to SendGrid). The new platform will generate its own keypair; the rotation is an unavoidable consequence of the migration.
• Annual penetration-test finding - the pentest report flags long-lived DKIM keys as a finding. Rotation closes the finding.

The pre-condition for every emergency rotation is a documented rotation runbook (Section 5 - Dual-selector procedure - below). Operators who have never executed a rotation discover its pitfalls during an emergency, which is the worst possible time. Practice rotation at least once during quiet periods so the procedure is rehearsed before it is needed.

4. Recommended cadence by sender profile

There is no universal answer to "how often should I rotate DKIM keys". The right cadence depends on the sender's threat model, compliance regime, and operational capacity. The table below summarises the cadence recommendations for the most common operator profiles:

The cadence is independent of the key-size decision. A 2048-bit RSA key rotated quarterly and a 2048-bit RSA key rotated annually are cryptographically equivalent for the duration each is published; the difference is in the replay window and the responsiveness to a compromise. The cadence is also independent of the rotation METHOD (dual-selector vs single-selector); the canonical zero-downtime method is dual-selector regardless of cadence.

5. The canonical dual-selector rotation procedure

Dual-selector rotation is the only safe production DKIM key rotation method. It guarantees zero downtime by ensuring that at every moment of the transition AT LEAST ONE valid DKIM selector is published, so every in-flight message can be validated by the receiver.

The procedure has six discrete stages:

Stage 1: Generate the new keypair

Generate a fresh 2048-bit RSA keypair using OpenSSL or your provider's key-generation tool. The private key is stored on the signing host; the public key (in base64-encoded SubjectPublicKeyInfo DER format) goes into DNS.

# Generate the private key
openssl genrsa -out dkim-2026.key 2048

# Extract the public key in DKIM format
openssl rsa -in dkim-2026.key -pubout -outform der 2>/dev/null \
  | openssl base64 -A

The base64 output is the value that goes into the p= field of the public-key TXT record.

Stage 2: Publish the new public key under a fresh selector

Choose a new selector name. The convention is date-stamped (2026q2, jan2026, 20260521) or numbered (s2, selector2). The selector name has no cryptographic significance; it is purely a label that lets multiple keys coexist under one domain.

; New selector TXT record published in DNS:
2026q2._domainkey.example.com.   IN  TXT  ( "v=DKIM1; k=rsa; "
                                             "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                             "..continues for ~400 bytes total.."
                                             "..ends with the closing equals signs.." )

The 2048-bit RSA public key in base64 encoding is approximately 400 characters and must be split across multiple quoted strings (Section 11 Troubleshooting below).

Stage 3: Wait for DNS propagation

Wait 24-48 hours for DNS propagation. During this stage the OLD selector remains the active signing selector and the NEW selector is published but unused. The new selector is available for any receiver that fetches it but no production mail references it yet.

Verify the new public-key TXT record is reachable from external recursive resolvers before proceeding:

dig +short TXT 2026q2._domainkey.example.com @8.8.8.8
dig +short TXT 2026q2._domainkey.example.com @1.1.1.1

Stage 4: Switch the signer to use the new selector

Update the mail-signing daemon configuration to sign outbound mail with the NEW private key and reference the NEW selector in the s= tag of the DKIM-Signature header. The exact configuration change depends on the signing software:

• OpenDKIM: update the KeyTable + SigningTable files to map the sending domain to the new private key file and selector. Restart opendkim.
• Rspamd DKIM module: update the selector + path keys in dkim_signing.conf. Reload rspamd.
• Postfix milter: same as OpenDKIM but invoked via the milter socket in main.cf.
• Amazon SES / Mailgun / Postmark / SendGrid: handled by the provider's management UI; switch the active selector via the provider's web console.

Stage 5: Wait for the retention window

Wait at least 7 days (14 days is safer for high-value domains) with BOTH selectors published. This is the retention window during which any in-flight or queued mail signed with the OLD private key can still be validated by the receiver using the OLD public key. Mailing lists that re-deliver legitimate mail days after the original send, retry queues at receivers bouncing temporary errors back to disk, and archival forensic-analysis tools that fetch Authentication-Results headers all benefit from the retention window.

Stage 6: Remove the old public-key TXT record

After the retention window expires, delete the OLD selector's public-key TXT record from DNS. The OLD private key on the signing host should be wiped from disk at the same time (using shred on Linux or a comparable secure-deletion tool). Document the rotation in your key-management log: date generated, date published, date switched, date retired, reason for rotation.

The cycle repeats on the next scheduled cadence with the selectors swapping back: the next rotation generates a new key, publishes it under a fresh selector (or reuses the now-empty old selector slot if the operator prefers alternating between two names indefinitely), and the procedure runs again.

6. Single-selector hot-swap: the riskier emergency procedure

Single-selector hot-swap is the rotation method that replaces the public-key TXT record AT THE SAME SELECTOR with a new public key, while simultaneously switching the signer to use the new private key. The selector name does not change; only the published key material does.

The trade-off: zero selector-management complexity, at the cost of a 24-48 hour window during which in-flight mail signed with the OLD private key may fail DKIM validation because the receiver fetches the NEW public key from DNS and the signature does not verify against it.

The procedure has three stages:

1. Generate the new keypair (same as dual-selector Stage 1).
2. Atomically swap the published public-key TXT record at the existing selector AND the signing configuration on the signer. The DNS update and the signer-config update should happen as close together as possible - ideally within seconds.
3. Accept the 24-48 hour validation window during which messages signed with the OLD key but validated against the NEW key will fail DKIM. With a published DMARC policy of p=quarantine or p=reject, those messages may be quarantined or rejected by the receiver.

When is single-selector justified? The narrow answer is: only for emergency rotations where the security cost of leaving the old key live for the dual-selector retention window exceeds the deliverability cost of the validation window. Confirmed compromise of the private key is the canonical case - the attacker is already using the compromised key, so leaving it published in DNS for any longer than strictly necessary is unacceptable.

For every NON-emergency rotation, prefer dual-selector. The operational overhead of managing two selectors is small; the deliverability overhead of single-selector rotation is unacceptable for routine cadence work.

7. Per-provider automation: Google Workspace, Microsoft 365, Amazon SES, Mailgun, Postmark, SendGrid

Most operators do not run a self-hosted DKIM signer. The mailbox provider or transactional email service handles signing and key management. The rotation flow depends on the provider:

7a. Google Workspace

Google Workspace offers two DKIM modes: manual (the default) and Auto Key Rotation (an explicit opt-in).

• Manual: the admin uses the Admin Console at Apps > Google Workspace > Gmail > Authenticate email to generate a key, publishes the TXT record at google._domainkey (the default selector), and clicks Start authentication. The selector and key persist until the admin manually generates a new record.
• Auto Key Rotation: Google manages the keypair generation and rotation on a quarterly cadence. If the DNS provider is one Google integrates with (Cloudflare, AWS Route 53, GoDaddy, and others), the new public-key TXT record is published automatically via the DNS API; otherwise the admin receives an email notification with the new record to publish manually. The selector name rotates between a Google- chosen sequence (typically google._domainkey alternating with a fresh name).

Operator action for routine rotation: enable Auto Key Rotation and confirm the DNS integration works. After that the rotation is fully automated.

7b. Microsoft 365 (Exchange Online)

Microsoft 365 uses a dual-selector model out of the box: selector1._domainkey and selector2._domainkey, both implemented as CNAME records pointing at the tenant's onmicrosoft.com subdomain. Microsoft rotates the underlying RSA keys behind those CNAMEs on a quarterly cadence without any operator action. The operator's responsibility is to keep BOTH CNAME records published; if either is deleted, the next automatic rotation silently breaks signing because the new key is not reachable from the operator domain.

; The two Microsoft 365 DKIM CNAMEs:
selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.example.onmicrosoft.com.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.example.onmicrosoft.com.

Operator action for routine rotation: none - Microsoft handles it. Verify quarterly that BOTH CNAME records still resolve correctly.

7c. Amazon SES (Easy DKIM)

Amazon SES Easy DKIM uses three CNAME records pointing at SES-managed targets in the AWS DNS zone (amazonses.com). SES rotates the underlying keys behind the CNAMEs on a schedule managed by AWS. The operator's responsibility is to keep ALL THREE CNAME records published.

; The three Amazon SES Easy DKIM CNAMEs (example):
abc123._domainkey.example.com.  CNAME  abc123.dkim.amazonses.com.
def456._domainkey.example.com.  CNAME  def456.dkim.amazonses.com.
ghi789._domainkey.example.com.  CNAME  ghi789.dkim.amazonses.com.

7d. Mailgun

Mailgun uses a per-domain DKIM selector (typically mailo._domainkey or mta._domainkey) with manually- managed rotation. The admin generates a new key via the Mailgun control panel, publishes the new TXT record (or CNAME if delegated), and switches the signing-selector via the control panel. Mailgun does not currently offer fully automated rotation, so operators using Mailgun are responsible for the cadence themselves.

7e. Postmark

Postmark uses one DKIM keypair per Postmark server (the Postmark abstraction for a logical sending identity). The operator manages keys via the Postmark control panel; rotation is manual and requires the operator to generate a new key, publish the new TXT record, and switch the signing selector.

7f. SendGrid

SendGrid uses CNAME-delegated DKIM with selector names s1._domainkey and s2._domainkey. Like Microsoft 365, SendGrid rotates the underlying keys behind the CNAMEs on an internal cadence. The operator publishes the two CNAMEs once during initial setup and SendGrid handles rotation automatically thereafter.

8. Key size: 1024-bit vs 2048-bit vs Ed25519 (RFC 8463)

The choice of key size is the cryptographic decision that bounds the signing key's safe operating lifetime. Three options are practical in 2026:

The pragmatic recommendation for 2026: publish 2048-bit RSA as the primary algorithm AND Ed25519 as a secondary algorithm under a different selector. Most signers can sign with both keys; receivers that support Ed25519 will prefer it for the verification-cost win, and receivers that do not support Ed25519 will fall back to the RSA signature.

The transition from 1024-bit to 2048-bit (or from 2048-bit to Ed25519) is a rotation event that follows the dual-selector procedure (Section 5). The new key under a new selector is published, the signer is reconfigured to use the new algorithm, and the old algorithm's selector retires after the retention window.

9. Common mistakes

• Never rotating. The most common mistake. A DKIM key published in 2015 and never rotated is still valid until the TXT record is removed. Operators discovering a 10-year-old DKIM key in their zone should treat it as a security finding and rotate immediately.
• Rotating without dual-selector propagation. Hot-swapping the public-key TXT at the same selector at the same instant as switching the signer produces a 24-48 hour validation gap. Use dual-selector unless this is an emergency.
• Removing the old selector too early. The retention window protects in-flight mail; cutting it short produces silent body- hash failures on legitimate retries and mailing-list rebroadcasts. 7 days minimum, 14 days for high-value domains.
• Leaving 1024-bit keys live. RFC 8301 deprecated 1024-bit in 2018. Every domain with a 1024-bit DKIM key today is cryptographically exposed.
• Truncating the TXT record at 255 bytes. Some DNS provider UIs accept a 400-byte string in the input field but truncate it silently. Always verify the published record with a recursive query after publication (Section 11 Troubleshooting).
• Storing the private key in version control. Accidental commit of a DKIM private key to a public Git repository is the most common small-business compromise path. Treat the private key with the same care as a TLS private key: gitignore it, store it on the signing host only, never email it.
• Not rotating after personnel changes. An administrator who has had access to the DKIM private key continues to have that access after departure unless the key is rotated. Treat administrator departures as a rotation trigger.
• Skipping the rehearsal. First-time rotations often hit unexpected issues (TXT-record splitting, signer config syntax, propagation timing). Practice rotation at least once during a quiet period so the procedure is rehearsed before an emergency requires it.
• Not documenting the rotation log. Auditors will ask. Maintain a log of every rotation: date, reason, old selector, new selector, retention-window dates, validator used to confirm publication.
• Forgetting subdomains. If the parent domain publishes DKIM and a marketing subdomain publishes its own DKIM under a separate selector, BOTH need to be rotated. The most common omission is forgetting that news.example.com has its own selector.

10. Troubleshooting common rotation failures

10a. The 255-byte TXT record limit

A single character-string within a DNS TXT record is limited to 255 bytes by RFC 1035. A 2048-bit RSA public key encoded in base64 produces approximately 400 characters that cannot fit in one string. The standard solution is to split the value across multiple quoted strings within ONE TXT record:

; CORRECT: multi-string TXT record (concatenated by the resolver)
2026q2._domainkey.example.com.  IN  TXT  ( "v=DKIM1; k=rsa; "
                                            "p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."
                                            "..middle 255 bytes.."
                                            "..final bytes ending in equals signs.." )

The pitfall is DNS provider UIs that accept a 400-byte string in the input field but silently truncate at 255 bytes when storing. Always verify the published record:

dig +short TXT 2026q2._domainkey.example.com @8.8.8.8
# Expected output: a SINGLE record with multiple strings,
# concatenated as: "v=DKIM1; k=rsa; p=MIIBIjAN..." (400 chars total)

If the output shows only the first 255 characters, the provider truncated. Workarounds:

• Use a different DNS provider (most modern providers handle multi-string TXT correctly).
• Provide the record via the provider's API with explicit string-splitting (bypassing the UI truncation).
• Use Ed25519 DKIM (RFC 8463) which produces ~43-character public keys that fit in one string trivially.

10b. Body-hash failures during the transition

A DKIM signature includes a hash of the canonicalised message body. If the receiver fetches the WRONG public key during a rotation transition (for example, the new public key but the signer used the old private key), the body-hash check passes but the signature check fails - producing a DKIM result of signature mismatch or bodyhash mismatch.

Mitigation: the dual-selector procedure (Section 5) avoids this by keeping both keys published and active during the transition. Single-selector hot-swap (Section 6) accepts a 24-48 hour window where this happens; the operator must accept that some in-flight mail will fail.

10c. ARC chain breakage during the transition

Authenticated Received Chain (RFC 8617) preserves upstream DKIM verdicts across forwarding hops by signing the original DKIM result with the forwarder's ARC key. If a forwarder has cached the OLD DKIM public key and validates an in-transit message using that cache, the ARC seal records a "pass" verdict that downstream receivers may treat as authoritative even after the OLD key is retired. The practical effect is minimal because ARC is consultative (downstream receivers can re-verify against the current DNS state), but operators rotating heavily- forwarded mail (mailing-list subscribers, Microsoft 365 distribution-list rewrites) should add a small extra retention buffer.

10d. Body-hash failures from canonicalization mismatch

DKIM has two canonicalization modes for the body: simple (preserves whitespace) and relaxed (collapses repeated whitespace). A rotation that changes the canonicalization mode (rare but possible if the signer is replaced as part of the rotation) can produce body-hash failures even when the public-key TXT record is published correctly. Verify the signer's canonicalization mode before and after the rotation; keep it consistent.

10e. Public key publication verified, signatures still fail

If dig confirms the public key is correctly published and reachable from external resolvers but DKIM signatures still fail, the most common remaining cause is that the SIGNER is using a different selector or different private key than the operator expects. Inspect the DKIM-Signature header on an outbound test message:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
    d=example.com; s=2026q2;
    h=from:to:subject:date; ...

The s= tag MUST match the selector name published in DNS. If it does not, the signer is misconfigured.

11. Frequently asked questions

How often should I rotate DKIM keys?

The industry baseline is annual rotation for production DKIM signing keys, with shorter cadences (3-6 months) for high-value brand domains and immediate rotation on suspicion of key compromise. Most managed providers (Google Workspace Auto Key Rotation, Microsoft 365 selector1 / selector2 alternation, Amazon SES Easy DKIM automatic rotation) handle rotation automatically on a quarterly to annual cadence; self-hosted DKIM signing requires explicit operator-managed rotation.

What is dual-selector DKIM rotation?

Dual-selector rotation is the canonical zero-downtime DKIM key rotation procedure. The operator publishes a new public key under a fresh selector while the old selector remains live. After the new selector propagates the signer is switched to the new selector; the old selector then stays published for at least 7 days so in-flight mail can validate, after which the old selector is removed.

Why should I upgrade from 1024-bit to 2048-bit DKIM keys?

RFC 8301 (January 2018) deprecated 1024-bit RSA DKIM signing keys and mandated 2048-bit RSA minimum. The 2012 Zach Harris research project demonstrated 1024-bit DKIM keys were factorable at sub-thousand-dollar cost; the economics have only improved since.

What happens when a DKIM key is compromised?

A compromised DKIM private key lets the attacker sign arbitrary messages under the victim domain that pass DKIM authentication. The mitigation is immediate emergency rotation: generate a fresh keypair, publish the new public key under a new selector, switch the signer to the new selector, and remove the compromised public key from DNS within hours.

Does Google Workspace rotate DKIM keys automatically?

Google Workspace offers an Auto Key Rotation feature that periodically generates a new DKIM keypair and publishes the new public key via DNS-API integration or manual TXT publication. Default cadence is quarterly.

Does Microsoft 365 rotate DKIM keys automatically?

Microsoft 365 uses a dual-selector model (selector1 and selector2) with automatic quarterly alternation. The selectors are CNAME records pointing at the tenant onmicrosoft.com domain; Microsoft rotates the underlying keys behind the CNAMEs automatically as long as both CNAMEs remain published.

What is the 255-byte TXT record limit and why does it affect DKIM?

A single character-string within a DNS TXT record is limited to 255 bytes by RFC 1035. A 2048-bit RSA public key in base64 produces about 400 characters that must be split across multiple quoted strings within one TXT record. Some DNS provider UIs silently truncate, producing a corrupted published key - always verify with a recursive query.

How long should the old DKIM selector stay published after rotation?

The conservative answer is 7 days plus the longest known receiver DKIM cache TTL. Most operators keep the old selector for 7-14 days. After the retention window the old public-key TXT record is removed.

12. Related guides

• DKIM explained - the DKIM pillar covering DNS syntax, selectors, canonicalization, signature verification, and the broader DKIM deployment context. Start here if DKIM is new to you.
• DMARC for cPanel - the CPANEL-EXIM-DKIM-SIGNER-MANAGED- KEY-LIFECYCLE-VS-MANUAL-OPERATOR-MANAGED- KEY-LIFECYCLE-AT-CONTROL-PANEL-BOUNDARY companion to this DKIM key-rotation operational reference. Where THIS page documents the generic 90-day-cadence dual-selector zero-downtime rotation procedure (the selector1 → selector2 swap, the TTL-bounded overlap window, the seven rotation-induced failure modes), the DMARC-for-cPanel spoke is the SHARED-HOSTING-CONTROL-PANEL companion documenting the STRUCTURALLY-CONSTRAINED rotation surface at the cPanel / Exim-DKIM-Milter / WHM-managed-key boundary: (i) the cPanel WHM "Email Deliverability" wizard issues a SINGLE DKIM selector (typically default._domainkey) per customer domain at provisioning — the dual-selector zero-downtime rotation procedure THIS page documents requires the operator to manually edit /var/cpanel/domain_keys/ private/<domain> and publish a SECOND selector via cPanel's DNS Zone Editor (or via WHM's DNS Functions API), an operator-side step the customer cannot perform through the normal cPanel UI; (ii) cPanel's Exim-DKIM-Milter reads ONE private-key file per domain at MTA-start time, which means the rotation playbook on cPanel typically requires an Exim restart (or a SIGHUP) after switching the active private-key file — distinct from the rotation cadence on a self-managed MTA where the operator can dual-sign with both selectors during the overlap window; (iii) cPanel multi-tenant shared-IP egress amplifies the rotation- induced replay-risk window — a delayed selector rotation on cPanel leaves a stale key in the DNS zone for longer than a single-tenant operator would tolerate, and any DKIM-replay attack against the stale selector spreads its damage across the shared-IP-pool's reputation footprint, not just the originating customer's domain; (iv) the cPanel provider's centralized rotation policy (if any) imposes a provider-defined rotation cadence at the provider-managed-key layer that may be coarser than the 90-day cadence this page recommends — customers whose cPanel provider rotates the provider-pooled keys quarterly or semi-annually inherit that provider-cadence as the FLOOR of the customer's own rotation discipline. Read the DMARC-for- cPanel spoke alongside this rotation playbook when planning a DKIM-key-rotation runbook for a cPanel-hosted customer portfolio, when investigating "why did the rotation cause downtime on cPanel when it was zero-downtime on our self-managed MTA", or when the provider announces a forced-rotation event the customer must coordinate with.
• DKIM selectors explained - the selector address-space deep dive the rotation procedure on this page walks through. The eight canonical selector naming patterns (numbered / dated / provider / short-letter / opaque / purpose / domain-prefix / hosted-prefix) govern HOW you name selector1 / selector2 for the dual-selector zero-downtime swap; the seven failure modes (NXDOMAIN / wrong-name / stale / 255-byte / CNAME-vs- TXT / wildcard / propagation) name the specific drift classes a rotation can introduce. Read alongside this page when planning a rotation naming convention.
• DKIM DNS record syntax (TXT-record byte reference) - the byte-by-byte reference for the public-key TXT record this rotation procedure publishes at the new selector's <selector>._domainkey.<d-domain> label. Where THIS page documents the rotation procedure (the selector1 → selector2 dual-selector zero-downtime swap, the 90-day cadence, the per-provider rotation automation), the DNS-syntax page documents the byte-level rules the NEW TXT record must satisfy when you publish it: the v=DKIM1 version-tag floor, the k=rsa / k=ed25519 algorithm tag (the rotation event is the natural time to migrate from 1024-bit RSA to 2048-bit RSA per RFC 8301 — or to Ed25519 per RFC 8463), the p=<base64-public-key> tag carrying the DER-encoded SubjectPublicKeyInfo of the new key, the p=-empty revocation signal you publish to RETIRE the old selector after the dual-active window (RFC 6376 §3.6.1 — distinguishes deliberate revocation from accidental deletion), the 2048-bit-floor split- string TXT-record concatenation rule (Cloudflare auto-splits, GoDaddy requires manual 255-byte chunking, BIND requires the ("..." "...") concatenation form — the #1 silent- rejection cause when a registrar UI truncates the new public key at the 255-byte boundary without splitting, triggering a fresh dkim=permerror wave right after the rotation), the optional t=y testing- mode flag for the burn-in window before flipping the signer over, the t=s strict-alignment flag, and the legacy g= granularity / h= hash- restriction / n= notes / s=* service-type tags. Read this page when authoring the new TXT record for the rotation target selector — every byte-level constraint documented here is a potential silent-rejection cause that will surface as a fresh dkim=permerror wave at the receiver if the new record is published incorrectly.
• DNS propagation explained - the KEY-ROTATION-OVERLAP-WINDOW-BOUNDED- BY-DNS-TTL-PROPAGATION companion reference. Where THIS page documents the rotation PROCEDURE (the selector1 → selector2 dual-selector zero-downtime swap, the 90-day cadence, per-provider rotation automation, the p=-empty revocation signal published to retire the old selector after the dual-active window), the DNS-propagation spoke documents the STRUCTURAL TIMING-MODEL the rotation procedure's overlap window MUST be sized against: DNS propagation is a TTL-bounded recursive-resolver-cache aging phenomenon, not a server-side propagation wave — when the operator publishes the new selector2._domainkey.<d> TXT and later deletes the old selector1._domainkey.<d> TXT (or republishes it with p=-empty as a revocation signal), the WINDOW during which in-flight signed mail with the OLD selector continues to verify at receivers is bounded by the OLD selector's previously-cached TTL at every recursive resolver that has resolved the selector name in the prior window. The implication: the dual-active overlap window length this page prescribes (typically 7-14 days at standard 3600s TTL, or 24-48 hours at short 300s TTL for emergency-rotation scenarios) is the OPERATIONAL EXPRESSION of the TTL-bounded resolver-cache aging model the DNS-propagation spoke documents — and operators who shorten the TTL on the DKIM TXT record BEFORE rotation (per the spoke's email-auth-TTL-recommendation of 300s for DKIM keys being actively rotated, vs 3600s for stable records) compress the overlap window from weeks to hours, which is the canonical emergency-rotation pattern (compromised private key, breach response, compliance-mandated key replacement). Conversely, operators who LEAVE the TTL at the typical 86400s legacy default lock themselves into a 24-hour-minimum overlap window per rotation, which is incompatible with the 90-day rotation cadence's operational economics. Read the DNS-propagation spoke alongside this page when planning a rotation TTL strategy — the rotation overlap window and the per-record TTL are NOT independent operational variables; the TTL choice DETERMINES the minimum viable overlap window, and the emergency-rotation use case STRUCTURALLY REQUIRES the TTL to have been pre-shortened well in advance of the actual rotation event.
• DANE explained (RFC 7672 DANE-for-SMTP) — the DKIM-PUBLIC-KEY-DNS-PUBLICATION- LIFECYCLE-VS-DANE-TLSA-CERTIFICATE-HASH- DNS-PUBLICATION-LIFECYCLE-STRUCTURALLY- ANALOGOUS-ROTATION-DISCIPLINE companion reference. Where THIS page documents the DKIM-public-key-record rotation procedure (the <selector>._domainkey. <d> TXT record holding the Base64-encoded public-key, the dual-selector zero-downtime swap pattern, the TTL-bounded overlap window, the 6-to-12-month rotation cadence per RFC 6376 §3.3, the emergency-rotation incident-response protocol), the DANE-explained spoke documents the STRUCTURALLY-ANALOGOUS DANE TLSA-record certificate-hash- publication-lifecycle at the DNS-RR layer. The PARITY is at the DNS-record- rotation-discipline level: both protocols publish cryptographic material (DKIM public-key OR DANE TLSA cert/hash) in DNS-RR form, both require a key/cert-rotation cadence to bound the blast-radius of compromise, both depend on DNS-TTL mechanics to bound the overlap window between OLD and NEW record publication, both have an emergency-rotation use case that requires the TTL to have been pre- shortened in advance of the actual rotation event, both support dual- publication overlap patterns (DKIM: selector1 + selector2 simultaneously published; DANE: dual TLSA RRset with OLD + NEW certificate-hash co- published). The structural difference is that DANE TLSA records REQUIRE the authoritative DNS zone to be DNSSEC- signed (the trust-model anchor is DNSSEC, not X.509-PKI), whereas DKIM public-key records do NOT require DNSSEC (the trust-model anchor is per-signature cryptographic verification). Read this when planning a parallel DNS-RR rotation discipline for a DNSSEC-signed zone that publishes both DKIM-public-keys and DANE-TLSA-records — the rotation cadence, dual-publication overlap pattern, TTL-bounded propagation discipline, and emergency-rotation protocols documented for DKIM on THIS page are structurally analogous to the equivalent DANE TLSA-rotation discipline the DANE- explained spoke documents.
• TLS-RPT report format (RFC 8460 §4 JSON schema deep dive) — the DKIM-ROTATION-OVERLAP-WINDOW-OPERATIONAL-ANALYTICS-CONSUMER-OF-PER-RUA-WINDOW-TLS-RPT-JSON-AGGREGATE-REPORTS companion documenting the per-field JSON schema ("organization-name" / "date-range" / "policies" with "summary"+"failure-details" sub-records) of the aggregate JSON report receivers serialize per RFC 8460 §4 schema, whose per-failure-record consumption is the load-bearing operational-analytics input the DKIM-rotation operator depends on when verifying the rotation overlap window did not coincide with a transport-layer-anomaly that could mask the per-selector aligned-pass-rate contribution, across FOUR DKIM-rotation-window TLS-RPT-JSON-consumer dimensions: (1) Per-RUA-window summary.total-failure-session-count baseline during the dual-selector overlap window as transport-confound exclusion signal — when the operator stages the dual-selector publication (sel-old._domainkey + sel-new._domainkey BOTH publishing during the TTL-bounded overlap), the per-RUA-window TLS-RPT aggregate summary establishes the transport-layer failure baseline; a baseline-level failure-count rules out transport-layer confounding of the rotation aligned-pass-rate contribution, while a failure-spike requires pausing the rotation cutover until the transport anomaly is investigated; (2) Per-RUA-window failure-details[].sending-mta-ip correlation with publisher-side DKIM signer-IP during the rotation window — the JSON per-failure-record sending-mta-ip identifies the SMTP client IP that initiated the downgrade-affected session; correlating this IP against the publisher's known DKIM signer IPs (Postfix / SES / Sendgrid / etc.) during the rotation overlap window discriminates between transport-tampering by a downstream receiver (operational concern but does not block rotation) and downgrade affecting the publisher's own signer infrastructure (which DOES block rotation cutover); (3) Per-policy policy.policy-string[] byte-content verification at the rotation cutover boundary — the JSON per-policy-string array contains the verbatim MTA-STS or DANE policy lines the receiver fetched; verifying the JSON-reported policy-string matches the publisher's canonical policy at the cutover boundary rules out adversarial policy-interception coinciding with the rotation event (a known attacker tactic against well-publicised rotation windows); (4) Per-day summary.total-success-session-count trend at the post-rotation steady-state as rotation-success acceptance signal — the RFC 8460 §4.3 per-policy summary integer fields establish the post-rotation steady-state baseline (transport-layer success-session-count back to baseline); sustained baseline-level success-counts across the 14-day post-cutover window signals successful rotation absent transport-layer confounds. The JSON-report-consumption across these four dimensions is the load-bearing transport-layer-confound-exclusion analytics the DKIM rotation operator depends on when committing to the rotation cutover this page documents.
• CAA records explained — the CAA-DNS-BASED-PKI-PUBLICATION-AS- STRUCTURALLY-PARALLEL-DISCIPLINE-TO-DKIM- PUBLIC-KEY-DNS-PUBLICATION companion reference. Where THIS page documents the DKIM-public-key-record rotation procedure (the <selector>._domainkey.<d> TXT record holding the Base64-encoded public-key, the dual-selector zero- downtime swap pattern, the TTL-bounded overlap window, the 6-to-12-month rotation cadence per RFC 6376 §3.3, the emergency-rotation incident-response protocol), the CAA-records-explained spoke documents the STRUCTURALLY- PARALLEL CA-issuance-authorisation publication at the apex (or sub-domain) owner-name, whose four-dimensional record-lifecycle discipline mirrors the DKIM-record rotation discipline this page documents: (i) CAA records at the apex are the parallel PKI-policy- publication-at-DNS to DKIM public-key publication at selector._domainkey — both publish operator-controlled cryptographic-authorisation information in DNS-RR form for cross-organisation consumption (DKIM by mail receivers verifying signatures; CAA by certificate authorities verifying issuance authorisation), (ii) the CAA-record- rotation lifecycle (adding a new CA via issue "new-ca.example", bedding it in across the receiver-CA population, retiring the old CA via directive removal) parallels DKIM-key- rotation lifecycle (adding selector2, bedding it in across the receiver population, retiring selector1 via TXT- record removal) — both follow the DNS- RR add-then-remove discipline with a TTL-bounded overlap window, (iii) DNS TTL discipline governs both CAA and DKIM record propagation (RFC 1035 + RFC 2181 + RFC 8767 serve-stale apply symmetrically), so the cache-aging analysis the dual-selector overlap- window calculation this page documents applies analogously to CAA-rotation overlap-window calculation upstream of certificate-issuance attempts at all contacting CAs, and (iv) CAA issue ";" (no-issuance lockdown — the publisher explicitly forbids issuance from any CA) parallels DKIM p= empty-tag revocation (the publisher explicitly revokes the key without removing the record) — both are DNS-record- publication-deactivation patterns that preserve the record's existence as an explicit-prohibition signal rather than a silent-absence. Read the CAA-records- explained spoke alongside this page when designing a unified DNS-RR- publication-discipline across the application-authentication-key- publication (DKIM) AND PKI-issuance- authorisation-publication (CAA) record- classes — the rotation cadence, dual- publication overlap pattern, TTL- bounded propagation discipline, and emergency-revocation protocols documented for DKIM on THIS page are structurally parallel to the equivalent CAA-rotation discipline the CAA-records- explained spoke documents.
• DKIM canonicalization explained (simple vs relaxed) - the byte-level header-and-body normalisation layer that survives every rotation: swapping selector1 for selector2 in the dual-selector zero-downtime procedure documented on this page keeps the c= tag stable (simple/simple, simple/relaxed, relaxed/simple, or relaxed/relaxed), but a rotation is also the natural time to standardise on c=relaxed/relaxed if the prior selector defaulted to simple/simple and your receivers have been logging body-hash mismatches against forwarders or mailing-list infrastructure. Covers RFC 6376 section 3.4 (the two header algorithms per sections 3.4.1 and 3.4.2, the two body algorithms per sections 3.4.3 and 3.4.4, the four c= tag combinations), the optional l= partial-body- length tag with its replay-amplification trade-off (avoid in production), the seven most common body-hash mismatch causes, and the per-provider canonicalization defaults for Microsoft 365, Google Workspace, Amazon SES, SendGrid, Mailgun, Postmark, SparkPost, OpenDKIM, Postfix dkim-milter, and Exim DKIM. Pair with this rotation guide when migrating from 1024-bit RSA to 2048-bit RSA or to Ed25519 — the new selector is the natural place to also set c=relaxed/relaxed if not already.
• DMARC alignment explained - the alignment rules that determine whether a passing DKIM result also satisfies DMARC. A failed DKIM rotation produces a DKIM=fail outcome that may or may not affect DMARC depending on whether SPF is also aligned.
• DKIM alignment with DMARC — the DKIM-side alignment procedural deep dive (the KEY-LIFECYCLE-SURFACES-ALIGNMENT-FAILURES companion to this rotation reference) - the KEY-LIFECYCLE-SURFACES-ALIGNMENT-FAILURES companion documenting the DKIM-side alignment rules that key-rotation events repeatedly stress. Where THIS page is the rotation cadence reference (the 6-month rotation cycle, the overlap-window protocol where old and new selectors both serve briefly, the rotation triggers from DKIM-replay attack-research findings, the selector1 / selector2 dual-selector pattern, the k=rsa vs k=ed25519 algorithm migration step, the staged DNS-TTL countdown), the DKIM-alignment-with-DMARC spoke is the IDENTIFIER-ALIGNMENT REFERENCE whose verdict every individual rotation step SURFACES failures against. Key-rotation events surface DKIM-DMARC alignment failures in FIVE characteristic ways the cross-reference makes explicit: (i) old-selector retirement before rotation-overlap expiry — retire selector1 too early and in-flight messages signed-but-not-yet-delivered with the old key arrive at receivers as DKIM=fail, breaking the d=-aligned-with-From identifier check; (ii) new-selector publication before signing-rotation — publish the new public key in DNS but rotate signing too late, leading to new-key-signs-old-public-key DKIM=permerror; (iii) third-party-sender CNAME-delegated rotation drift — when a SaaS sender rotates its key but the customer's CNAME at selectorN._domainkey.customer.com still points to the previous selector record, the SaaS-signed messages arrive DKIM=fail against the customer's published DNS, breaking DKIM-aligned-with-DMARC posture for that SaaS sender; (iv) algorithm migration alignment regression — rotating from k=rsa to k=ed25519 can momentarily break DKIM verification at receivers whose verifier doesn't yet support Ed25519, even though the d= identifier alignment would have passed had the signature verified; (v) DKIM-replay-driven rotation cadence affects alignment posture durability — short rotation cadence is the operational countermeasure for the DKIM-replay threat where a captured signed message is re-injected with the original DKIM-aligned identifier intact for hours-to-days until the rotation invalidates the captured signature. Operators landing here for rotation cadence need the DKIM-alignment-with-DMARC procedural companion to understand which rotation outcomes the downstream DMARC verdict will surface.
• DMARC record tags explained - every tag in the DMARC DNS record. The p= tag determines the receiver action when a DKIM rotation produces a DKIM=fail outcome.
• DMARC troubleshooting - the operational diagnostic guide for DMARC failures including DKIM body-hash failures during rotation.
• DMARC forensic reports (RUF / AFRF) — the DKIM-KEY-ROTATION-CYCLE-AS-PER- MESSAGE-SIGNATURE-MISMATCH-RUF-AFRF- EVIDENCE-WINDOW companion to this DKIM rotation-cadence reference. Where THIS page documents the dual-selector 90-day zero-downtime rotation procedure operators execute against the DKIM key-lifecycle surface, the DMARC-forensic-reports spoke is the per-message AFRF / IODEF evidence- stream reference documenting the RFC 7489 §B.2 / RFC 6591 forensic-report channel whose per-message message/rfc822 embedded-part preservation is the FORENSIC-GRAIN artifact the incident- response team needs when a key-rotation cycle produces unexpected signature- mismatch verdicts at receivers. The DKIM-KEY-ROTATION-CYCLE-AS-PER-MESSAGE- SIGNATURE-MISMATCH-RUF-AFRF-EVIDENCE- WINDOW cross-reference establishes FOUR structurally-distinct rotation-phase-vs- RUF-AFRF-evidence-stream dimensions: (i) dual-selector-publish-phase-RUF- evidence-stream-baseline dimension — at the start of the rotation cycle THIS page documents the operator publishes BOTH the new selector AND keeps the old selector published; the RUF AFRF stream during this phase establishes the per-receiver baseline-verdict-distribution the operator's incident-response team reconciles future-phase RUF evidence against; (ii) signing-switchover- phase-RUF-evidence-stream-spike-detection dimension — the rotation cycle THIS page documents includes a hard cutover from old-selector signing to new- selector signing; a signature-mismatch RUF AFRF spike concentrated in the switchover window is the canonical signal that a receiver-side resolver cache retained the OLD selector's public key beyond its TTL — the per-message AFRF envelope's embedded message/rfc822 part preserves the EXACT bytes of the new-selector DKIM-Signature header the receiver could not verify, enabling the operator's incident-response team to attribute the spike to the per-receiver- resolver-cohort cache-retention behaviour rather than a publisher-side error; (iii) old-selector-revocation-phase-RUF- evidence-stream-permerror-trigger- detection dimension — at the completion of the rotation cycle THIS page documents the operator removes the OLD selector's public-key TXT record; the RUF AFRF stream during this phase produces structurally-distinct permerror verdicts (the receiver-side resolver returns NXDOMAIN for the now-deleted old-selector key) that the operator's incident-response team uses to detect stragglers — senders / forwarders / cache-retained messages still emitting DKIM-Signature headers referencing the revoked selector after the publish- window-bounded grace period; the per- message AFRF embedded message/rfc822 part preserves the offending byte-exact signature reference; (iv) emergency- key-compromise-revocation-RUF-evidence- stream-attacker-traffic-attribution dimension — outside the planned rotation cycle THIS page documents, an emergency key-compromise event requires immediate revocation; the per-message AFRF RUF stream during this period captures the attacker's USE of the compromised key (the per-message embedded message/rfc822 part contains the attacker-injected DKIM-Signature header with the legitimate d=<org> tag plus the compromised selector's value), providing the forensic evidence the SIRT correlates with the IP-routing-origin metadata to attribute the attacker-traffic for criminal-prosecution under 18 U.S.C. §1030 (Computer Fraud and Abuse Act). Read this RUF-forensic-reports spoke alongside THIS DKIM-key-rotation reference when authoring the per-rotation-cycle incident-response playbook that uses the per-message AFRF evidence stream as the forensic-grain artifact for stale-cache / straggler-detection / emergency-revocation triage during each phase of the rotation cycle the THIS-page-documented dual- selector procedure orchestrates.
• DMARC aggregate (RUA) reports — the DKIM-KEY-ROTATION-CADENCE-AS- PER-SELECTOR-PER-DAY-RUA-AGGREGATE- EVIDENCE-CONTINUITY-OBSERVABILITY- SURFACE companion to this DKIM-key- rotation operational reference. Where THIS page documents the per-tenant dual-selector rotation procedure (the cadence selection, the per-phase active-vs-standby selector assignment, the atomic per-message s= tag-value cutover, the stale-key-cache observation window, the emergency- revocation discipline), the DMARC- aggregate-reports spoke documents the RFC 7489 §7.2 XML aggregate-report schema at four per-rotation-phase-to- per-RUA-evidence-continuity coupling dimensions: (i) per-phase per- selector per-day per-row count distribution as rotation-cadence observability surface — the per-row <auth_results><dkim><selector> evidence catalogued in the RUA XML schema partitions the per-tenant per- author-domain per-receiver per-day per- row count by per-message s= tag-value the per-tenant rotation procedure THIS page documents emits; the per-day per-selector per-row count distribution IS the empirical surface the rotation-cadence operator observes to confirm the dual-selector cutover completed correctly (pre-cutover: s=selectorA dominant; cutover boundary: mixed; post-cutover: s=selectorB dominant); (ii) per-receiver per-selector per-day DKIM-aligned-pass- rate as rotation-cache-staleness attribution dimension — the per-tenant DNS publication of the new per-selector TXT record THIS page documents the operational discipline of propagates across the per-receiver recursive-resolver caches at different cadences (some receivers cache for 15min, others for 1h, others for 24h per the TXT TTL); the per-receiver per- selector per-day DKIM-aligned-pass-rate the DMARC-aggregate-reports spoke documents the XML schema for IS the attribution dimension that surfaces stale-cache-defect attribution per- receiver per-selector at the per-day per-row granularity; (iii) per- tenant rotation-phase advancement gate as per-selector per-day DKIM-aligned- pass-rate-baseline driven — the canonical multi-phase rotation cadence THIS page documents (publish new selector → wait for propagation → atomic cutover → wait for stale-cache drain → revoke old selector) is gated on a per-selector per-receiver DKIM-aligned-pass-rate baseline (≥99% legitimate-mail-pass on the new selector at every receiver) observed in the RUA-aggregate-report row stream the DMARC-aggregate-reports spoke documents the schema of — without the per-row per-selector evidence the rotation operator CANNOT empirically confirm the cutover-and-revocation gates have been satisfied; (iv) per-tenant emergency-revocation per-day RUA-aggregate-report-stream delta as compromise-incident observability surface — the per-tenant key-compromise emergency- revocation procedure THIS page documents (immediate per-selector key-rotation ahead of the regular cadence, per- receiver TXT-TTL-driven cache-drain wait, residual stale-cache-attacker- signature tail-off) is empirically observed at the per-tenant DMARC RUA aggregate-report stream as a per-day per-selector per-row distribution delta — the DMARC-aggregate-reports spoke documents the per-row schema the incident-response team uses to attribute per-receiver per-day residual attacker-signed traffic before the per-receiver cache-TTL expires. Read the DMARC-aggregate- reports spoke alongside this DKIM- key-rotation reference when the per- tenant operator is designing the per-rotation-phase advancement discipline whose empirical evidence stream lives in the RFC 7489 §7.2 XML aggregate-report row stream the DMARC-aggregate-reports spoke documents the byte-by-byte schema of.
• How attackers bypass weak DMARC - the security-research catalogue including DKIM 1024-bit factoring + DKIM replay attacks that motivate rotation.
• DKIM replay attacks explained - the dedicated deep dive on the DKIM-replay threat class — the canonical operational motivation for the short rotation cadence documented in this guide. The replay-attack page documents WHY long-lived DKIM keys are a deployment risk independent of crypto strength: an attacker who captures a single legitimately-signed message can re-send it to arbitrary recipients (different envelope, same signed headers + body) and the signature remains valid until either the key rotates OR the (new and recommended) RFC 9103 x= expiration tag lapses. Read this when prioritising your rotation cadence against the threat model — the "90-day-rotation-or-sooner" recommendation on this page is grounded in the replay-window math documented in the replay-attacks page.
• DKIM cryptography basics - the cryptographic-foundation deep dive that grounds the key-size and algorithm choices this rotation guide names. Where this page tells you when to rotate and how to rotate (the dual-selector zero-downtime procedure, the 90-day cadence, the per-provider automation), the cryptography-basics page tells you what you should be rotating to and why: 2048-bit RSA as the operational minimum (1024-bit RSA falls inside the projected NIST 2030 deprecation deadline and the academic 768-bit factoring milestone projects forward), Ed25519 elliptic-curve signing (RFC 8463) as the next-generation algorithm with smaller keys (32-byte private + 32-byte public) and equivalent ~128-bit security to 3072- bit RSA, SHA-256 as the only valid hash algorithm (SHA-1 is formally deprecated by RFC 8301 — every rotation should also verify the existing a= tag is not rsa-sha1), and the 255-byte TXT-record split rule that determines whether a 2048-bit key fits in one record or needs the multi-string TXT representation. Pair with the DKIM pillar for the protocol mechanics and DKIM replay attacks for the threat model.
• DKIM best practices - the consolidated operational-defaults sibling spoke. The rotation cadence and dual-selector swap procedure on this page are TWO entries in a broader best-practices list that also includes the 2048-bit RSA / Ed25519 algorithm floor (RFC 8301 + RFC 8463), the c=relaxed/relaxed canonicalisation default, the l= tag avoidance (length- limited signatures are trivially body- extended after capture), the RFC 9103 x= expiration tag adoption, the selector-naming conventions that survive rotation, and the alignment prerequisites (d= must match the organisational domain of From: per RFC 7489 §3.1.1). Read alongside this rotation guide when codifying your team's DKIM standard operating procedure — rotation cadence without the broader best-practices context tells operators when to rotate but not what they should be rotating to or what other defaults the rotation should re-confirm.
• DMARC for Google Workspace - the Workspace deployment guide including the Auto Key Rotation feature.
• DMARC for Microsoft 365 - the M365 deployment guide including selector1 + selector2 automatic alternation.
• DKIM for Microsoft 365 — the M365-TENANT-DKIM-SELECTOR-1-AND- SELECTOR-2-DUAL-SELECTOR-CNAME- PUBLICATION-AS-THE-CANONICAL-M365-CLOUD- IMPLEMENTATION-OF-THE-DUAL-SELECTOR- ZERO-DOWNTIME-ROTATION-PROCEDURE companion to this DKIM-key-rotation operational reference. Where THIS page documents the canonical dual-selector zero-downtime DKIM rotation procedure (new-selector publication + overlap- window key-availability + old-selector empty-p= retirement + rotation cadence floor) at the provider-agnostic operational granularity, the dkim_for_microsoft_365 spoke is the M365-TENANT-DKIM-PUBLICATION canonical cloud-specific implementation reference documenting the FOUR M365-DKIM-rotation- vs-canonical-dual-selector-discipline coupling dimensions: (i) M365 selector1/selector2 dual-selector CNAME publication as the canonical M365-cloud implementation of the dual-selector zero-downtime rotation primitive — the per-tenant selector1-<tenant>. _domainkey + selector2-<tenant>. _domainkey CNAMEs pointing at Microsoft-managed onmicrosoft.com hostnames ARE the canonical M365-cloud instantiation of the dual-selector publication discipline THIS page documents at the provider-agnostic operational level — the M365-tenant operator interacts with the dual- selector rotation primitive via the Microsoft-managed CNAME-publication topology rather than directly authoring per-selector TXT-records; (ii) Rotate-DkimSigningConfig PowerShell cmdlet orchestration as the M365-tenant operator interface to the per-tenant rotation discipline — the M365-tenant operator orchestrates the selector1-to-selector2 cutover via the Rotate-DkimSigningConfig -KeySize 2048 PowerShell cmdlet (Exchange Online PowerShell module), which Microsoft-side automates the per-tenant key generation + selector cutover + overlap-window orchestration the canonical dual-selector rotation procedure on THIS page describes at the provider-agnostic operational level — the M365-tenant operator does NOT manually publish TXT-records per rotation step but instead invokes the Microsoft-managed cmdlet whose internal orchestration mirrors the canonical rotation primitives; (iii) M365 default 1024-bit RSA legacy-default-key-strength as the per- tenant cryptographic-foundation-upgrade prerequisite to modern rotation discipline — the M365 legacy default DKIM key-strength is 1024-bit RSA (deprecated per RFC 8301 §3); the per-M365-tenant operator's FIRST rotation execution should be the cryptographic-foundation upgrade to 2048-bit RSA via the Rotate-DkimSigningConfig -KeySize 2048 cmdlet BEFORE adopting the steady-state rotation cadence THIS page documents at the provider- agnostic operational level; (iv) per-M365-tenant d=-tag identity preservation across selector1-to- selector2 rotation cutover as the canonical DKIM-aligned-pass- preservation discipline — the per-M365-tenant rotation MUST preserve the d=-tag value at the protected vanity domain across the selector1-to-selector2 cutover (the canonical DKIM-side identifier- alignment-preservation discipline this page documents at the d=-tag- invariance level); the M365 cmdlet orchestration preserves this invariance Microsoft-side, but the per-tenant operator MUST verify the per-message DKIM-Signature d=-tag emission matches the protected vanity domain by inspecting receiver-side Authentication-Results headers AFTER the rotation cutover completes. Read the dkim_for_microsoft_365 spoke as the M365-cloud-specific implementation reference whenever the rotation discipline THIS page documents applies to an M365-tenant DKIM deployment.
• DMARC for hybrid Exchange (on-premises + Exchange Online) — the HYBRID-EXCHANGE-DUAL-SIGNER-DKIM- ROTATION-COORDINATION-AS-MULTI-LOCATION- KEY-LIFECYCLE-DISCIPLINE-CONSUMER companion to this DKIM-key-rotation operational reference. Where THIS page documents the canonical operator-controlled dual-selector zero-downtime rotation procedure (the selector1 → selector2 swap, the TTL-bounded overlap window, the publish-new-key → wait-for-propagation → switch-active-signer → retire-old-key sequence) — i.e. the DKIM-KEY-LIFECYCLE- OPERATIONAL-DISCIPLINE side of the DKIM deployment protocol — the DMARC-for-hybrid- Exchange spoke is the HYBRID-EXCHANGE-DUAL- SIGNER-CONSUMER companion documenting how that rotation discipline gets coordinated across the TWO simultaneous DKIM-signing locations a hybrid Exchange deployment induces. Concretely, the spoke documents FOUR hybrid-Exchange-DKIM-rotation- coordination dimensions: (i) the dual-signer hybrid topology has two operationally-distinct DKIM-signing locations whose key-rotation cadences must be coordinated — on-premises Exchange transport agents (Exclaimer, GFI MailEssentials, Zix) sign under d=your-domain.com with operator-controlled keys requiring manual rotation (typically a transport-agent config reload), while Exchange Online independently signs under d=<tenant>.onmicrosoft.com or the configured custom-domain DKIM via Microsoft-managed selector1._domainkey / selector2._domainkey CNAME- delegated automatic alternation — operationally the same dual-selector zero-downtime rotation pattern THIS page documents but applied at TWO independent signing locations whose rotation calendars the operator must align to avoid the dual-signer DMARC-alignment ambiguity the spoke documents; (ii) Centralized Mail Transport (CMT) collapses the dual- signer surface to the single-signer cloud rotation cadence — when the operator enables CMT (Set-HybridConfiguration -CentralizedTransportEnabled $true), all outbound mail relays through Exchange Online which becomes the SOLE DKIM signing location, and the rotation discipline collapses back to the Microsoft-managed selector1 ↔ selector2 automatic alternation cadence — the operator inherits Microsoft's rotation calendar (with operator-visibility through the Defender portal but no operator control over the rotation timing) and loses the operator-controlled rotation discipline THIS page documents; (iii) ARC sealing introduces a THIRD rotation surface when the operator keeps dual-signer topology — when CMT is not used and on-prem remains an outbound boundary, the operator typically deploys an ARC sealer (Exchange Online ARC Sealer in trusted- intermediary mode, or a dedicated on-prem ARC signer) whose own ARC-signing key rotation cadence must be coordinated with the on-prem DKIM key rotation AND the cloud Exchange Online DKIM key rotation — three independent key-lifecycle surfaces whose rotation calendars the operator must align to preserve ARC-chain verifiability across rotation windows; and (iv) the Hybrid Configuration Wizard (HCW) does NOT bootstrap DKIM rotation on either side — HCW configures the bidirectional Send / Receive connector pair, the federation trust, and the accepted-domain registration, but explicitly does NOT run Set-DkimSigningConfig on the cloud side, does NOT install on-prem transport agents, and does NOT publish any _domainkey TXT or CNAME records — the dual-selector rotation discipline THIS page documents must be assembled by the operator AFTER HCW completes, applied to whichever side(s) the operator chooses as outbound boundary. Read the DMARC-for-hybrid- Exchange spoke alongside this rotation reference when planning the rotation runbook for a hybrid Exchange portfolio (the CMT-vs-classic-hybrid decision determines whether the operator runs ONE rotation calendar or TWO/THREE), when investigating dual-signer DMARC alignment ambiguity surfaced during a rotation window, or when coordinating an ARC-sealer rotation with the DKIM-key rotation cadence on either signing side.
• DMARC for transactional email - the third-party-ESP deployment guide covering provider-managed DKIM rotation for SendGrid, Mailgun, Amazon SES, Postmark, SparkPost.
• DMARC for SaaS senders - marketing-automation deployment guide covering provider-managed DKIM rotation for Salesforce Marketing Cloud, HubSpot, Marketo, Mailchimp.
• DMARC for shared hosting - the DKIM-KEY-ROTATION-CADENCE-CONSTRAINED- BY-SHARED-HOSTING-PROVIDER-MANAGED-MTA- SIGNING-KEY-LIFECYCLE companion to this DKIM-key-rotation operator-runbook reference. Where THIS page documents the canonical operator-controlled DKIM-key- rotation discipline (dual-selector rotation overlap window, quarterly / biannual rotation cadence per RFC 6376 §6.1, the publisher-publishes-new- selector-before-transitioning-signer validation-window grace period, the operator-private-key-storage HSM-backed discipline), the shared-hosting spoke is the per-provider deployment companion documenting FOUR shared-hosting-DKIM- rotation-constraint dimensions: (i) shared-hosting MTA per-tenant DKIM signing posture — the provider's Exim / Postfix / qmail MTA signs outbound mail with a PROVIDER-MANAGED per-tenant DKIM key whose rotation cadence is PROVIDER-MANAGED, NOT operator-managed, removing the operator-controlled rotation timing this page presupposes - the shared-hosting spoke documents the canonical OPERATOR-EMPOWERMENT- CEILING (cPanel WHM "Manage Mail Service Authentication" → "DKIM" auto- enables a provider-default default._domainkey.<domain> selector, often with a 1024-bit provider-default key the operator cannot rotate without escalation) and the provider-managed-key-as-tenant- identity-anchor pattern that defaults the per-tenant DKIM identity to the provider's lifecycle rather than the operator's; (ii) shared-hosting control-panel DKIM-UI typically does NOT expose the dual-selector rotation overlap window this page documents — the cPanel UI is single-selector- oriented (one active selector per domain), forcing operators executing a manual rotation into a CUTOVER-WITH- DOWNTIME-WINDOW pattern instead of the overlap-window pattern - the shared-hosting spoke documents the canonical operator failure pattern where the operator advances from default._domainkey to s2._domainkey via cPanel UI and the UI immediately deactivates the prior selector (no overlap window), producing a 1-72-hour propagation window during which receivers see DKIM permerror on signatures that reference the now- deleted selector; (iii) shared- hosting tenant-isolation failure mode — some providers SHARE a single DKIM signing key across multiple tenants on the same shared-MTA, structurally violating per-tenant key sovereignty and creating a cross-tenant-replay- attack surface where any tenant on the shared-MTA can replay a signed message from another tenant on the same key - the shared-hosting spoke documents the operator-side verification discipline (publish a message via the shared-hosting MTA, capture the DKIM-Signature header, decode the d= and s= tags, compare against an OTHER tenant on the same provider — if both tenants' messages reference the SAME selector at the SAME owner name, the provider is violating per- tenant DKIM-key sovereignty); (iv) shared-hosting per-account escalation path to operator-managed DKIM-key custody — managed-DNS-zone access, custom-DKIM-selector publication, operator-private-key storage discipline, and the OPERATOR-EMPOWERMENT-FLOOR operators must escalate to before this page's dual-selector overlap-window rotation discipline becomes executable on a shared-hosting tenant - the shared-hosting spoke documents the per-provider escalation paths (cPanel "Edit DNS Zone" admin-tier escalation + per-account exim configuration override, Plesk "Custom DKIM Configuration" per-domain override + custom-key-upload UI, DirectAdmin per-domain DKIM configuration via the admin-tier DNS editor) that unlock the operator- controlled rotation cadence this page documents at the shared-hosting boundary. Read the shared-hosting spoke when deploying DKIM-key-rotation discipline on a cPanel / Plesk / DirectAdmin tenant — the spoke is the authoritative per- provider operational reference for the DKIM-key-rotation-meets-shared-hosting- provider-managed-MTA-signing-key cross- cluster boundary.
• DMARC monitoring - the operational monitoring guide. Tracking the DKIM pass rate is one of the standard health checks during and after rotation.
• Email authentication glossary - definitions of selector, private key, public key, body hash, canonicalization, and the other vocabulary used on this page.
• DKIM-Signature header tag anatomy — the DKIM-S-SELECTOR-LIFECYCLE- CONSUMER-OF-SIGNATURE-TAG-ANATOMY companion reference. Where this page documents the ROTATION PROCEDURE itself (dual-selector overlap procedure, single-selector hot-swap emergency procedure, per-provider automation across Workspace / M365 / SES / Mailgun / Postmark / SendGrid, key-size cadence guidance), the signatures-explained spoke is the FIELD-LEVEL CANONICAL REFERENCE for the DKIM-Signature header tags the rotation operationally targets: the s= selector tag identifies WHICH key pair signed the message (the canonical rotation target — every dual-selector rotation switches the signer's emitted s= value, every key-rotation event depublishes the old selector's TXT record), the d= signing-domain tag pins the namespace under which s._domainkey.d resolves to the public key (immutable across rotations unless a domain-migration accompanies), the a= algorithm tag encodes the key-size decision (rotating from 1024-bit RSA to 2048-bit RSA or Ed25519 per RFC 8463 changes the a= value at the signer-emission layer), and the b= / bh= signature + body-hash values change at every rotation because they're computed against the new private key. Read the signatures-explained spoke alongside this page when scripting the rotation-procedure verification logic: the spoke gives the per-tag canonical map of what each field encodes, this page gives the operational rotation lifecycle that cycles those fields' values, and together they form the produce-side (signer emits tags) and consume-side (receiver parses tags + DNS lookup) closure every rotation procedure must satisfy.
• DKIM failures explained — the KEY-ROTATION-WINDOW-AS-PRIMARY-FAILURE-MODE-PRODUCER companion to this rotation reference — the KEY-ROTATION-WINDOW-AS-PRIMARY-FAILURE- MODE-PRODUCER companion documenting how the operational rotation lifecycle THIS page documents is the SINGLE most-common deployment-driven producer of DKIM verification failure modes — when the rotation overlap window is mis-sized, when the new selector record's TTL has not propagated to receiver- side recursive resolvers, when the old selector is removed before in-flight signed mail has been delivered, or when the signing infrastructure switches over to the new selector before the new TXT record has been published. Where THIS page documents the rotation PROCEDURE in operational terms (overlap-window calendar, selector naming scheme, sequenced TXT publication / signing- infrastructure cutover / old-selector retention, DNS-TTL coordination), the failures spoke catalogues the receiver-side diagnostic signature of each rotation misstep: dkim=temperror (selector not yet published / DNS not yet propagated to the verifier's resolver), dkim=permerror (selector exists but key bytes don't decode), dkim=fail body-hash-mismatch (verifier looked up wrong selector because signer's s= field referenced a non-current selector), and bare dkim=neutral (signer switched off old selector before all in-flight signed messages were delivered). Read THIS rotation-procedure page WITH the failures reference when planning a rotation — the failures spoke names the four diagnostic Authentication-Results stamp signatures whose appearance in production RUA aggregate reports during the rotation window confirms which specific procedural step was mistimed.
• DKIM troubleshooting — the DKIM-KEY-ROTATION-AS-PROACTIVE- PREVENTION-OF-TROUBLESHOOTING-INDUCTION- VS-THE-ROTATION-WINDOW-AS-PRIMARY- INDUCTION-PERIOD-FOR-DKIM-VERIFICATION- FAILURE-OBSERVATION companion to this key-rotation procedure reference. Where THIS page documents the operationally correct zero-downtime rotation procedure (publish new selector → wait full overlap window driven by published TXT TTL → cut signer over to new selector → wait second overlap window for in-flight messages → retire old selector → re-shorten TTL), the dkim-troubleshooting spoke is the DIAGNOSTIC-ACTION-LAYER consumer of this rotation procedure documenting WHAT TO DO WHEN the rotation procedure has been mistimed and the rotation-window-induced DKIM-verification failures are now surfacing in production RUA aggregate reports. The structurally-distinct relationship is: rotation IS the operational discipline that PREVENTS the most common dkim=fail / dkim=temperror / dkim=permerror failure cohort from occurring at the signer-side at all (proactive prevention), but when rotation IS the OBSERVED INDUCTION-PERIOD root cause of an actual production DKIM-verification-failure event, the dkim-troubleshooting spoke is the REACTIVE-DIAGNOSTIC-PLAYBOOK operators execute on the as-observed-already-failing mail stream — the seven-step diagnostic decision tree (selector resolution audit, published-vs-signing key match audit, in-transit body-modification audit, signed-headers h= tag consistency audit, canonicalization c= tag implementation audit, t=/x= timestamp validity audit, per-receiver verifier implementation audit) the dkim-troubleshooting spoke documents includes the rotation-window- specific failure-class diagnostic sub-procedures (steps 1 and 2 are the rotation-window-induced failure-mode- specific audits operators run first when the failure window correlates with a recent rotation event), the per-control- panel / per-platform / per-ESP DKIM authoring UI quirk catalogue (where platform-specific rotation-UI gotchas like the cPanel "Email Deliverability" single-selector limitation or the Workspace Admin Console DKIM "Generate New Record" silent-old-selector- retention produce predictable rotation- timing failures), and the iterative narrow-by-pivoting RUA analysis pattern operators run during incident response. Pair this page (the proactive rotation procedure) with the dkim-troubleshooting spoke (the reactive diagnostic playbook when rotation timing fails) — together they document the complete DKIM-key- lifecycle operational discipline from preventive procedure to incident response.
• Email spoofing taxonomy — the KEY-ROTATION-AS-PROACTIVE-DEFENSE- AGAINST-COMPROMISED-LEGITIMATE-SENDER- AND-THIRD-PARTY-VENDOR-COMPROMISE- SPOOFING-VARIANTS companion to this DKIM key-rotation reference. Where THIS page documents the four-phase rotation procedure (publish new selector, parallel signing window, retire old selector, post-retirement verification) and the rotation-window failure-mode catalogue, the email-spoofing spoke documents the SEVEN-TECHNIQUE spoofing taxonomy whose TWO cryptographic-compromise variants the rotation discipline THIS page documents structurally defends against across FOUR rotation-as-defense dimensions: (i) compromised- legitimate-sender spoofing defense via scheduled key rotation — the compromised-legitimate-sender spoofing variant (where an attacker exfiltrates a DKIM private key from the signing infrastructure and forges cryptographically- valid messages from the victim's domain) is structurally LIMITED in attacker window by the rotation cadence documented on THIS page — a 90-day rotation schedule caps attacker validity at 90 days, a 30-day schedule caps it at 30 days; (ii) third-party- vendor-compromise spoofing defense via per-vendor-selector isolation — the third-party-vendor-compromise spoofing variant (where a compromised ESP's signing key is used to forge messages cryptographically aligned with the victim's d=) is structurally ISOLATED by the per-vendor-selector publication discipline THIS page documents — a compromised vendor's selector under vendor1._domainkey.<d> does not invalidate the victim's in-house selectors under mail1._domainkey.<d> / mail2._domainkey.<d>; (iii) post-compromise emergency- rotation procedure as incident-response primitive — when the spoofing catalogue's compromised-legitimate- sender variant materialises (attacker with valid DKIM-signed forgeries), the emergency-rotation procedure documented on THIS page is the LOAD-BEARING incident-response primitive that invalidates the attacker's existing forgeries cryptographically the moment the old selector's DNS publication is retired; (iv) key-size + algorithm-strength selection as long-window compromise-resistance defense — the algorithm-and- key-size selection guidance THIS page documents (2048-bit RSA minimum, Ed25519 preferred where receivers support, no 1024-bit RSA for new deployments) determines the cryptographic feasibility of the brute- force-compromise attack-class underlying the compromised-legitimate- sender variant — a 2048-bit RSA key is computationally infeasible to brute- force within the rotation window, while a deprecated 1024-bit key is increasingly within reach of nation- state cryptanalysis. Read the email- spoofing spoke WITH this rotation reference when designing the operational rotation cadence for a sensitive sending infrastructure — the spoofing-taxonomy spoke documents WHICH spoofing variants the rotation discipline defends against and HOW the rotation cadence parameter caps the attacker-window for each defended variant.
• BIMI Verified Mark Certificates (VMC) — the BIMI-VMC-PER-CERT-RENEWAL- LIFECYCLE-AS-CA-ISSUED-CRYPTOGRAPHIC- MATERIAL-LIFECYCLE-DISCIPLINE-PARALLEL- TO-DKIM-PER-SELECTOR-ROTATION-CADENCE companion to this DKIM key-rotation reference. Where THIS page documents the per-publisher DKIM private-key / public-key rotation discipline (the dual-selector overlap-window cadence, the 90-180-day rotation period typical for sensitive infrastructure, the per-selector p=-public-key TXT-RR publication-then-removal staged propagation pattern, the per-rotation attacker-window cap), the BIMI VMC spoke is the CA-ANCHORED CRYPTOGRAPHIC- MATERIAL-LIFECYCLE companion documenting the X.509 Verified Mark Certificate per-cert renewal cadence whose per-publisher 1-year reissuance cycle + CA-validation reissuance workflow + AIA/CRL/OCSP revocation- propagation + per-cert emergency- revocation discipline is the CA- anchored cryptographic-material- lifecycle parallel to this DKIM publisher-anchored rotation cadence. The four-axis DKIM-PER-SELECTOR- ROTATION-VS-BIMI-VMC-CERT-RENEWAL comparison exposes the structurally- distinct per-publisher cryptographic- material-lifecycle disciplines: (i) DKIM per-selector rotation is operator-controlled (publisher decides cadence, executes rotation via DNS-edit of the per-selector TXT-RR pair); BIMI VMC per-cert renewal is CA-coupled (publisher renews via the CA workflow, executes against a 1-year cert validity-window the CA imposes) — both are per-publisher per- cryptographic-material lifecycle disciplines but the rotation/renewal decision-locus differs (operator controls DKIM cadence, CA constrains VMC cadence); (ii) DKIM rotation cadence caps the attacker- window for stolen-private-key replay (per-selector compromise window = rotation-period - days- since-last-rotation); BIMI VMC revocation-propagation budget caps the attacker-window for compromised VMC (AIA/CRL/OCSP fetch interval + per-receiver cache TTL bounds the per-receiver display-eligibility re-evaluation after publisher- notified revocation) — both disciplines have an attacker- window-cap structural invariant but DKIM rotation reduces the window proactively while BIMI VMC revocation reduces it reactively; (iii) DKIM rotation discipline prescribes an overlap-window for in-flight-message DKIM-signature- verification continuity; BIMI VMC renewal discipline prescribes an overlap-window for cached-VMC-fetch continuity at receivers caching the publisher's prior cert — both publication-disciplines have cryptographic-material-overlap- window invariants the per-publisher operator must coordinate; (iv) DKIM private-key compromise triggers an unplanned-rotation emergency workflow (immediate new- selector publication + delayed old- selector removal); BIMI VMC private- key compromise triggers an unplanned- CA-revocation emergency workflow (CA-issued revocation propagated via AIA/CRL/OCSP) — both publication-disciplines have an emergency-revocation contract the per-publisher operator must execute in coordination with the cryptographic-material publication infrastructure (DKIM via DNS, BIMI VMC via CA). Read the BIMI VMC spoke alongside this DKIM key- rotation reference when scoping the per-publisher cross-layer cryptographic-material-lifecycle discipline — the spoke documents the CA-anchored cryptographic- material lifecycle whose per-cert renewal cadence is the display- layer CA-anchored parallel to the DKIM message-layer publisher- anchored rotation cadence this page documents.
• Domain Security Checker - live DNS lookups for SPF, DKIM, DMARC. Verifies the current DKIM public key under any selector.
• Email Header Analyzer - paste a message's headers and see the DKIM-Signature header parsed: selector, algorithm, signed headers, signature verification result.
• DNS Record Generator - model a new DKIM TXT record before publishing it.
• DMARC deployment checklist - the END-TO-END DEPLOYMENT-PHASE-CONTAINING- DKIM-KEY-ROTATION-CADENCE companion to THIS rotation-discipline catalogue. Where THIS page documents the dual-selector zero-downtime rotation procedure (publish new selector → switch signing → wait for receiver-cache ageing window per RFC 1035 + RFC 8767 serve- stale → retire old selector) as the OPERATIONAL-LIFECYCLE-DISCIPLINE applied to a deployed DKIM signing pipeline, the deployment checklist documents the END-TO-END DEPLOYMENT-PHASE-SEQUENCE within which DKIM key rotation sits as the ongoing-operations- phase cadence after the initial publication- plus-monitoring-plus-enforcement-commitment ramp closes out. Four DEPLOYMENT-CHECKLIST-VS- DKIM-ROTATION axes the checklist documents that this page is the operational-cadence deep-dive for: (1) initial publication phase — the checklist's "publish DKIM TXT at <selector>._domainkey" step that establishes the first selector (the baseline this page's dual-selector rotation procedure operates against — every subsequent rotation is anchored to the selector originally established at deployment); (2) RFC 8301 algorithm-strength compliance phase — the checklist's RSA-≥-2048 / Ed25519 selection decision whose initial public-key-size choice determines the urgency of the rotation cadence this page documents (an initially-published 1024-bit RSA key under RFC 8301's deprecation ruling must be rotated MORE URGENTLY than the annual-cadence baseline this page recommends); (3) ongoing-operations phase — the checklist's "rotate keys annually with dual- selector overlap" step is the cadence-defining entry-point for the dual-selector rotation procedure this page documents at the operational-step level (the checklist sets the annual cadence; this page documents the per- rotation step-by-step procedure that fulfils the cadence); (4) enforcement- commitment phase coordination — the checklist's p=none → p=quarantine → p=reject ramp must NOT overlap with an in-flight DKIM rotation window (rotation during enforcement-flip risks the dkim=temperror / dkim=permerror background rate spiking during the rotation-overlap window AND the enforcement flip converting that elevated rate into legitimate-message rejection); this page documents the operational sequence the checklist relies on to keep rotation windows outside enforcement-flip windows. Read the deployment checklist FIRST to position DKIM rotation in the deployment lifecycle; read THIS page when EXECUTING a rotation within that lifecycle.
• ARC explained (RFC 8617 Authenticated Received Chain) — the PER-HOP-ARC-SEALER-KEY-ROTATION- CADENCE-PARALLELS-PER-PUBLISHER-DKIM-KEY- ROTATION-CADENCE companion to this DKIM key-rotation operational reference. Where THIS page documents the per-publisher dual-selector key-rotation discipline (the per-publisher Phase-1 mint-new-selector, Phase-2 publish-new-public-key-TXT-record, Phase-3 transition-outbound-signing, Phase-4 monitor-DKIM-pass-rate-on-new- selector, Phase-5 revoke-old-selector after the per-publisher propagation-grace- period), the ARC-explained spoke documents the STRUCTURALLY-PARALLEL per-hop ARC sealer-key-rotation cadence every per-hop forwarder-relay (Gmail / Outlook / Mailman / corporate gateway / mailing-list mediator) materialises at its own per- sealer organisational-domain selector- publication boundary across FOUR per-hop- ARC-key-lifecycle-vs-per-publisher-DKIM- key-lifecycle coordination dimensions: (i) per-hop ARC sealer dual-selector rotation discipline inherits from DKIM publisher-side dual-selector rotation discipline — when Gmail rotates its ARC sealer-selector from arc20240601._domainkey.google.com to arc20240901._domainkey.google.com at the per-sealer rotation cadence, Gmail's ARC sealer infrastructure follows the IDENTICAL five-phase rotation discipline THIS page documents — mint new per-sealer selector, publish per-sealer TXT-record, transition outbound ARC sealing to the new per-sealer selector, monitor per-sealer ARC-Seal-verification success rate, revoke prior per-sealer selector after the per-sealer propagation- grace-period; (ii) per-hop ARC sealer key-rotation cadence orthogonal to per-publisher DKIM rotation cadence — the per-hop ARC sealer's key-rotation cadence operates INDEPENDENTLY of the per-publisher DKIM-signing operator's rotation cadence — the per-publisher rotating their per-publisher s1._domainkey.<publisher-domain> selector at quarterly cadence does NOT affect the per-hop forwarder-sealer's per-sealer rotation cadence; the per-hop sealer's ARC chain-validation continues to succeed via the per-hop sealer's independent rotation discipline; the downstream receiver consuming the per- hop ARC chain verifies each per-hop signature against the per-hop sealer's currently-published selector regardless of the per-publisher DKIM signing signature's selector-rotation status; (iii) per-hop ARC sealer key- compromise-and-revocation discipline parallels per-publisher DKIM compromise- and-revocation discipline — when a per-hop ARC sealer's private key is compromised (the sealer's per-sealer infrastructure breach), the per-hop sealer executes the SAME emergency rotation pattern THIS page documents for per-publisher DKIM compromise — mint emergency per-sealer selector, publish new per-sealer public-key, transition outbound ARC sealing to the new per- sealer selector, IMMEDIATELY revoke the compromised per-sealer selector (no propagation-grace-period — the cost of receiver-side ARC chain-validation failures during the propagation window is acceptable vs the cost of an attacker continuing to forge per-hop ARC sealer signatures with the compromised key); and (iv) per- hop ARC sealer key-algorithm-strength upgrade discipline parallels per- publisher DKIM RFC 8301 algorithm- upgrade discipline — when the IETF deprecates an algorithm (RFC 8301 deprecation of 1024-bit RSA in 2018, future deprecation of RSA-2048 in favour of Ed25519 / post-quantum), the per-hop ARC sealer's per-sealer infrastructure executes the SAME algorithm-upgrade rotation pattern THIS page documents for per-publisher DKIM algorithm-upgrade — mint per-sealer Ed25519 keypair, publish per-sealer Ed25519 public-key alongside prior per-sealer RSA-2048 public-key for the transition period, transition outbound ARC sealing to the per-sealer Ed25519 selector, revoke the per-sealer RSA-2048 selector after the per-sealer propagation-grace-period. Pair THIS DKIM key-rotation operational reference with the ARC-explained spoke when scoping the per-hop forwarder-relay sealer-key- rotation operational discipline for a forwarding-gateway or mailing-list- mediator deployment — the per-publisher DKIM key-rotation operational sequence THIS page documents IS the per-hop operational sequence every per-hop ARC sealer materialises at its own per-sealer organisational-domain selector-publication boundary in the forwarder-relay chain.
• DKIM for Google Workspace — the GOOGLE-WORKSPACE-TENANT-DKIM-AT- google-DOMAINKEY-DIRECT-TXT-RR-PUBLICATION- AS-CANONICAL-ADMIN-CONSOLE-ORCHESTRATED- DUAL-SELECTOR-ZERO-DOWNTIME-ROTATION- PRIMITIVE-INSTANTIATION companion to this DKIM key-rotation reference. Where THIS page documents the per-publisher per- selector key-rotation discipline (the dual-selector zero-downtime swap pattern, the TTL-bounded overlap window, the 6-to-12-month rotation cadence per RFC 6376 §3.3, the emergency-rotation incident- response protocol, the <selector>._domainkey.<d> TXT-record publication sequencing), the dkim-for-google-workspace spoke is the WORKSPACE-TENANT-CANONICAL-OPERATOR- INTERFACE reference documenting the FOUR Workspace-tenant-rotation-vs-cluster- rotation-discipline coupling dimensions every Workspace-tenant DKIM-rotation deployment depends on: (i) Google Workspace Admin Console > Apps > Google Workspace > Gmail > Authenticate email panel as canonical operator interface for dual-selector rotation — the per-publisher per-selector dual-selector zero-downtime rotation procedure THIS page documents (publish-new-selector → wait-for-DNS- propagation → enable-new-selector-at-signer → wait-for-TTL-overlap → revoke-old- selector) is executed at the Workspace tenant via the Admin Console's "Generate new record" + "Start authentication" + per-selector-namespace-rotation actions, which materialise the canonical zero- downtime rotation primitive at the Workspace operator's per-domain google._domainkey.<d> → google2._domainkey.<d> selector-namespace boundary; (ii) Workspace per-publisher per-selector 1024-to-2048-bit RSA key-strength upgrade discipline — the Workspace Admin Console's default "Generate new record" action still emits a 1024-bit RSA keypair (deprecated per RFC 8301 §3 — the canonical upgrade-rotation trigger THIS page documents as one of the three primary rotation-cadence drivers); the Workspace operator MUST select the 2048-bit option at rotation time to lift the per-publisher per-selector cryptographic-strength floor the modern receiver-side DKIM-verifier requires for the per-message DKIM-aligned- pass verdict THIS rotation discipline protects; (iii) Workspace per- selector TTL-bounded overlap window for the per-message-in-flight-and-replay- envelope — the operator-controlled per-publisher per-domain DNS zone TTL on the published google._domainkey.<d> TXT-RR (typically 3600s default) gates the per-publisher per-selector overlap- window duration THIS page documents, whose minimum length is the TTL + the per-message in-flight residency time + the DKIM replay-acceptance envelope per RFC 6376 §6.1.3, beyond which the old selector TXT-RR MAY be safely revoked with p= empty value or outright deleted; (iv) Workspace per-tenant d=-tag identity preservation across rotation cutover — the per-selector rotation event THIS page documents must NOT alter the per- message DKIM-Signature d=- tag value (the primary domain at the Workspace tenant level), so the DKIM-half of identifier-alignment continues to evaluate against the SAME author- domain From: header across every Workspace-tenant rotation cutover — the rotation moves per-selector keys ONLY, not per-tenant d=-tag identity. Read the dkim-for-google-workspace spoke as the Workspace-tenant-specific operator- interface reference whenever the protected domain is hosted on the Google Workspace cloud tenant and the per-publisher per- selector rotation discipline THIS page documents needs a Workspace-tenant- operator-interface instantiation baseline.
• Business Email Compromise (BEC) - the DKIM-KEY-ROTATION-DISCIPLINE-AS- ONGOING-BEC-DEFENSE-CRYPTOGRAPHIC-FRESHNESS- POSTURE companion to this DKIM key-rotation reference. Where THIS page documents the per-publisher per-selector key-rotation discipline (dual-selector zero-downtime rotation, 1024-to-2048-bit RSA cryptographic- strength upgrade, per-selector TTL-bounded overlap window, d=-tag identity preservation across rotation cutover, RFC 8301 algorithm- deprecation timeline, RFC 8463 Ed25519 adoption path), the business-email-compromise spoke documents the canonical BEC financial- fraud-attack-category catalogue (six canonical variants per FBI IC3 USD 2.9B reported 2023 loss + USD 55B+ cumulative since 2013) and the per-variant defense-in-depth control stack whose ONGOING-CRYPTOGRAPHIC-FRESHNESS FOUNDATION is the DKIM-key-rotation discipline THIS page documents — at four DKIM-key-rotation-to-BEC-financial-fraud- defense coupling dimensions: (i) per-selector key-rotation as DKIM- replay-attack window-bounding primitive for BEC-campaign-message-replay defense — BEC attackers who can capture a cryptographically-valid DKIM-signed legitimate message (e.g., an authentic executive-from-publisher communication intercepted via mailbox compromise or message-stream interception) can replay the message-byte-content against downstream recipients for an attack window bounded by the per-selector key-lifetime; the per- publisher per-selector rotation discipline THIS page documents (e.g., 90-day rotation cadence) caps the BEC-message-replay attack window — without rotation, the BEC-replay- window is bounded only by the per-selector key-publication TTL, which can extend indefinitely; (ii) per-selector key-rotation as BEC-key-compromise-recovery primitive — if BEC attackers succeed in compromising a per-publisher per-selector DKIM-private-key (e.g., via cloud-tenant-administrator-credential theft, on-prem-signer-host compromise, or insider-threat ex-employee credential- retention), the per-publisher response playbook the BEC defense-in-depth control stack relies on is THE rotation discipline THIS page documents — without an established per-publisher per-selector rotation operational discipline, the per-publisher per-tenant key-compromise-recovery surface does not exist; (iii) per-tenant rotation-cutover gap as BEC-DMARC-bypass exploitation window — when a publisher's per-selector rotation cutover accidentally publishes EITHER no-selector OR the wrong-selector at the receiver-side DNS namespace, the per-message DKIM- Signature verification fails and the per- message DKIM-aligned-pass evaluation path is eliminated; the BEC attacker who can exploit DKIM-publication-discipline-gaps during the rotation-cutover window gains a per-publisher per-domain DMARC-bypass opportunity that would NOT exist absent the rotation gap (the per-publisher rotation-cutover discipline THIS page documents — TTL-bounded selector overlap windows, propagation-lag-conservative cutover boundaries — is the operator-side discipline that closes this exploitation window); (iv) cryptographic- strength-upgrade discipline as per-publisher per-tenant BEC-defense cryptographic- baseline-floor primitive — the per-publisher RFC 8301 1024-to-2048-bit RSA cryptographic-strength upgrade discipline THIS page documents is the load- bearing per-publisher per-tenant cryptographic-baseline-floor primitive that forecloses the BEC-attacker's capability to brute-force-forge per-publisher DKIM- signatures (1024-bit RSA factorization is within reach of well-resourced adversaries per RFC 8301 §3.4; 2048-bit RSA factorization is not, under current cryptanalytic capability assumptions). Read the BEC spoke ALONGSIDE this DKIM-key-rotation reference whenever the per-publisher per-tenant ongoing-cryptographic-freshness posture is being scoped for BEC-financial-fraud- campaign-defense coverage — the DKIM-key- rotation discipline THIS page documents IS the ONGOING-CRYPTOGRAPHIC-FRESHNESS primitive the BEC defense-in-depth-control-stack the BEC spoke documents structurally consumes across every per-publisher per-tenant rotation cycle to bound replay windows, enable key-compromise recovery, close rotation-cutover BEC-DMARC-bypass exploitation windows, and maintain a cryptographic-strength-baseline floor.
• DMARC multi-domain strategy — the MULTI-DOMAIN-ESTATE-SPECIFIC DKIM-KEY-ROTATION-COORDINATION companion to this DKIM-key-rotation reference. Where THIS page documents the per- publisher per-selector key-rotation lifecycle (publish-new-selector-FIRST → cutover-signing-key → retire-old- selector), the multi-domain-strategy spoke is the MULTI-DOMAIN-ESTATE- SPECIFIC execution coordination guide at FOUR per-multi-domain-estate-to- DKIM-key-rotation coupling dimensions: (i) per-organizational-domain primary-brand-domain DKIM-key-rotation coordination with sibling brand- subsidiary-domain rotation cycles — when the org-domain brand.com rotates its selector2024Q2._domainkey selector, sibling brand-subsidiary domains brand-eu.com, brand-apac.com, brand-shop.com typically rotate together to maintain estate- wide cryptographic-freshness parity — the multi-domain spoke documents the per-organizational- domain rotation-cycle coordination operators execute to maintain consistent cryptographic-freshness posture across the multi-domain estate; (ii) per-parked- domain DKIM-publication-or-absence coordination with primary-brand- domain DKIM-key-rotation — when the org rotates the primary-brand-domain signing key, parked defensive domains like brand-typo.com, brand-cn.com, brand-misspelling.com either MUST mirror the rotation (if they emit mail) or MUST maintain explicit v=DKIM1; p=; revocation TXT records (if they do not emit mail) to prevent attacker- impersonation via parked-domain DKIM- bypass — the multi-domain spoke documents the per-parked- domain DKIM-publication-discipline coordination operators execute during primary-brand-domain rotation cycles; (iii) per-acquired- domain DKIM-key-rotation lifecycle coordination during M&A integration cycles — when the parent organization acquires newco.com, the acquired-domain DKIM signing-key rotation lifecycle MUST be brought into alignment with the parent organization's rotation cadence within the M&A-integration-quarter boundary to maintain estate-wide cryptographic-freshness-baseline- floor — the multi-domain spoke documents the per-acquired- domain rotation-cycle integration workflow operators execute during M&A integration cycles; (iv) per-multi-domain-estate rotation-window-coordination discipline — staggered per-domain rotation cutover windows to avoid simultaneous estate-wide DNS- propagation-window dkim=temperror spikes that would degrade DMARC- aligned-pass-rate across the entire estate during a single coordinated cutover window — the multi- domain spoke documents the per- estate rotation-window-staggering coordination discipline operators execute to bound the per-estate DKIM-aligned-pass-rate-degradation risk during synchronized rotation cycles. Read the multi-domain- strategy spoke ALONGSIDE this DKIM- key-rotation reference whenever the per-publisher per-selector rotation- lifecycle THIS page documents is being scoped for execution across the organization's multi-domain estate — the multi-domain spoke is the canonical per-multi-domain- estate rotation-coordination reference whose per-organizational- domain + per-parked-domain + per- acquired-domain + per-estate- rotation-window-staggering coordination disciplines are the LOAD-BEARING multi-domain-estate execution discipline every estate- wide DKIM-key-rotation cycle depends on.
• SPF for Microsoft 365 — the per-M365-tenant per-domain v=spf1 include:spf.protection.outlook.com -all publication discipline this spoke documents is the per-tenant per- domain envelope-MAIL-FROM authorization leg that pairs with the per-selector DKIM key-rotation discipline THIS page covers as the per-message cryptographic-binding leg — both legs feed the per- receiver per-message DMARC composite verdict for the M365-tenant per- domain deployment surface. Read the M365 SPF spoke when AUTHORING the envelope-MAIL-FROM authorization publication discipline whose first- hop SPF-aligned-pass outcome runs as the per-publisher per-domain authentication-leg companion to the per-selector DKIM key-rotation publication discipline THIS page's rotation-cycle catalogue drives.
• Email security glossary — the DKIM-KEY-ROTATION-DISCIPLINE- VOCABULARY-RESOLVES-TO-CROSS-CLUSTER- EMAIL-SECURITY-TERMINOLOGY-HUB companion to this DKIM-key-rotation discipline reference. Where THIS page documents the per-publisher per-selector DKIM-key- rotation discipline (the canonical annual-rotation cadence, the dual- selector overlap window, the per-selector public-key TXT-RR publication at <selector>._domainkey.<d>, the per-publisher key-compromise incident-response runbook, the per-selector revoked-key sentinel p= empty-value publication), the email-security-glossary spoke is the cross-cluster TERMINOLOGY-RESOLUTION reference whose per-term canonical definitions establish the shared vocabulary every DKIM-rotation discussion structurally depends on at FOUR per-term vocabulary-resolution dimensions: (i) per-term DKIM-public-key-record tag-set vocabulary resolution — the DKIM- public-key-record tag-set vocabulary (p= public-key tag, k= key-type tag, h= hash-algorithms tag, t= flags tag, s= service-type tag, n= notes tag, g= granularity tag, v= version tag) THIS page's per-publisher per-selector rotation reference structurally references at every per-rotation-phase entry is canonically defined in the glossary spoke; the per-selector per-publisher TXT-RR per-tag terminology vocabulary that drives every rotation- authoring discussion lives in the glossary's per-tag entry-set; (ii) per-term DKIM-cryptographic- primitive vocabulary resolution — the DKIM-cryptographic-primitive vocabulary (RSA-SHA256 algorithm, 2048-bit modulus, public-key cryptography, key-generation entropy, private-key storage discipline, key-rotation as forward-secrecy approximation, key-compromise blast- radius, per-selector key-revocation via empty-p= sentinel) THIS page's per- publisher per-selector rotation reference references when describing the per-rotation-cycle cryptographic primitives is canonically defined in the glossary spoke; the per- selector cryptographic-primitive terminology vocabulary that drives every DKIM-rotation-incident-response discussion lives in the glossary's per- term cryptographic-primitive entry-set; (iii) per-term selector-cohort vocabulary resolution — the selector- cohort vocabulary (selector, dual- selector overlap window, selector rotation cadence, per-publisher per- selector cohort partitioning, per- receiver selector validation order, per-receiver selector TTL-cache aging, per-receiver legacy-selector verify- history) THIS page's per-publisher per- selector rotation reference references when describing the per-overlap-window coordination is canonically defined in the glossary spoke; the per- selector-cohort overlap-window coordination terminology vocabulary that drives every rotation-cadence- coordination discussion lives in the glossary's per-term selector-cohort entry-set; (iv) per-term DKIM- rotation-failure vocabulary resolution — the DKIM-rotation-failure vocabulary (CNAME-not-yet-propagated, public-key- TXT-RR misconfiguration, new-selector- not-yet-published, old-selector-still- signing, dual-selector inconsistency, per-receiver-side TTL-cache stale-state, per-receiver-side DNS-resolution failure, per-receiver-side public-key signature verification failure) THIS page's per-publisher per-selector rotation reference references when describing the per-rotation-failure triage runbook is canonically defined in the glossary spoke; the per- rotation-failure-mode terminology vocabulary that drives every operator- side per-rotation-failure-triage discussion lives in the glossary's per- term rotation-failure-vocabulary entry- set. Read the email-security-glossary spoke alongside this DKIM-key-rotation discipline reference when authoring per- publisher per-selector rotation runbooks and per-rotation-incident- response documents that need the shared terminology hub.
• MTA-STS for Google Workspace — the WORKSPACE-TENANT-PER-CUSTOM-DOMAIN- PER-SELECTOR-DKIM-ROTATION-CADENCE-VS- MTA-STS-POLICY-ID-BUMP-CADENCE companion to this DKIM key-rotation playbook. Where THIS page documents the per-publisher per- selector DKIM rotation discipline (annual cadence, dual-selector overlap window, per-selector revoked-key sentinel via empty p= tag), the MTA-STS-for-Google-Workspace spoke documents the per-Workspace-tenant per- custom-domain transport-layer rotation- cadence companion at four per-tenant cross-protocol rotation-cadence coordination dimensions: (i) per-Workspace-tenant per-custom-domain DKIM selector1/selector2 rotation cadence parallels per-tenant MTA-STS policy id=<version> bump cadence — Workspace tenants rotate per-custom-domain DKIM via the google._domainkey.< workspace-domain> TXT-RR republication AND per-custom-domain MTA-STS via the _mta-sts.< workspace-domain> TXT-RR id=-pointer bump + HTTPS policy-file republish; per-tenant rotation-cadence coordination ensures the cryptographic-trust-anchor rotation and transport-layer-policy rotation events do not collide on the same per-tenant zone-edit commit boundary; (ii) per-tenant dual-overlap window discipline parallel across application-layer DKIM and transport-layer MTA-STS — DKIM rotation requires an overlap window where both old and new selectors publish simultaneously (so in-flight signed mail still verifies); MTA-STS rotation requires an overlap discipline where the per-tenant policy-file retains backward-compatible mx: allow-list entries across the rotation window so sending MTAs honor the published policy through the per-tenant max_age cache window; (iii) per-tenant revocation discipline parallel between application-layer DKIM-empty- p= sentinel and transport- layer MTA-STS mode: none revocation — Workspace tenants decommissioning a custom domain publish per-selector empty p= sentinel to signal DKIM-key revocation, AND per-tenant mode: none commitment to signal MTA-STS-enforce decommissioning; per-tenant revocation publication discipline runs across both cryptographic-trust-anchor + transport- layer-enforcement boundaries; and (iv) per-Workspace-tenant per-day TLS-RPT JSON-aggregate evidence consumption as observability peer of per-tenant per-day DKIM-pass-rate evidence consumption — Workspace tenants running DKIM rotation consume per-receiver per-day Postmaster Tools DKIM-pass-rate evidence to validate rotation success, AND per-receiver per-day TLS-RPT JSON- aggregate failure-evidence stream at _smtp._tls.<workspace-domain> to validate MTA-STS policy- update success; per-tenant rotation- observability coordination ensures both rotation cadences are downstream- observable through complementary evidence streams. Read the Workspace- MTA-STS deployment spoke alongside this DKIM key-rotation playbook when coordinating per-Workspace-tenant per- custom-domain rotation cadences across the cryptographic-trust-anchor and transport-layer-policy publication boundaries simultaneously.
• RFC 6376 - DomainKeys Identified Mail (DKIM) Signatures - the canonical DKIM specification.
• RFC 8301 - Cryptographic Algorithm and Key Usage Update to DKIM - the 2018 update deprecating 1024-bit RSA and mandating 2048-bit minimum.
• RFC 8463 - A New Cryptographic Signature Method for DKIM - the Ed25519 signing-method specification for DKIM.
• TLS-RPT explained - the canonical protocol-layer TLS-RPT reference whose per-receiver per-publisher per-day aggregate JSON evidence stream is the load- bearing per-DKIM-key-rotation- cutover transport-layer observability companion the per- DKIM-key-rotation cadence discipline THIS page documents depends on at four DKIM-key- rotation-to-TLS-RPT-observability resolution dimensions: (i) the per-DKIM-key-rotation-cutover per-receiver TLS-handshake- success-rate baseline-shift evidence is the canonical load- bearing per-publisher per-rotation- window transport-confidentiality observability input - per-DKIM- rotation cutovers coincide with per-receiver per-source-IP TLS- handshake-rate windows the TLS-RPT aggregate JSON stream IS the canonical publisher-side per- receiver evidence feed for, so the publisher can EXCLUDE a transport- layer TLS-handshake-disruption confound class from the per- rotation per-receiver DKIM-pass- rate regression-analysis the rotation-cadence reference IS the canonical decision-framework for; (ii) the per-DKIM-key-rotation 7-day-dual-overlap discipline is the canonical load-bearing per- publisher cadence-discipline whose per-receiver per-source-IP observability the TLS-RPT JSON- aggregate stream IS the canonical per-receiver per-day evidence-feed for - the 7-day window during which both pre-rotation and post- rotation DKIM signatures coexist in transit is monitored against the per-receiver TLS-handshake- success-rate baseline the TLS-RPT aggregate stream IS the per- publisher per-rotation-window observability feed for; (iii) the per-DKIM-key-rotation empty- p=-tag emergency- revocation discipline is the canonical load-bearing per- publisher incident-response pattern whose per-receiver per- source-IP TLS-handshake-success- rate continuity the TLS-RPT JSON- aggregate stream IS the canonical publisher-side observability feed for - emergency-revocation cutovers risk per-receiver per-source-IP TLS-handshake-disruption windows the TLS-RPT JSON-aggregate stream catalogues at row-level granularity, and the per-publisher per-receiver per-day TLS-handshake- success-rate baseline-shift observability the TLS-RPT reference IS the canonical feed for IS the load-bearing per- revocation-event publisher-side verification surface; and (iv) the per-DKIM-key-rotation per-Ed25519- upgrade-pathway discipline is the canonical load-bearing per- publisher RFC 8463 Ed25519- signing-method upgrade-pathway coordination input - per-publisher Ed25519-key publication coincides with per-receiver per-source-IP DKIM-Signature-header-byte-size delta windows that the TLS-RPT aggregate stream's per-receiver per-source-IP TLS-handshake-MTU- and-fragmentation-success-rate evidence IS the canonical publisher-side observability feed for. Read the TLS-RPT spoke ALONGSIDE this DKIM-key-rotation reference whenever the publisher scopes a per-publisher per- rotation-window per-receiver TLS-transit-observability coordination plan - the per-DKIM- key-rotation cadence discipline THIS page documents IS the load- bearing per-publisher rotation- event-emitter whose per-receiver per-source-IP per-day per-rotation- window transport-confidentiality baseline-shift evidence the per-receiver per-publisher per- day RFC 8460 JSON-aggregate stream the TLS-RPT spoke documents IS the canonical publisher-side per-receiver per-rotation-window observability feed for.
• Email deliverability — the PER-SELECTOR-ROTATION-CADENCE- INTEGRITY-AS-LOAD-BEARING-UPSTREAM- DETERMINANT-OF-PER-PUBLISHER-PER-MAILBOX- PROVIDER-DELIVERABILITY-BASELINE companion reference. Where THIS page documents the per-publisher per-selector DKIM key- rotation cadence discipline (the quarterly-or-faster cryptographic-key- lifecycle rotation, per-selector publication-grace-period retention, per- receiver-resolver-cache TTL-bounded rotation-window discipline), the email- deliverability spoke documents the per- publisher per-mailbox-provider deliverability-baseline outcome (the per- publisher Gmail-inbox-vs-spam-vs-promotions- vs-blocked / Yahoo / M365 / Apple Mail / Fastmail per-day per-publisher delivery- placement-rate aggregate signal each per- publisher's per-mailbox-provider reputation-and-engagement signal stream produces), across four per-selector- rotation-cadence-to-per-mailbox-provider- deliverability-baseline-coupling dimensions: (i) per-publisher- per-mailbox-provider-DKIM-pass-rate-as- load-bearing-input-to-per-publisher-per- mailbox-provider-deliverability-floor — the per-publisher per-mailbox-provider deliverability baseline at Gmail / Yahoo / M365 floors on the per-publisher per- mailbox-provider per-day DKIM-pass-rate signal; per-selector rotation-cadence defects (stale rotated-away public-key TXT records evicted prematurely, new- selector pre-publication window violations, per-receiver-resolver-cache propagation-incompleteness during rotation events) collapse the per- publisher per-mailbox-provider DKIM- pass-rate baseline directly degrading the per-publisher per-mailbox-provider deliverability floor; (ii) per- publisher-per-mailbox-provider-DMARC- aligned-pass-rate-as-load-bearing-input- to-per-publisher-per-mailbox-provider- delivery-placement-policy — the per-publisher per-mailbox-provider per- day DMARC-aligned-pass-rate (the proportion of per-publisher messages whose per-message DMARC evaluation at the per-mailbox-provider produces dmarc=pass with d=tag-aligned-to-5322- From-domain) directly drives the per- publisher per-mailbox-provider per-day delivery-placement-policy decision tree (inbox vs spam vs promotions vs quarantine vs block); per-selector rotation-cadence defects collapse the per-publisher per-mailbox-provider DKIM-aligned-pass component of the DMARC-aligned-pass-rate baseline, cascading per-publisher per-mailbox- provider delivery-placement-policy regressions; (iii) per-publisher- per-rotation-window-deliverability- baseline-shift-as-canonical-rotation- cadence-defect-diagnostic-signal — per-publisher per-day per-mailbox- provider delivery-placement-rate regressions correlated against per- publisher per-selector rotation-window publication events are canonical rotation-cadence-defect diagnostic signals; the per-publisher operator diagnosing per-day per-mailbox-provider deliverability-baseline-shift outcomes MUST correlate the regression window against per-selector rotation-window publication timestamps to attribute deliverability-baseline-shift to rotation-cadence-defect root cause vs non-rotation root causes (per-publisher per-source-IP reputation degradation, per-publisher per-mailbox-provider per-day engagement-signal regression, per-publisher per-mailbox-provider spam-rate threshold breach); (iv) per-publisher-per-mailbox- provider-deliverability-baseline-as- load-bearing-feedback-signal-to-per- publisher-per-selector-rotation-cadence- operator-decision-tree — the per-publisher per-mailbox-provider per- day delivery-placement-rate aggregate signal IS the load-bearing per-publisher operator-side decision-tree input that drives per-publisher per-selector rotation-cadence operator decisions (quarterly cadence vs faster cadence, per-selector pre-publication window sizing, per-selector publication-grace- period sizing); per-publisher operators sequencing per-selector rotation events MUST instrument per-publisher per- mailbox-provider per-day delivery- placement-rate signals BEFORE AND AFTER each per-selector rotation event to validate per-publisher per-mailbox- provider deliverability-baseline continuity across rotation-window boundaries. Read this WITH the per- publisher per-selector DKIM key-rotation cadence reference when the per-publisher per-mailbox-provider deliverability- baseline degradation diagnostic sequence reaches the operator's queue: THIS page documents the per-selector cryptographic- key-lifecycle rotation-cadence integrity discipline, the email-deliverability spoke documents the per-publisher per- mailbox-provider deliverability- baseline outcome whose DKIM-pass-rate and DMARC-aligned-pass-rate floor components are STRUCTURALLY GATED on the per-selector rotation-cadence integrity discipline THIS page documents.
• DMARC reporting pipeline (RUA aggregate-report end-to-end flow) — the PER-PUBLISHER-PER-SELECTOR-ROTATION- OBSERVABILITY-CHANNEL companion to this DKIM key-rotation reference. Where THIS page documents the per-publisher per- selector cryptographic-key-lifecycle rotation-cadence integrity discipline (per-selector primary-key publication, per-selector rotation-secondary-key publication, per-selector key-revocation- marker publication, per-selector outbound signing-key cutover, per-selector public- key-TXT-RR deprecation), the reporting- pipeline spoke is the per-publisher per- receiver per-day RUA-aggregate-XML ingestion-pipeline reference documenting the per-receiver per-message DKIM- verification verdict observability channel through which per-publisher per-selector rotation-cadence cutover commits MUST be verified: the per-publisher per-receiver per-day DKIM-pass-rate KPI surface in the per-publisher RUA-aggregate-XML evidence stream is the LOAD-BEARING per-publisher per-selector rotation-completion- verification observability channel — without per-receiver per-message DKIM- verification verdicts being captured at Stage 1 of the pipeline, batched at Stage 2, delivered at Stage 3, ingested at Stage 4, and surfaced as per-source-IP per-disposition rows at Stages 5 and 6, the per-publisher per-selector rotation- cadence integrity discipline THIS page documents has no per-receiver per-day verification surface to consult. Read THIS page when AUTHORING per-publisher per-selector DKIM-key rotation-cadence cutover plans; read the reporting- pipeline spoke when VERIFYING per- receiver per-day DKIM-pass-rate KPI impact of a per-publisher per-selector rotation cutover via the RUA aggregate- XML evidence-stream surface.
• DMARC myths and misconceptions debunked — the 18-myth operator-mental-model correction catalogue covering recurring DMARC misconceptions whose protocol- layer refutations the per-protocol-pillar reference pages provide. The DKIM-key- rotation myth class this page directly refutes covers the per-publisher operator-mental-model errors around rotation cadence and primary+rotation- secondary selector publication — the recurring "we rotated the key but DKIM is still failing" rollout blocker, the "once rotated, we can remove the old selector immediately" cutover-window miscalculation, and the "key rotation breaks DMARC alignment" misconception. Read THIS rotation operational reference alongside the myths catalogue when operators raise rotation-cadence rollout-blocker questions during DMARC ramp progression — the per-publisher per-selector rotation-overlap discipline THIS page documents IS the protocol-layer refutation the myths catalogue cites at the rotation-mental-model myth class.
• Phishing protection — the DEFENDER-SIDE-PHISHING-ATTACK- CLASS-ENUMERATION-AT-PER-PROTOCOL-LAYER- MITIGATION-PILLAR companion to this DKIM key-rotation reference. Where THIS page documents the per-publisher per-selector DKIM key-rotation operational discipline (publish new selector2._domainkey with active key, run overlap window with both selectors live for ≥1 receiver-side cache TTL, transition ESP/signer to new selector, revoke old key via empty p= after confirmed receiver-side cache expiry), the phishing-protection cluster-level enumeration spoke is the cluster-level DEFENDER-SIDE-PHISHING-ATTACK-CLASS- CATALOGUE REFERENCE documenting the six canonical per-protocol-layer phishing attack classes plus the per-protocol- layer mitigation pillar that closes each class. The DKIM-KEY-ROTATION-VS-PHISHING- PROTECTION cross-reference establishes that the per-publisher per-selector DKIM rotation-cadence discipline IS the per- cryptographic-key-staleness mitigation pillar for the HISTORICAL-DKIM-KEY-REPLAY phishing-bypass attack class — an attacker who exfiltrates a per-publisher per-selector DKIM private key (compromised signing infrastructure, leaked from retired ESP, recovered from misconfigured backup) can replay-sign a phishing message with the leaked key, and the message will verify as dkim=pass with the per-publisher's d= domain until the per-publisher per-selector rotation cadence revokes the compromised key. The per-publisher per-selector rotation discipline THIS page documents (canonical cadence: 6-month rotation for active selectors, immediate rotation on signing-infrastructure-compromise suspicion, revocation via empty p= publication) closes the historical-key-replay phishing-bypass attack window at the per-publisher per- selector revocation boundary. Read THIS page when AUTHORING per-publisher per- selector DKIM rotation cadence; read the phishing-protection cluster-level enumeration spoke when MAPPING per- publisher per-selector rotation cadence coverage to the per-receiver per-attack- class defender-side enumeration, or when CO-AUDITING the per-publisher per- protocol-layer mitigation-pillar completeness across SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA / ARC at per-attack-class closure boundaries.
• MTA-STS policy-file syntax — the PER-PUBLISHER-PER-DOMAIN- RFC-8461-MTA-STS-POLICY-FILE-BYTE-GRAMMAR- PUBLICATION-DISCIPLINE-AS-LOAD-BEARING- PEER-TRANSPORT-LAYER-PUBLICATION-COMMIT- CADENCE-COMPANION companion to this DKIM- key-rotation operational reference. Where THIS page documents the per-publisher per-selector DKIM key-rotation operational discipline at the application layer (key- generation, rotation-overlap selector coexistence, primary-secondary selector swap, empty p= revocation publication, per-publisher per-selector rotation cadence), the MTA-STS-policy- syntax spoke is the peer per-publisher per-domain RFC 8461 transport-layer policy-file publication discipline whose per-publication-discipline rhythm pairs operationally with the DKIM rotation cadence at FOUR per-publication-discipline coupling dimensions: (i) per- publisher per-domain coordinated DNS-and- resource publication-leaf cadence parallelism — DKIM key rotation requires per-publisher per- selector publication at <selector>._domainkey.<domain> DNS leaves, MTA-STS policy publication requires per-publisher per-domain coordinated publication at BOTH the _mta-sts.<domain> TXT leaf (the policy-version pointer) AND the HTTPS-served https://mta-sts.<domain>/.well-known/mta-sts.txt URI (the policy-file body), and the per- publisher per-domain operator-side publication-discipline rhythm THIS page documents for per-selector DKIM rotation commits structurally mirrors the per- publisher per-domain TXT-pointer + HTTPS-policy-file commit-pair rhythm the MTA-STS-policy-syntax spoke documents at the transport layer; (ii) per- publisher per-domain three-mode rotation- cadence-progression parallelism — the per-publisher per-selector DKIM rotation cadence ramps through the primary-selector → secondary-selector coexistence → primary-secondary swap → empty p= revocation lifecycle THIS page documents, the per-publisher per-domain MTA-STS three-mode policy progression ramps through mode: none → mode: testing → mode: enforce the MTA-STS- policy-syntax spoke documents, and the per-publisher per-domain operator-side per-mode-progression commit discipline is the load-bearing rhythm BOTH layers share at the per-publication-step boundary; (iii) per-publisher per-domain rotation-misstep failure-mode catalogue parallelism — DKIM key rotation missteps surface as per-message DKIM-fail / DKIM-permerror failure-mode rows in the per-publisher per-domain DMARC aggregate rua stream, MTA-STS policy- syntax missteps surface as per-receiver per-session sts-policy-fetch-error / sts- policy-invalid / sts-webpki-invalid failure-mode rows in the per-publisher per-domain TLS-RPT failure-details aggregation stream the MTA-STS-policy- syntax spoke documents, and the per- publisher per-domain operator-side rotation-failure-mode-detection discipline runs against BOTH telemetry streams in parallel; (iv) per-publisher per- domain max_age:-cache-window-vs- DKIM-rotation-overlap-window operational coordination — the per- publisher per-domain MTA-STS max_age: caching-budget directive determines the per-receiver per- resolver policy-file-cache TTL window (typically 86400s–604800s) during which a published policy-file change does NOT propagate to receivers, and the per- publisher per-domain DKIM-rotation overlap- window THIS page documents must be sized with awareness of the MTA-STS max_age:-driven receiver- side policy-fetch cadence — emergency DKIM- revocation publication with empty p= coexists with MTA-STS cached-policy-file mode=enforce state at the per-receiver per-session boundary the MTA-STS-policy-syntax spoke documents the publication-discipline contract for. Read THIS page when AUTHORING per-publisher per-selector DKIM rotation cadence; read the MTA-STS-policy-syntax spoke when CO- AUTHORING the per-publisher per-domain transport-layer policy-file publication discipline whose per-publication-step commit cadence pairs operationally with the DKIM rotation discipline THIS page documents at the application layer.
• include: vs ip4: vs a: vs mx — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-DECISION-VIEW-AS-LOAD-BEARING- PEER-PROTOCOL-LAYER-DNS-PUBLICATION- CADENCE companion to this DKIM-key-rotation cadence reference. Where THIS page documents the per-publisher per-selector DKIM key- rotation cadence at the per-selector cryptographic-publication-discipline layer (per-selector overlap-window cadence between OLD-selector retirement and NEW- selector activation, per-selector empty- p= revocation publication pattern, per-selector rotation-misstep failure-mode catalogue, per-selector RSA- 2048 → Ed25519 algorithm-migration cadence), the include-vs-ip4-vs-a-vs-mx spoke is the peer per-publisher per-domain SPF-mechanism-decision-view whose per- mechanism-choice publication discipline determines the per-publisher per-domain SPF-record zone-edit-publication cadence and pairs operationally with the per- publisher per-selector DKIM key-rotation cadence THIS page documents at FOUR per- publication-cadence coupling dimensions: (i) peer per-publisher per-domain DNS-publication-cadence parallelism between per-selector DKIM TXT-RR rotation and per-domain SPF TXT-RR mechanism- update — the per-publisher per-selector DKIM TXT-RR rotation cadence THIS page documents at the per-selector cryptographic-publication-discipline layer pairs operationally with the per-publisher per-domain SPF TXT-RR mechanism-update cadence the include-vs-ip4-vs-a-vs-mx spoke documents the per-mechanism-choice rationale of — both are per-publisher per- domain DNS-leaf publication-cadence operations whose per-publication-step zone-edit-discipline coordination is the load-bearing per-publisher per-domain DNS-publication-cadence rhythm every per- publisher per-domain DMARC-deployment programme requires; (ii) per- publication-step zone-edit-discipline parallelism — per-selector DKIM TXT-RR publication-step coordination vs per- domain SPF mechanism-choice publication- step coordination — the per-publisher per-selector DKIM TXT-RR rotation publication-step discipline THIS page documents (per-selector OLD-and-NEW TXT-RR coexistence overlap window, per- selector empty-p= revocation publication step, per- selector TTL-decay-vs-cadence coordination) pairs operationally with the per-publisher per-domain SPF mechanism-choice publication-step discipline the include- vs-ip4-vs-a-vs-mx spoke documents (per- include: upstream-revision propagation step, per-ip4: literal-IP-range edit step, per- a: A-record-lookup coordination step, per-mx: MX-RR-set drift coordination step) at the per-publisher per-domain SPF TXT-RR layer — together the two per-protocol-layer publication-step disciplines compose the per-publisher per-domain complete cross- protocol-pillar DNS-publication-step coordination posture; (iii) per- publisher per-domain trust-anchor-renewal- vs-mechanism-evolution publication coordination — the per- publisher per-selector DKIM key-rotation cadence THIS page documents is the per- selector cryptographic-trust-anchor- renewal operational cadence whose peer per-publisher per-domain mechanism- evolution publication cadence is the per-publisher per-domain SPF-mechanism- choice evolution cadence the include-vs- ip4-vs-a-vs-mx spoke documents the per- mechanism-choice rationale of (per- publisher per-domain include:-set composition evolution as third-party-publisher adoption / retirement, per-publisher per- domain ip4: IP-range evolution as infrastructure-migration cadence, per- publisher per-domain a:/ mx: infrastructure-evolution cadence as A-and-MX-RR-set drift) — both are per-publisher per-domain operational publication-cadence-evolution rhythms every per-publisher per-domain DMARC- deployment programme coordinates at the per-publisher per-domain DNS-publication- cadence boundary; (iv) per- publisher per-domain operator-side cross- protocol-pillar DNS-publication-cadence rhythm composition — the per-publisher per-selector DKIM rotation cadence THIS page documents at the per- selector cryptographic-publication- discipline layer pairs operationally with the per-publisher per-domain SPF- mechanism-choice publication-cadence rhythm the include-vs-ip4-vs-a-vs-mx spoke documents (per-include: upstream-driven cadence, per- ip4:/a:/ mx: infrastructure-driven cadence), and the per-publisher per- domain operator-side per-protocol-pillar publication-cadence-composition discipline is the load-bearing per-publisher per- domain cross-protocol-pillar DNS- publication-cadence rhythm that every per-publisher per-domain DMARC-deployment programme requires for sustainable per- protocol-pillar publication-cadence coordination. Read THIS page when SCHEDULING per-publisher per-selector DKIM key- rotation cadence; read the include-vs- ip4-vs-a-vs-mx spoke when CHOOSING the per-publisher per-domain SPF-mechanism publication approach (include:, ip4:, a:, or mx:) whose per-mechanism-choice publication- cadence pairs operationally with the per- publisher per-selector DKIM key-rotation cadence THIS page documents at the per- publisher per-domain cross-protocol-pillar DNS-publication-cadence-composition boundary.
• BIMI SVG Tiny PS requirements — the per-publisher per-domain BIMI SVG Tiny PS asset-rotation overlap-window publication-discipline companion to this DKIM-key-rotation reference. Where THIS page documents the per-publisher per-selector DKIM-key-rotation overlap-window discipline (publish new selector with new key, wait for receiver-resolver-cache TTL-bounded propagation, retire old selector), the BIMI SVG Tiny PS requirements spoke is the PER- PUBLISHER-PER-DOMAIN-BIMI-SVG-ASSET- ROTATION-OVERLAP-WINDOW-PUBLICATION reference documenting the per-publisher per- domain BIMI SVG Tiny PS asset-rotation overlap-window discipline (publish new SVG with new VMC binding, wait for per-receiver BIMI-evaluator-cache flush, retire old SVG + VMC). Four PER-PUBLISHER-PER-DOMAIN- ROTATION-WINDOW-PUBLICATION-DISCIPLINE- COUPLING dimensions the BIMI SVG Tiny PS requirements spoke documents: (i) per-publisher per-domain cryptographic-asset vs display-asset rotation-overlap-window discipline parallel — both the per-publisher per-selector DKIM key-rotation overlap- window discipline this page documents and the per-publisher per-domain BIMI SVG Tiny PS asset-rotation overlap-window discipline are per-publisher per-domain rotation- overlap-window publication-discipline primitives at distinct layers (per-message cryptographic-signing-key vs per-receiver display-asset); (ii) per-publisher per-selector DKIM-key rotation cadence vs per-publisher per-domain BIMI-SVG-asset rotation cadence coordination — the per-publisher per-selector DKIM-key- rotation cadence this page documents (typically quarterly or biannual) interacts with the per-publisher per-domain BIMI-VMC cert-renewal cadence (annual cert lifecycle) whose VMC-renewal-bound SVG-asset rotation the BIMI SVG Tiny PS requirements spoke documents — both must be coordinated at the per-publisher per-domain cross-protocol- pillar rotation-cadence-composition boundary; (iii) per-publisher per- domain DKIM-aligned-pass coverage-rate as upstream prerequisite for BIMI-display-gate eligibility — the per-publisher per-selector DKIM-key rotation that preserves the per-publisher per-domain DKIM-aligned-pass coverage-rate THIS page documents is the load-bearing upstream prerequisite for the BIMI-display-gate eligibility the SVG-Tiny-PS-asset publication the BIMI SVG Tiny PS requirements spoke documents depends on; (iv) per- publisher per-domain DKIM-key revocation vs BIMI-SVG-asset deprecation publication- discipline parallel — DKIM's p= empty-public-key revocation publication (per-selector key explicitly retired) structurally parallels BIMI's per- publisher per-domain SVG-asset deprecation publication (per-domain SVG asset explicitly retired with VMC binding revoked) — both are per-publisher per-domain explicit- deprecation-publication-discipline primitives at distinct cryptographic vs display layers. Read the BIMI SVG Tiny PS requirements spoke alongside this DKIM-key- rotation reference when DESIGNING the per- publisher per-domain cross-protocol-pillar rotation-overlap-window publication- discipline that pairs per-publisher per- selector DKIM-key-rotation cadence with per-publisher per-domain BIMI-SVG-asset rotation cadence at the per-publisher per- domain authentication-and-display posture composition boundary.
• BIMI explained — the per-publisher per-domain BIMI receiver- side brand-indicator display-eligibility companion to this DKIM-key-rotation operational discipline reference. Where THIS page documents the per-publisher per-selector 90-day-cadence dual-selector zero-downtime rotation procedure (the selector1 → selector2 swap, the TTL-bounded overlap window, the seven rotation-induced failure modes), the BIMI-explained pillar documents the per-publisher per-domain receiver-side brand-indicator display surface whose DMARC-policy-enforcement precondition (p=quarantine or p=reject at the organizational- domain BIMI-lookup boundary) is structurally GATED on the per-publisher per-receiver per-day DKIM-aligned-pass-rate floor THIS page's per- selector rotation-cadence integrity directly produces, at FOUR per-publisher per-domain per- selector-rotation-cadence-to-BIMI-display- eligibility-precondition coupling dimensions: (i) per-publisher per-receiver per-day DKIM-pass-rate floor as the load- bearing upstream input to the per-publisher per-receiver per-day DMARC-composite-pass-rate floor that, when sustained above the per- receiver BIMI-eligibility threshold for the per-receiver BIMI-evaluation window, qualifies the per-publisher per-domain for per-message brand-indicator display — the per-selector rotation-overlap-window discipline THIS page documents directly co-authors the per-day DKIM-pass-rate floor projection that gates BIMI eligibility; (ii) per- publisher per-domain per-selector cryptographic- publication-cadence (the DKIM selector1._domainkey.<domain> → selector2._domainkey.<domain> zone-edit cadence + TTL-bounded overlap window) as the per-publisher per-domain DNS-publication- cadence peer-pair of the per-publisher per- domain BIMI default._bimi.<domain> TXT-RR publication cadence + a=<vmc-uri> VMC trust-anchor URI republish cadence + Tiny PS SVG asset rotation cadence — both per-publisher per- domain rotation cadences co-occupy the per- domain DNS zone-edit window and share per- domain DNS-publication-commit operator discipline at the application-layer- cryptographic-publication-vs-display-layer- trust-anchor-publication composition boundary; (iii) per-selector cryptographic-staleness risk class (the per- publisher per-selector DKIM private-key reaching end-of-life and the public-key-RR- cache-eviction-overlap-window mis-sizing class THIS page enumerates) peer-pairing the per- publisher per-domain BIMI VMC cryptographic- expiration risk class (the BIMI Mark Certificate reaching per-CA-policy pre-expiry renewal window vs the per-receiver BIMI- evaluator cached VMC-trust-anchor cache- eviction window) at the per-publisher per- domain joint cryptographic-publication- staleness-discipline coordination boundary; and (iv) per-publisher per- receiver per-day DMARC RUA XML aggregate- report per-selector DKIM-verdict aggregation (the per-report <auth_results><dkim> per-selector per-source-IP per-day DKIM- verdict evidence stream THIS page's per- selector rotation-cadence integrity directly produces) as the joint per-publisher per- receiver per-day observability evidence stream whose per-receiver per-day DKIM-aligned-pass- rate aggregate projection feeds both the per- publisher per-domain DMARC-policy-mode-ramp phase-advancement-readiness gate (THIS page's operational rationale) AND the per-publisher per-domain BIMI-display-eligibility- precondition readiness gate (the BIMI- explained pillar's operational rationale) at the per-publisher per-domain per-receiver per-day evidence-stream composition boundary.
• Why SPF alone is insufficient — the per-publisher per-domain WHY-DKIM-KEY-ROTATION-EXISTS-AT-ALL motivating- rationale companion to this DKIM-key-rotation operational discipline reference. Where THIS page documents the per-publisher per-selector DKIM-key rotation cadence + per-rotation-cycle overlap-window publication-discipline (per-selector active-key vs scheduled- successor-key dual-publication, per-selector DNS TTL-aware promote-and-retire sequencing, per-publisher per-selector retire-by- overwriting-with-empty-public-key revocation discipline), the why-SPF-alone-is-insufficient spoke documents the per-publisher per-domain SPF-only THREAT-MODEL coverage gap that MOTIVATES the existence of the per-publisher per-selector DKIM-key publication discipline the rotation cadence THIS page documents operationalises in the first place: SPF ALONE (i) BREAKS under per-message forwarding when intermediate MTAs rewrite the MAIL FROM envelope; (ii) provides NO per-non-existent- subdomain coverage; (iii) provides NO per- message MAIL-FROM-vs-From-header alignment visibility; and (iv) provides NO per-message message-integrity protection — every one of which is the structural per-publisher per- domain coverage gap the per-publisher per- selector DKIM-Signature header cryptographic-message-integrity publication discipline THIS page's rotation cadence operationalises CLOSES. Three per-publisher per-selector DKIM-key-rotation operationalisation-rationale dimensions the why-SPF-alone-is-insufficient spoke supplies the per-publisher per-domain operator MUST UNDERSTAND at the per-publisher per-selector DKIM-key-rotation authoring tier: (i) per-publisher per-message message-integrity-publication-discipline- motivation as the per-publisher per-domain SPF-only-coverage-gap-closure rationale — the per-publisher per-message message- integrity gap the per-publisher per-domain SPF-only publication discipline LEAVES OPEN (per-message body-and-headers post-SPF-pass remain mutable) is THE per-message cryptographic-message-integrity coverage gap the per-publisher per-selector DKIM-Signature publication discipline THIS page's rotation cadence operationalises CLOSES — operators understanding the per-publisher per-domain SPF-only-coverage-gap-as-message-integrity- absence frame the per-selector DKIM-key- rotation cadence as the per-publisher per- domain message-integrity-publication- discipline operational primitive at the per- publisher per-selector cadence tier; (ii) per-publisher per-message forwarding-survival-publication-discipline- motivation as the per-publisher per-domain SPF-only-forwarding-breakage closure rationale — the per-message SPF- fail-after-forward breakage the per-publisher per-domain SPF-only publication discipline suffers under per-message MAIL FROM rewriting is THE per-message forwarding-survival coverage gap the per-publisher per-selector DKIM-Signature publication discipline THIS page's rotation cadence operationalises CLOSES (per-message DKIM-Signature header survives per-message MAIL FROM rewriting by intermediate MTAs because per-message DKIM- Signature byte-grammar is independent of envelope-layer MAIL FROM byte-grammar) — operators understanding the per-publisher per-domain SPF-only-forwarding-breakage frame the per-selector DKIM-key-rotation cadence as the per-publisher per-domain forwarding- survival-publication-discipline operational primitive at the per-publisher per-selector cadence tier; (iii) per-publisher per-message replay-window-bounding- publication-discipline-motivation as the per- publisher per-domain SPF-only-no-replay-defence closure rationale — the per-message SPF-only publication discipline provides NO per-message replay defence (per-message SPF- pass verdict is replayable by any sender controlling the per-publisher per-domain envelope MAIL FROM); the per-publisher per- selector DKIM-key-rotation cadence THIS page documents BOUNDS the per-publisher per- selector per-message replay window to the per-selector active-key lifetime (a per- selector key live for 90 days admits at most 90 days of per-message replay; aggressive rotation at weekly or daily cadence for high- value senders constrains the per-message replay window to days or hours) — operators understanding the per-publisher per-domain SPF-only-no-replay-defence gap frame the per- selector DKIM-key-rotation cadence as the per-publisher per-domain replay-window- bounding operational primitive at the per- publisher per-selector cadence tier. Read the why-SPF-alone-is-insufficient spoke ALONGSIDE this DKIM-key-rotation reference whenever the per-publisher per-domain operator AUDITS the per-publisher per- selector DKIM-key-rotation-cadence-as-SPF- only-coverage-gap-closure rationale for the per-publisher per-domain DKIM publication investment.
• DMARC policy rollout — the PER-PUBLISHER-PER-DOMAIN-DMARC-POLICY- RAMP-AS-LOAD-BEARING-CONSUMER-OF-PER-SELECTOR- DKIM-KEY-ROTATION-CADENCE-CONTINUITY companion to this per-publisher per-selector DKIM-key- rotation cadence reference. Where THIS page documents the per-publisher per-selector key-rotation cadence + dual-selector overlap- window + per-tenant compromise-revocation emergency-rotation procedure as the LOAD- BEARING per-publisher per-day per-receiver DKIM-aligned-pass-rate continuity discipline, the policy-rollout spoke documents the FOUR PER-DMARC-RAMP-PHASE-AS-DKIM-KEY-ROTATION- CADENCE-CONSUMER DIMENSIONS the per-publisher per-domain operator MUST coordinate to advance through the canonical p=none → p=quarantine → p=reject ramp without per-phase rollback: (i) per-phase ADVANCEMENT GATE driven by per-publisher per-receiver per-day DKIM-aligned-pass-rate floor — the per-publisher per- domain operator MUST observe a per-receiver per-day DKIM-aligned-pass-rate ≥ 95 % across the trailing 14-day per-receiver-aggregate- report window BEFORE advancing from p=none to p=quarantine, and that floor is structurally gated on the per-selector key-rotation continuity discipline THIS page documents — a per-selector rotation overlap-window error during the p=none phase masks itself in the aggregate-report stream as a per-day per- receiver DKIM-aligned-pass-rate dip that defeats the advancement-gate criterion; (ii) per-phase pct= percentage- gradual-quarantine STEP-FUNCTION as per- selector rotation-overlap-window risk- management primitive — the per- publisher per-domain operator advances from p=quarantine; pct=10 through pct=25 / pct=50 / pct=75 / pct=100 on a weekly-to-fortnightly cadence so a per- selector rotation-overlap-window error during a per-quarantine-percentage-step is bounded to the per-percentage-quarantined per-day receiver-side message-fraction blast radius; (iii) per-phase advancement-PAUSE on per-selector emergency-revocation EVENT — the per-publisher per-domain operator MUST FREEZE the policy-rollout cadence at the current phase the moment a per-tenant per- selector DKIM-key-compromise incident triggers the emergency-revocation workflow THIS page documents, because the per-receiver per-day per-selector DKIM-aligned-pass-rate floor will DIP during the emergency-rotation overlap window and per-phase advancement during the dip will compound the per-receiver per-day rejection blast radius; (iv) per- receiver per-day rua= aggregate- report ingestion as joint per-selector- rotation-cadence + per-policy-ramp-phase observability primitive — the per- publisher per-domain operator reads the per- day per-receiver rua= aggregate report as the SINGLE observability surface that surfaces BOTH per-selector rotation- cadence DKIM-aligned-pass-rate continuity evidence AND per-policy-ramp-phase enforcement-verdict-distribution evidence, letting the operator attribute a per-receiver per-day per-phase enforcement-distribution deviation to the SPECIFIC per-selector rotation-cadence root cause OR per-policy- ramp-phase configuration error. Read the policy-rollout spoke ALONGSIDE this DKIM- key-rotation reference whenever the per- publisher per-domain operator COORDINATES the per-selector key-rotation cadence with the per-DMARC-ramp-phase advancement cadence — the per-policy-ramp-phase-as-DKIM- rotation-cadence-consumer coordination catalogue is the canonical operator-facing companion every per-publisher per-domain DKIM-key-rotation operator MUST master to advance through the canonical p=none → p=quarantine → p=reject ramp without per-phase rollback.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the PER-PUBLISHER-PER-SELECTOR-DKIM-KEY- ROTATION-CADENCE-AS-PER-PUBLISHER-PER-DOMAIN- DKIM-ALIGNED-PASS-RATE-FLOOR-PRECONDITION-FOR- DMARC-POLICY-MODE-RAMP-PHASE-ADVANCEMENT- READINESS companion to THIS DKIM key-rotation reference. Where THIS page documents the per- publisher per-selector RSA-2048 / Ed25519 key- pair generation cadence, the per-publisher per-selector dual-publication overlap-window discipline during key-rollover (publish new selector → validate per-receiver per-message signed-mail-flow → retire old selector), the per-publisher per-selector DKIM private-key custody discipline, and the per-publisher per- selector emergency-revocation incident-response workflow on key-compromise detection, the DMARC-policy-modes spoke documents the publisher-side three-state p=-tag enforcement-policy ladder (p=none observe-only, p=quarantine probation, p=reject terminal) whose per-phase advancement gate the per- publisher per-selector DKIM key-rotation cadence structurally co-authors at FOUR per- publisher per-domain application-layer policy- mode-ramp-coordination dimensions: (i) per-publisher per-selector DKIM key- rotation overlap-window discipline as per- publisher per-domain DKIM-aligned-pass-rate- floor preservation precondition for per- receiver per-policy-mode-ramp phase advancement — per-publisher per- selector key-rotation overlap-window without dual-selector publication creates a per- receiver per-message DKIM-verifier-side verification-key-fetch gap where the per- receiver per-message DKIM-Signature header cites a per-selector public-key TXT-RR that does not yet exist (rotation gap) OR no longer exists (retirement gap), and the per- publisher per-domain DKIM-aligned-pass-rate floor DIPS at the per-receiver per-message DKIM-verifier boundary during the rotation gap window, compounding the per-receiver per- policy-mode rejection blast-radius during per-publisher per-domain DMARC p=quarantine/p=reject phase advancement; (ii) per-publisher per-selector DKIM key-compromise emergency- revocation workflow as per-publisher per- domain DMARC policy-mode-ramp FREEZE-AND- ROLLBACK trigger — the per-publisher per-domain operator MUST freeze the per- publisher per-domain DMARC policy-mode-ramp at the current phase the moment a per- publisher per-selector DKIM-key-compromise incident triggers the per-publisher per- selector emergency-revocation workflow THIS page documents, because the per-receiver per- message DKIM-aligned-pass-rate floor will DIP during the per-publisher per-selector emergency-rotation overlap-window AND per- publisher per-domain DMARC policy-mode-ramp phase advancement during the DKIM-aligned- pass-rate dip will compound the per-receiver per-policy-mode rejection blast-radius at the per-publisher per-domain receiver-side enforcement boundary; (iii) per- publisher per-selector DKIM key-rotation cadence as per-publisher per-domain DMARC p=quarantine / p=reject phase-advancement readiness gate — the per-publisher per-domain operator advances p=none → p=quarantine ONLY AFTER the per-publisher per-selector key-rotation cadence is operationally validated against the per-receiver per-message DKIM-aligned- pass-rate floor evidence; advances p=quarantine → p=reject ONLY AFTER the per- publisher per-selector key-rotation cadence is producing stable per-receiver per-message DKIM-aligned-pass-rate evidence at the per- receiver per-day per-publisher per-domain RUA aggregate-XML report's per-DKIM-selector per-record row distribution; (iv) per- receiver per-day RUA aggregate-XML report's per-DKIM-selector per-disposition row attribution as joint observability surface for selector-rotation cadence + policy-mode- ramp phase enforcement-distribution evidence — the per-publisher per- domain operator reads the per-day per- receiver per-publisher per-domain RUA aggregate-XML report's auth_results/dkim/selector per-record attribution to correlate per- publisher per-selector rotation-cadence with per-publisher per-domain DMARC policy-mode- ramp phase enforcement-distribution outcomes, attributing per-policy-mode disposition- verdict variance to per-publisher per- selector rotation-cadence root cause OR per- publisher per-domain application-layer DMARC-record root cause at the per-publisher per-domain receiver-side enforcement boundary. Read THIS DKIM key-rotation reference when EXECUTING the per-publisher per-selector rotation cadence AND when GATING the per- publisher per-domain DMARC policy-mode-ramp phase advancement against the per-publisher per-selector DKIM-aligned-pass-rate-floor readiness; read the DMARC-policy-modes spoke when COORDINATING the per-publisher per- domain application-layer DMARC enforcement- ramp phase advancement against the per- publisher per-selector DKIM key-rotation readiness floor THIS page documents.
• SPF mechanisms explained — the PER-PUBLISHER-PER-DOMAIN-SPF- MECHANISM-AUTHORING-AS-STRUCTURALLY- PARALLEL-ENVELOPE-MAIL-FROM-LAYER- PUBLICATION-OPERATIONAL-DISCIPLINE- COUNTERPART-TO-DKIM-KEY-ROTATION-CADENCE companion to THIS DKIM key-rotation operational-discipline reference. Where THIS page documents the per-publisher per- selector DKIM key-rotation cadence discipline (per-publisher per-selector annual-quarterly key-rotation cadence floor, per-publisher per-selector dual- selector overlap for DNS-propagation- window publisher-side staging, per- publisher per-selector retired-selector TXT-RR removal cadence, per-publisher per- selector key-length progression discipline from 1024-bit RSA to 2048-bit RSA / Ed25519 per RFC 8301 + RFC 8463), the SPF- mechanisms-explained spoke is the PER- PUBLISHER-PER-DOMAIN-ENVELOPE-MAIL-FROM- LAYER-PUBLICATION-OPERATIONAL-DISCIPLINE counterpart at FOUR per-SPF-mechanism- authoring-vs-DKIM-key-rotation parallelism dimensions: (i) per-publisher per- domain SPF include: cascade-membership audit cadence AS structurally-parallel envelope-MAIL-FROM-layer publication- operational-discipline counterpart to per- publisher per-selector DKIM key-rotation cadence application-layer publication- operational-discipline — the per-publisher per-domain SPF include: cascade-membership audit cadence the SPF- mechanisms-explained spoke documents (per- publisher per-domain include: cascade-list per-quarter membership audit, per-publisher per-domain per-third-party-SaaS-sender ESP- include freshness audit, per-publisher per- domain retired-ESP-include removal discipline) IS the structurally-parallel per-publisher per-domain envelope-MAIL- FROM-layer publication-operational- discipline counterpart to the per-publisher per-selector DKIM key-rotation cadence application-layer publication-operational- discipline THIS page documents the per- publisher per-selector quarterly rotation- cadence floor publishing-readiness audit of; (ii) per-publisher per-domain SPF ip4: range publication-staging operational discipline AS structurally- parallel publisher-side envelope-MAIL- FROM-layer staging-discipline counterpart to per-publisher per-selector DKIM dual- selector overlap publisher-side staging- discipline — the per- publisher per-domain SPF ip4: range publication-staging operational discipline the SPF-mechanisms-explained spoke documents (per-publisher per-domain new- ip4: range publication BEFORE per-source- IP first-message emission, per-publisher per-domain retired-ip4: range removal AFTER per-source-IP last-message emission + per-DNS-propagation-window grace period, per-publisher per-domain ip4: range publication-staging coordination against per-source-IP-pool egress-cutover cadence) IS the structurally-parallel per- publisher per-domain envelope-MAIL-FROM- layer staging-discipline counterpart to the per-publisher per-selector DKIM dual- selector overlap publisher-side staging- discipline THIS page documents the per- publisher per-selector new-selector- publication-BEFORE-first-signing + per- selector retired-selector-removal-AFTER- last-signing + per-DNS-propagation-window grace-period discipline of; (iii) per-publisher per-domain SPF mechanism-publication operational-discipline audit-rhythm AS load-bearing per-publisher per-domain operational-hygiene-rhythm complement to per-publisher per-selector DKIM key-rotation operational-hygiene- rhythm — the per-publisher per-domain SPF mechanism-publication operational-discipline audit-rhythm the SPF-mechanisms-explained spoke documents (per-publisher per-domain quarterly SPF record-audit cadence + per-publisher per- domain monthly include: cascade-depth audit + per-publisher per-domain weekly per-source-IP egress-pool reconciliation) IS the per-publisher per-domain envelope- MAIL-FROM-layer operational-hygiene-rhythm complement to the per-publisher per- selector DKIM key-rotation operational- hygiene-rhythm THIS page documents (per- publisher per-selector annual-quarterly rotation cadence + per-publisher per- selector retired-key timed-removal); per- publisher per-domain operators schedule BOTH per-publisher per-domain envelope- MAIL-FROM-layer + per-publisher per- selector application-layer operational- hygiene rhythms coordinated at the per- publisher per-domain unified-publication- operational-hygiene-discipline boundary; (iv) per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication-floor coordination AS load-bearing per-publisher per-domain operator-side unified-trust-signal- publication-discipline-floor — the per-publisher per-domain SPF mechanism-authoring publication- operational-discipline the SPF-mechanisms- explained spoke documents IS the load- bearing per-publisher per-domain envelope- MAIL-FROM-layer publication-operational- discipline leg of the per-publisher per- domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication-floor coordination posture the per-publisher per-selector DKIM key-rotation cadence discipline THIS page documents the per- publisher per-selector application-layer- cryptographic-publication-operational- hygiene leg of; per-publisher per-domain operators publish ALL FIVE per-publisher per-domain protocol-layer publications coordinated at the per-publisher per- domain unified-trust-signal-floor publication-readiness boundary. Read THIS page when AUTHORING the per- publisher per-selector DKIM key-rotation cadence discipline; read the SPF- mechanisms-explained spoke when AUTHORING the per-publisher per-domain envelope- MAIL-FROM-layer SPF mechanism-choice publication discipline whose per- publisher per-domain SPF mechanism- authoring publication-operational- discipline IS the structurally-parallel envelope-MAIL-FROM-layer publication- operational-discipline counterpart to the per-publisher per-selector DKIM application-layer-cryptographic- publication-operational-hygiene discipline THIS page documents.
• MTA-STS vs DANE for SMTP — the structurally parallel transport-layer publication-rotation operational-discipline companion to this DKIM key rotation application-layer publication-rotation reference. Where THIS page documents the per- publisher per-selector DKIM key rotation cadence (every 6-12 months per RFC 6376 §3.6.1 best-practice + per-publisher selector1/selector2 dual-selector rotation discipline + per- publisher per-message DKIM-Signature `s=` tag selector-switch transition), the MTA-STS-vs- DANE spoke documents the structurally parallel transport-layer publication-rotation cadence discipline whose per-publisher per-domain selection drives the per-MX-host certificate- and-key rotation cadence at the per-receiving- MTA STARTTLS enforcement boundary. Four per- protocol-layer publication-rotation cadence coupling dimensions matter at the per-publisher per-domain application-and-transport-layer rotation-discipline boundary: (i) per-publisher per-domain DUAL rotation-trigger primitive — per-publisher DKIM key rotation triggered by time-based cadence (6-12 month interval), per- publisher MTA-STS policy-id rotation triggered by per-domain per-MX-host set change, per- publisher DANE TLSA rollover triggered by per- domain per-MX-host certificate-and-key renewal; (ii) per-publisher per-domain DUAL rotation- ceremony cadence — per-publisher DKIM selector1/selector2 dual-selector switchover at per-domain DNS-zone-edit boundary, per-publisher MTA-STS id-bump + policy-content-update at per- domain HTTPS Well-Known-URI commit + TXT-RR id signal, per-publisher DANE 3-3-1 rollover ceremony per RFC 7671 §8 (publish-new → TTL wait → switch-active → TTL wait → retire-old); (iii) per-publisher per-domain DUAL operational rotation cadence discipline — per-publisher DKIM 6-12 month best-practice cadence at per- domain DNS-zone commit-and-propagation boundary, per-publisher MTA-STS opportunistic cadence at per-domain Well-Known-URI commit-and-cache boundary, per-publisher DANE per-certificate- renewal cadence at per-MX-host zone-file commit- and-propagation boundary; (iv) per-publisher per-domain DUAL composite application-and- transport-layer publication-rotation portfolio — per-publisher DKIM key rotation + per-publisher SPF record audit + per-publisher MTA-STS-or- DANE transport-layer publication-rotation form the composite per-publisher per-domain publication-rotation operational-discipline portfolio every per-publisher per-domain deployment THIS page documents materially coordinates publication-rotation operational discipline against.
• MTA-STS for Microsoft 365 — the PER-M365-TENANT-PER-CUSTOM- DOMAIN-MTA-STS-POLICY-ID-ROTATION-AS- STRUCTURALLY-PARALLEL-DKIM-KEY-ROTATION companion to this DKIM key rotation reference. Where THIS page documents the per-publisher per-selector DKIM key- rotation cadence and operational discipline (per-selector annual/semi-annual key-pair regeneration, per-selector DNS-TXT-RR publication overlap, per-selector retirement window after key-revocation, per-selector namespace versioning to support overlap rollover), the M365 MTA-STS spoke is the PER-M365-TENANT TRANSPORT-LAYER ROTATION- CADENCE reference the per-M365-tenant operator consults when coordinating the parallel transport-layer publication rotation. Four cross-layer rotation- cadence coordination dimensions: (i) PER- M365-TENANT-MTA-STS-POLICY-ID-ROTATION-VS- DKIM-SELECTOR-ROTATION (per-M365-tenant MTA-STS policy-id field rotation cadence drives per-receiver per- recursive-resolver cache-invalidation propagation — structurally parallel to per-publisher per-selector DKIM DNS- TXT-RR rotation cadence driving per- receiver per-recursive-resolver public- key-cache invalidation); (ii) PER-M365- TENANT-MTA-STS-HTTPS-POLICY-FILE-OVERLAP- VS-DKIM-SELECTOR-OVERLAP (per-M365-tenant HTTPS-served policy-file payload byte- content rotation requires overlap-window for in-flight MTA-STS-policy-fetch survival — structurally parallel to per-publisher per-selector DKIM publication overlap-window for in-flight DKIM-Signature verification survival); (iii) PER-M365- TENANT-MTA-STS-MX-ALLOW-LIST-ROTATION-VS- DKIM-KEY-COMPROMISE-REVOCATION (per-M365- tenant mx:-directive list rotation when M365 introduces new MX hostnames is structurally parallel to per-publisher per-selector DKIM key-pair regeneration after key-compromise revocation events); (iv) PER-M365-TENANT- MTA-STS-TLS-RPT-OBSERVABILITY-OF-ROTATION- BREAKAGE-VS-DKIM-DMARC-RUA-OBSERVABILITY- OF-KEY-ROTATION-BREAKAGE (per-M365-tenant MTA-STS rotation breakage surfaces in per-receiver TLS-RPT JSON sts-policy-fetch-error result-type rows — structurally parallel to per-publisher per-selector DKIM-key-rotation breakage surfacing in per-receiver DMARC RUA XML auth_results/dkim/result=fail rows). Read the M365 MTA-STS spoke alongside this DKIM key-rotation guide when AUTHORING the per-M365-tenant per- custom-domain composite cross-layer rotation-cadence coordination discipline, when PLANNING the per-M365-tenant per- custom-domain rotation-overlap window (whether to align MTA-STS policy-id rotation with DKIM key-rotation), or when INVESTIGATING per-M365-tenant per-custom- domain composite cross-layer deliverability regressions correlating with either rotation cadence breakage.
• MX records explained
• Reverse DNS PTR records
• MTA-STS explained
• SPF PermError vs TempError
• 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.

13. Audit your current DKIM signing keys now

DMARC Analyzer's Domain Security Checker performs a live recursive lookup of any published DKIM public key under a given selector (via includes/DnsChecker.php), reporting the key algorithm, key size, canonical selector name, and whether the record matches the RFC 6376 schema. The Email Header Analyzer parses the DKIM-Signature header from any message (via includes/EmailHeaderParser.php) and surfaces the signer's selector + algorithm + signed-header list + verification result - the data you need to confirm a rotation has correctly propagated to your outbound mail.

Check my DKIM public key Sign up — Free plan