DMARC Analyzer

TL;DR — the 15 DKIM best-practice rules

A healthy DKIM deployment in 2026 follows 15 prescriptive rules synthesized from RFC 6376, RFC 8301, RFC 8463, RFC 8617, and a decade of operator experience across the major mail ecosystems.

1. 2048-bit RSA minimum. RFC 8301 §3. 1024-bit is broken. (§2, algorithm)
2. Dual-publish k=rsa + k=ed25519 on separate selectors for forward compatibility. (§2)
3. Descriptive dated selector names. E.g., sel-2026a._domainkey — not k1 or default. (§3, selectors)
4. Annual rotation with 7-day dual-selector overlap, 30-day in-flight drain, 30-day empty-p= retention. (§4, rotation)
5. c=relaxed/relaxed canonicalization. Tolerates intermediary whitespace edits. (§5, canonicalization)
6. Sign From, Subject, Date, To, Reply-To, MIME-Version, Content-Type at minimum; OVERSIGN From, Subject, Date with the empty-double-list trick. (§6, h= list)
7. Leave i= empty (defaults to d=) unless documented per-AUID delegation required. (§7, AUID)
8. NEVER use l= body-length tag — replay-attack vector. (§8, l=)
9. t=y for 24-72h burn-in, then REMOVE. Stale t=y silently disables DMARC-via-DKIM. (§9, t=)
10. Single signature default; multi-signature only for documented algorithm-migration or sub-brand isolation. (§10, multi-signature)
11. Monitor Authentication-Results + DMARC aggregate daily; alert on verdict-distribution shifts. (§11, monitoring)
12. Multi-string TXT chunking for 2048-bit RSA keys per RFC 1035 §3.3.14. (§12, DNS)
13. Emergency revocation = empty-p= within minutes of compromise detection; NEVER delete the record. (§13, revocation)
14. Document every selector with name, deployment date, rotation history, owner. (§14, documentation)
15. Quarterly cluster audit: verify every above rule against every production selector. (§15, checklist)

Each rule below has its own deep-dive subsection explaining the rule, the rationale, the operator action, and the cross-references to the sibling cluster page that documents the underlying mechanism in detail.

1. What makes a DKIM deployment "best practice"

DKIM (RFC 6376) is a cryptographic protocol that works correctly at the protocol level for many different configurations — but only a subset of those configurations are operationally robust against the threat models that mature operators actually face: forwarder body-modification attacks, replay attacks (RFC 6376 §8), key compromise, intermediary header injection, sub- brand spoofing, DMARC alignment failures, and the long-running ed25519 vs RSA algorithm migration.

A "best practice" deployment is the configuration that survives those threat models without operational drift. The 15 rules synthesized below are the cluster-wide consensus from the 12 sibling DKIM-cluster pages — each rule traces back to a specific RFC mandate or a documented failure mode that operators have observed repeatedly.

Where this page fits in the cluster:

• Protocol pillar — what DKIM does (the cryptography, the verification flow, the verdict codes).
• Key-record syntax — how to encode the published public key (RFC 6376 §3.6.2).
• Header tag anatomy — what the signer emits per message (RFC 6376 §3.5).
• The 8 focused deep-dive pages: canonicalization, selectors, cryptography, key rotation, replay attacks, failures explained, alignment with DMARC, and troubleshooting.
• The 2 provider deployment guides: Microsoft 365, Google Workspace.
• THIS page is the synthesis layer — the actionable ruleset that operators execute against once they understand the underlying mechanism.

How to use this page: read the 15 TL;DR rules above, then jump to the rule subsection corresponding to whichever rule you are currently uncertain about. Each subsection cross-references the deep-dive page that documents the underlying mechanism — read both if you want the full background.

2. Algorithm and key size: 2048-bit RSA floor, dual-publish ed25519

Rule 1: 2048-bit RSA minimum. Per RFC 8301 §3, "Signers MUST NOT sign with rsa keys shorter than 1024 bits, and SHOULD use keys of 2048 bits or larger". The 1024-bit floor is a legacy compromise from RFC 6376 (2011); modern receivers downgrade verdicts on 1024-bit signatures to dkim=policy or treat them as dkim=fail. No production deployment in 2026 should publish a 1024-bit RSA key.

Rule 2: dual-publish k=rsa + k=ed25519 on separate selectors. RFC 8463 added k=ed25519 as a second valid key type with structural advantages (32-byte public keys, 64-byte signatures, faster verification). Receiver coverage of ed25519 has grown steadily since 2018 and is now near-universal among major receivers in 2026, but legacy spam appliances and small ISPs still produce dkim=neutral or dkim=permerror on ed25519. The dual-publish posture gives the signer a fallback:

; Selector 1 — RSA-2048:
selector1._domainkey.example.com   IN  TXT  ( "v=DKIM1; k=rsa; "
                                              "p=MIIBIjANBgkqhkiG9w0BAQEF..." )

; Selector 2 — ed25519:
selector2._domainkey.example.com   IN  TXT  "v=DKIM1; k=ed25519; p=11qYAYKxCrfVS/7TyWQHOg7hcvPapiMlrwIaaPcHURo="

The signer adds both signatures or alternates per message. For DMARC alignment, RFC 7489 §3.1.1 "any aligns wins" — if the receiver understands either signature and finds it aligned, DMARC passes via DKIM.

Cross-reference: help_dkim_cryptography_basics.php documents the RSA vs ed25519 algorithm choice in depth, including the multi-year migration timeline.

3. Selector naming: descriptive and dated

Rule 3: use descriptive dated selector names like sel-2026a, sel-2026b, m365-selector1 — not default, k1, dkim, or mail.

The selector name is operator-chosen and has no protocol semantics — receivers concatenate it with _domainkey.<d-value> and query as-is. But the name carries operational meaning for the humans maintaining the zone:

• Dated selectors (sel-2026a) make rotation history visible in the zone file — when you see sel-2024a, sel-2025a, and sel-2026a in the zone, you know rotation has been happening on schedule. Generic names (k1, k2) carry no rotation signal.
• Source-named selectors (m365-selector1, sendgrid-s1, internal-postfix-2026) make selector ownership visible — when an outage occurs and you need to identify which signer is responsible for a particular d= signature, the selector name itself points to the team.
• Avoid default — many provider wizards still suggest this name; it conflicts when multiple signers try to claim it and produces operationally- opaque diagnostics.

Cross-reference: help_dkim_selectors_explained.php documents the selector vocabulary in depth.

4. Rotation cadence: annual with dual-selector overlap

Rule 4: rotate every signing key once per year using the dual-selector overlap discipline.

The 67-day end-to-end rotation lifecycle:

1. Day 0: generate a new keypair, publish the public key at a NEW selector (e.g., sel-2026b if currently signing with sel-2026a). The old selector continues signing.
2. Day 7: verify the new selector resolves from multiple geographic resolvers (dig +short sel-2026b._domainkey.example.com TXT @8.8.8.8, @1.1.1.1, @9.9.9.9). Switch the signer to use the new selector.
3. Days 7-37: the old selector is still published in DNS but no new mail signs with it. In-flight messages (forwarded, queued, archived) may still reference the old selector during verification.
4. Day 37: publish empty-p= at the old selector. Any straggler verifications now fail with dkim=permerror (the canonical "permanently revoked" signal).
5. Day 67: delete the empty-p= record entirely.

Emergency rotation (key compromise detected) skips the 7-day overlap: publish empty-p= at the affected selector IMMEDIATELY (within minutes of detection), stand up a new selector with a fresh keypair, switch the signer. The 30-day retention timeline remains.

Cross-reference: help_dkim_key_rotation.php documents the rotation playbook with timing diagrams.

5. Canonicalization: c=relaxed/relaxed default

Rule 5: use c=relaxed/relaxed. The format is c=<header-canon>/<body-canon>; both halves should be relaxed.

The four canonicalization combinations and their operational survival rates:

• c=simple/simple — intolerant of any modification. Any whitespace change anywhere in the body produces body-hash mismatch. Survival rate through real-world mail-flow: low. AVOID.
• c=simple/relaxed — rare; the header is more sensitive than the body, opposite of normal threat modeling. AVOID.
• c=relaxed/simple — also rare; the body is intolerant which is the wrong way around. AVOID.
• c=relaxed/relaxed — the modern default. Tolerates trailing whitespace, blank-line collapse, line- ending normalization. USE THIS.

The relaxed body canonicalization tolerates intermediary body modifications that are inherent in real mail flow: forwarders adding trailing spaces, mailing lists adding List-Unsubscribe footers, content-scanning gateways normalizing encoding. ARC sealing (RFC 8617) is the structural fix for cases where even relaxed canonicalization is not enough.

Cross-reference: help_dkim_canonicalization.php documents the byte-level canonicalization algorithms with worked examples.

6. Header list: sign what matters, oversign what attackers spoof

Rule 6: the h= tag in the DKIM-Signature header declares which message headers are covered by the signature. The minimum operator-discipline list:

h=From:Subject:Date:To:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Sender;

The From mandate: RFC 6376 §5.4 mandates that From: be signed. A DKIM signature without From in h= is non-compliant; modern receivers reject the signature as dkim=permerror.

The oversigning trick: append a second copy of From, Subject, and Date at the end of h=:

h=From:Subject:Date:To:Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding:Sender:From:Subject:Date;

The duplicate-name trick tells the verifier "if a SECOND From header appears in the message, include it in the signature calculation". This neutralizes the attack where a forwarder adds a forged second From: above the signed one — a naive verifier reads the first From: (the forged one) but the signature only protects the second From: (the original). With oversigning, the verifier MUST find the signed From: at EVERY position and the attack collapses.

Cross-reference: help_dkim_signatures_explained.php documents the h= tag and the oversigning technique in the byte-by-byte tag anatomy.

7. AUID (i= tag): leave empty by default

Rule 7: leave the i= tag empty in the DKIM-Signature header — receivers will default it to @<d-value> per RFC 6376 §3.5.

The AUID (Agent or User Identifier) is intended for fine-grained signing-authority delegation — e.g., a shared signer that signs different sub-brands with different AUIDs. In practice the feature is rarely used because:

• Selector-level isolation (a separate selector per sub-brand) is structurally cleaner — each sub-brand publishes its own key, owns its own rotation, and the receiver sees the attribution naturally via s= and d=.
• AUID-level isolation requires the publisher to publish a t=s flag in the key record and to maintain a per-AUID allowlist — more moving parts, more drift risk.
• DMARC alignment is computed on d=, not on i=, so AUID isolation does not affect alignment.

When to use i= explicitly: only when you have a documented per-AUID delegation requirement that cannot be satisfied by selector-level isolation. In every other case, omit i= entirely.

8. NEVER use the l= body-length tag

Rule 8: do not deploy l=.

The l= tag declares that only the first N body bytes are covered by the signature; everything after byte N is unsigned. A replay attacker can:

1. Capture a legitimate signed message from your domain.
2. Append arbitrary content (phishing CTAs, malware links, drive-by JavaScript) to the body AFTER byte N.
3. Replay the modified message — the signature still verifies because the appended content is outside the signed range.

RFC 6376 §3.5 itself cautions against l=: "Use of the 'l=' tag might allow display of fraudulent content without appropriate warning to end users". Modern signing libraries do not emit l= by default. If you find l= in your DKIM-Signature output, audit the signer configuration and remove it immediately.

Cross-reference: help_dkim_replay_attacks.php documents the full l= threat model with concrete attack scenarios.

9. The t=y testing flag: 24-72h burn-in, then REMOVE

Rule 9: use t=y in the KEY RECORD for the first 24 to 72 hours after deploying a new selector, then REMOVE the flag.

The t=y flag tells verifiers "this selector is in deployment-test mode" — verifiers compute the verdict and surface it in Authentication-Results headers (so you can inspect it) but do NOT feed the verdict into DMARC alignment or spam-filter input. This is intentional during burn-in: you can debug the cryptography without affecting deliverability.

The problem: t=y left in production SILENTLY DISABLES DKIM-based DMARC alignment forever. Every receiver downgrades the resulting dkim=pass to "pass but ignore"; the cryptography is valid but DMARC does not credit it. This is one of the top three causes of "DKIM is configured but DMARC still fails" tickets.

Operator discipline:

• Set a calendar reminder for 72 hours after every new selector deployment specifically to remove t=y.
• Run a quarterly cluster audit (Rule 15) that verifies no production selector carries t=y.
• The Domain Security Checker tool flags production selectors with stale t=y.

Cross-reference: help_dkim_dns_syntax.php documents the t= flag in the key-record syntax deep dive.

10. Multi-signature: single default, multiple for documented use cases

Rule 10: sign with ONE DKIM-Signature header by default. Add additional signatures only for two documented use cases:

• Algorithm migration: during the multi-year k=rsa to k=ed25519 transition, dual-publish both keys at separate selectors and let the signer add BOTH signatures so receivers that have not implemented RFC 8463 fall back to the RSA signature.
• Sub-brand isolation: when a shared signer handles multiple sub-brands with different selectors — but this is usually better handled via per-tenant signing-configuration rather than multi-signature on a single message.

For DMARC alignment, RFC 7489 §3.1.1 states "any aligns wins" — if ANY of the dkim=pass results has a d= aligned with the From: header, DMARC alignment is satisfied. So multi-signature can improve DMARC robustness against single-signature failures.

Anti-pattern: spraying signatures "just in case". Every additional signature adds: DNS publication overhead (one selector per signature), monitoring overhead (one verdict per signature to track), and rotation overhead (each selector rotates independently). Default to ONE signature; add more deliberately.

Cross-reference: help_dkim_troubleshooting.php section on multi-signature scenarios documents the verifier behaviour in detail.

11. Monitoring: three surfaces

Rule 11: monitor DKIM via three complementary surfaces.

Surface 1: DMARC aggregate reports. Every receiver that ingests mail from your domain emits a daily aggregate report to the rua=mailto: address you publish in your DMARC record. The <auth_results><dkim> blocks contain the verdict for every received message. Use DMARC Analyzer to ingest these reports and surface the per-selector pass/fail profile in the dashboard.

What to alert on:

• Sudden drop in dkim=pass rate (any selector falling below its 30-day baseline by >5 percentage points).
• Rise in dkim=fail (forwarder/mailing-list body modification — investigate ARC sealing or per-receiver policy).
• Rise in dkim=permerror (DNS publication broken — investigate immediately).
• Rise in dkim=temperror (authoritative nameserver overloaded — investigate DNS provider).

Surface 2: Authentication-Results header spot-check. Send a test message from your domain to yourself; paste the raw headers into the Email Header Analyzer. The receiver-side verdict string (dkim=pass header.d=example.com) is the ground truth — aggregate reports lag by 24 hours, headers are immediate.

Surface 3: DNS monitoring. Alert on TXT-record changes at <selector>._domainkey.<domain> — any change is either authorized (rotation) or unauthorized (compromise) and warrants investigation within the same business day.

Cross-reference: help_dkim_failures_explained.php is the verdict catalogue documenting each Authentication-Results dkim= verdict in detail.

12. DNS publication discipline

Rule 12: publish DKIM TXT records with attention to four DNS-level details.

• Use multi-string chunking for 2048-bit RSA keys — the base64-encoded key is ~392 characters and exceeds the 255-octet character-string limit (RFC 1035 §3.3.14). Split into adjacent quoted strings; the resolver concatenates at lookup time. See help_dkim_dns_syntax.php for the chunking syntax.
• Strip the PEM banner — the p= value contains the raw base64 only, not the -----BEGIN PUBLIC KEY----- / -----END PUBLIC KEY----- wrapper. Including the banner produces dkim=permerror.
• No embedded whitespace — the p= value is a single continuous base64 string. Some legacy parsers reject embedded line breaks or spaces.
• Verify from multiple resolvers immediately after publishing — dig +short selector._domainkey.example.com TXT from @8.8.8.8, @1.1.1.1, @9.9.9.9 should all return identical output. Discrepancies between resolvers indicate propagation delay or authoritative-server inconsistency.

TTL: 3600 seconds (1 hour) is the conventional default — short enough for rotation but long enough to absorb traffic spikes without re-querying. Lower TTLs (300 seconds) are acceptable during planned rotation windows.

Cross-reference: help_dkim_dns_syntax.php documents the full TXT-record syntax including the 255-octet chunking rule and the empty-p= revocation convention.

13. Emergency revocation: empty-p= within minutes

Rule 13: when a signing key is compromised (private key leaked, signer infrastructure breached, supply-chain attack detected), publish an empty p= at the affected selector WITHIN MINUTES of detection.

The empty-p= form:

; Compromise detected — publish immediately:
selector1._domainkey.example.com   IN  TXT  "v=DKIM1; k=rsa; p="

Receivers MUST treat any signature referencing this selector as dkim=permerror per RFC 6376 §3.6.1. The structurally critical detail: DO NOT DELETE THE RECORD. Deletion produces NXDOMAIN at resolvers, which some verifiers interpret as transient (DNS outage) and retry with dkim=temperror. The explicit empty-p= form tells every receiver "this key is permanently revoked, do not accept any signature using it".

Post-revocation playbook:

1. Publish empty-p= (within minutes).
2. Stand up a new selector with a fresh keypair, switch signer to use it.
3. Document the incident: detection time, scope of suspected forgery, customer notifications.
4. Keep the empty-p= record for at least 30 days for in-flight messages.
5. Audit other selectors for the same compromise vector.

Cross-reference: help_dkim_key_rotation.php documents the emergency-revocation playbook alongside the routine-rotation cadence.

14. Documentation and change management

Rule 14: maintain a per-selector change log with four fields per entry.

• Selector name — e.g., sel-2026a.
• Deployment date — when the selector was first published in DNS.
• Rotation history — every switch-in and switch-out date for this selector.
• Owner — the team or on-call responsible for this selector.

The minimum-viable change log is a plain Markdown file in your infrastructure-as-code repository:

# DKIM selector change log — example.com

| Selector       | Deployed    | Switched in  | Switched out | Revoked      | Owner       |
|----------------|-------------|--------------|--------------|--------------|-------------|
| sel-2024a      | 2024-01-08  | 2024-01-15   | 2025-01-15   | 2025-02-14   | infra       |
| sel-2024b      | 2024-06-08  | 2024-06-15   | --           | --           | infra (M365) |
| sel-2025a      | 2025-01-08  | 2025-01-15   | 2026-01-15   | 2026-02-14   | infra       |
| sel-2026a      | 2026-01-08  | 2026-01-15   | --           | --           | infra       |
| sel-2026b-ed25519 | 2026-05-22 | 2026-05-29 | --           | --           | infra (ed25519 dual-publish) |

The log provides three operational guarantees: (1) auditability — every selector that has ever existed is documented with its provenance, (2) rotation evidence — a quarterly compliance review can verify the annual rotation cadence is being honored, (3) incident-response context — when a selector is implicated in a forgery investigation, the log immediately surfaces the responsible team and the deployment-period blast radius.

15. Quarterly cluster audit checklist

Rule 15: run a quarterly cluster audit — verify every rule above against every production selector.

The audit script (manual or automated):

1. Enumerate every production selector by inspecting the DKIM change log AND by surveying DMARC aggregate reports for selectors actually observed in the wild (the log may be incomplete; the reports are ground truth).
2. Verify key size — every RSA selector returns a 2048-bit key. Flag any 1024-bit residual.
3. Verify k= — is the key type documented? Is ed25519 dual-publish in progress where applicable?
4. Verify no stale t=y — no production selector should carry the testing flag.
5. Verify no l= in emitted signatures — capture a recent outbound message and inspect the DKIM-Signature header.
6. Verify oversigned From, Subject, Date — same captured signature.
7. Verify TXT chunking — 2048-bit keys should render as multi-string in the zone file; if represented as a single string, check whether the DNS provider auto-chunks correctly.
8. Verify multi-resolver resolution — every selector resolves identically from Google, Cloudflare, and Quad9.
9. Verify DMARC aggregate verdict distribution — every selector has a healthy pass rate; flag anomalies.
10. Verify rotation cadence — no selector older than 12 months still actively signing.

Document audit findings, file follow-up issues for any rule violations, and re-run the audit quarterly.

FAQ

What is the single most important DKIM best practice?

Use 2048-bit RSA as the floor for every DKIM signing key, per RFC 8301 §3. 1024-bit RSA is computationally broken at the resources available to a determined adversary (forgery in days on a commodity GPU cluster), and modern receivers — Gmail, Microsoft 365, Yahoo, AOL, ProtonMail — downgrade verdicts on 1024-bit keys to dkim=policy or treat the signature as dkim=fail outright. Any DKIM deployment still using 1024-bit RSA in 2026 has effectively no anti-forgery protection regardless of how correctly the rest of the configuration is wired. The 2048-bit minimum is the single rule that, if violated, makes every other best practice irrelevant. If you have ANY production selector still publishing a 1024-bit key, rotate it to 2048-bit during the next planned change window using the dual-selector overlap discipline documented in help_dkim_key_rotation.php.

How often should I rotate my DKIM signing keys?

Once per year is the modern operator-discipline standard. The threat models change over time: cryptographic primitive degradation (the 2024-2026 wave of CRQC-prep advisories), accidental private-key exposure (developer laptop compromise, CI/CD secret leak, supply-chain breach in a build pipeline), and operational hygiene (a yearly rotation cadence forces the deployment to keep working, exercising every part of the rotation pipeline at least once per year so it never atrophies). Use the dual-selector overlap discipline: stand up the new selector, publish it in DNS, wait 7 days for cache propagation, switch the signer to the new selector, wait 30 days for in-flight messages to drain, then revoke the old selector with empty-p= for another 30 days before removing entirely. Total rotation lifecycle is 67 days end-to-end. The full sequence is in help_dkim_key_rotation.php. Emergency rotation (key compromise detected) skips the 7-day overlap and publishes empty-p= immediately at the affected selector.

Should I sign messages with multiple DKIM-Signature headers?

In most cases, no — a single well-configured DKIM signature is enough and adds the least operational complexity. Multiple signatures make sense in two narrow scenarios: (a) a sub-brand structure where different mailboxes legitimately use different signing keys (e.g., support@example.com signed by one tenant, newsletter@example.com signed by another) — but this is better handled with selector isolation under a single d= value than with multi-signature; (b) algorithm transition during the multi-year k=rsa to k=ed25519 migration — dual-publish both keys at separate selectors and let the signer add both, so receivers that have not implemented RFC 8463 fall back to the RSA signature. For DMARC alignment, RFC 7489 §3.1.1 says "any aligns wins" — if any of the dkim=pass results has an aligned d=, DMARC alignment is satisfied. So multi-signature does provide alignment robustness, but the operational complexity (DNS publication, monitoring, rotation coordination) is rarely worth it unless you are explicitly running an algorithm migration. Default to single-signature; add multi-signature deliberately for a documented use case.

What canonicalization mode should I use?

Use c=relaxed/relaxed (the c= tag in the DKIM-Signature header sets canonicalization as <header>/<body>). The relaxed/relaxed mode tolerates the kinds of body modifications that legitimate intermediaries routinely make: trailing whitespace removal, blank-line collapse, line-ending normalization. The simple/simple mode is intolerant of any modification — any whitespace change anywhere in the body produces a body-hash mismatch. In practice, modern mail traffic passes through too many intermediaries (forwarders, mailing lists, content-scanning gateways, anti-spam appliances) for simple/simple to survive — every modern operator deployment uses relaxed/relaxed and accepts that ARC sealing (RFC 8617) is the proper structural fix for the residual body-modification cases. The full canonicalization deep dive is in help_dkim_canonicalization.php. NEVER use simple/simple for new deployments; if you inherit a simple/simple configuration, migrate to relaxed/relaxed during the next routine rotation.

Which headers must my DKIM signer include in the h= list?

At minimum, h= must include From: (RFC 6376 §5.4 mandates From signing — a signature without From in h= is non-compliant and most receivers reject it). Beyond From, the standard operator-discipline list adds: Subject, Date, To, Reply-To, MIME-Version, Content-Type, Content-Transfer-Encoding, Sender. These are the headers a forger would manipulate to mount a spoofing attack; signing them ties their values to the cryptographic verdict. ADDITIONALLY: oversign From, Subject, and Date with the empty-double-list trick — h=From:Subject:Date:From:Subject:Date — which signs ANY appearance of those headers including future-added copies. The oversigning defense neutralizes the attack where a forwarder adds a SECOND From: header above the signed one; receivers that read the first From: see the unsigned forged header but the signature does not protect against the augmented set. Oversigning From/Subject/Date is documented in help_dkim_signatures_explained.php as the "Hashed Header Field" defense.

Is the l= body-length tag safe to use?

No. The l= tag declares that only the first N body bytes are covered by the signature; everything after byte N is unsigned and a replay attacker can append arbitrary content (phishing CTAs, malware links, drive-by JavaScript) to your signed message and the signature still verifies. RFC 6376 §3.5 itself cautions against l= use; the cryptographic community classifies it as a known replay-attack vector. The l= tag exists in the RFC because the original DKIM design contemplated signing very large bodies with a limit, but the security cost has always outweighed the operational benefit. Modern signing libraries do not emit l= by default; if you find l= in your DKIM-Signature output, audit the signer configuration and remove it. The full l= threat model is documented in help_dkim_replay_attacks.php with concrete attack scenarios. NEVER deploy l= in production.

When should I use the t=y testing flag and when must I remove it?

Use t=y for the first 24 to 72 hours after deploying a NEW selector. The flag signals to verifiers that the key is in deployment-test mode — verifiers SHOULD compute the verdict (so it appears in Authentication-Results headers for your inspection) but SHOULD NOT feed it into DMARC alignment, spam filters, or reputation scoring. This lets you debug the cryptography (selectors resolving, signatures verifying) without affecting deliverability. Once aggregate reports confirm a healthy verdict pattern (dkim=pass on every receiver, no dkim=permerror, no dkim=fail spikes), REMOVE t=y. Leaving t=y in production is one of the top three causes of "DKIM is configured but DMARC still fails" tickets — every receiver downgrades the resulting dkim=pass to "pass but ignore", which silently disables DKIM-based DMARC alignment even though the cryptography is perfect. The discipline: set a calendar reminder for 72 hours after every new selector deployment specifically to remove t=y.

How should I monitor my DKIM deployment for regressions?

Combine three monitoring surfaces. (1) DMARC aggregate reports: the rua=mailto: address receives daily XML reports from every receiver that ingested mail from your domain — the <auth_results><dkim> blocks contain the verdict for every received message. Use DMARC Analyzer to ingest these reports and surface the per-selector pass/fail profile in the dashboard. A sudden drop in dkim=pass rate or rise in dkim=fail / dkim=temperror is a regression signal. (2) Spot-check Authentication-Results headers on outbound mail you receive from your domain (send a test to yourself, paste into the Email Header Analyzer) — the receiver-side verdict string is the ground truth and surfaces issues that aggregate reports miss (e.g., temperror caused by your authoritative DNS being slow). (3) DNS monitoring: alert on TXT-record changes at <selector>._domainkey.<domain> — any change to the published key is either authorized (rotation) or unauthorized (compromise) and warrants investigation. The dashboard cross-reference is documented in help_dkim_troubleshooting.php.

Should I sign with k=rsa or k=ed25519?

In 2026, sign with BOTH on separate selectors and let the signer choose which one to use per message. ed25519 (RFC 8463) has structural advantages — 32-byte public keys, 64-byte signatures, faster verification, no key-size choice to get wrong — but is less universally supported. A receiver that has not implemented RFC 8463 (less common in 2026 but still present in older spam appliances and small ISPs) produces dkim=neutral or dkim=permerror on ed25519 signatures. RSA with 2048-bit keys (RFC 8301 §3) is universally supported but operationally heavier (larger TXT records requiring 255-octet chunking, slower verification, looming concerns about CRQC quantum-resistance in the late 2020s). The dual-publish posture: selector1._domainkey publishes the RSA key (k=rsa, p=<2048-bit-base64>), selector2._domainkey publishes the ed25519 key (k=ed25519, p=<32-byte-base64>). The signer adds both signatures or alternates per message; the verifier picks whichever it understands. Over time, as receiver coverage of ed25519 reaches parity, the RSA selector can be deprecated. The cryptographic background is in help_dkim_cryptography_basics.php.

What is the proper way to revoke a compromised DKIM signing key?

Publish an empty p= at the affected selector immediately, then rotate the signer to a new selector with a fresh keypair. RFC 6376 §3.6.1 specifies that an empty p= value is the canonical "permanently revoked" signal — receivers MUST treat any signature using this selector as dkim=permerror. The empty-p= record is structurally different from deleting the record entirely: deletion produces NXDOMAIN at resolvers, which some verifiers interpret as transient (DNS outage) and retry with dkim=temperror. The empty-p= form explicitly tells every receiver "this key is gone, do not accept any signature using it". Keep the empty-p= record for at least 30 days (one mail-archive lifetime for forwarded messages still in flight) before removing entirely. The detailed revocation playbook with timing, parallel signer rotation, and post-compromise audit checklist is in help_dkim_key_rotation.php. Never wait, never debate — when a key is compromised, the empty-p= publish happens within minutes of detection.

Related guides — the 12 sibling DKIM-cluster pages this synthesis draws from

• DKIM protocol pillar — the whole-protocol survey.
• DKIM DNS record syntax — the key-record byte-level encoding reference.
• DKIM-Signature header tag anatomy — the per-message header byte-level reference.
• DKIM canonicalization — c= tag deep dive (Rule 5).
• DKIM selectors — selector vocabulary deep dive (Rule 3).
• DKIM cryptography basics — RSA vs ed25519 algorithm choice (Rule 2).
• DKIM key rotation — rotation discipline (Rule 4) and emergency revocation (Rule 13).
• DKIM replay attacks — l= tag threat model (Rule 8).
• DKIM failures explained — verdict catalogue (Rule 11 monitoring).
• DKIM alignment with DMARC — RFC 7489 §3.1.1 alignment engine.
• ARC (Authenticated Received Chain) explained — the PER-HOP-CRYPTOGRAPHIC-CHAIN-OF- CUSTODY-PRESERVING-DKIM-VERDICT-ACROSS- FORWARDER-BODY-REWRITES companion to this DKIM-best-practices 13-rule operator- discipline reference. Where THIS page synthesises the 13-rule DKIM operator discipline (Rules 1-13 covering RSA-2048 minimum key length, SHA-256 hash baseline, per-selector naming hygiene, c=relaxed/ relaxed canonicalization mode, oversigning of stable headers, annual key rotation with overlap window, l= tag avoidance, per-stream selector isolation, verdict- monitoring via aggregate reports, emergency revocation playbook), the ARC spoke documents the RFC 8617 three-header sealing protocol (ARC-Authentication- Results / ARC-Message-Signature / ARC-Seal) whose per-forwarder per-hop attestation chain is the cryptographic-chain-of-custody mechanism preserving the per-message DKIM verdict across the forwarder-body-rewrite boundary at FOUR per-DKIM-best-practice-vs- ARC-chain-of-custody coupling dimensions: (i) Rule 5 c=relaxed/relaxed canonicalization vs forwarder body-rewrite attestation-via-ARC-chain — Rule 5 recommends c=relaxed/relaxed canonicalization to maximise per-message DKIM-signature survival across forwarder whitespace/end-of- line normalisation; ARC complements this when the forwarder modification exceeds c=relaxed tolerance (mailing-list footer injection, body-content rewriting) by emitting an ARC-Message-Signature attesting the per-hop authentication state at the forwarder ingress boundary, so the downstream receiver can honour the original-hop DKIM verdict even after c=relaxed canonicalization verification fails; (ii) Rule 11 verdict-monitoring discipline vs per- receiver ARC-chain honour-policy — Rule 11 mandates per-source-IP dkim=pass- rate monitoring via aggregate-report ingestion; per-receiver ARC-chain honour policies (Gmail honours valid ARC chains from trusted ARC-signers; Microsoft EOP honours conditionally per ARC trust configuration) determine whether the per-receiver per-message DMARC=fail-but- ARC-valid disposition rolls up as a dkim=fail row in the publisher's monitoring stream OR is silently suppressed by ARC- chain trust elevation — the ARC spoke documents this per-receiver policy variance the Rule 11 monitoring discipline interprets; (iii) Rule 7 oversigning stable headers vs ARC-Message-Signature header- coverage discipline — Rule 7 recommends oversigning critical headers (From, Subject, Date, To, Cc, Message-ID, References, In-Reply-To, Reply-To) to prevent attacker downgrade of the per- message DKIM signature header-list; the ARC-Message-Signature emitted at each ARC- chain hop similarly covers a header-list whose contents and oversign-discipline determine whether the per-forwarder attestation survives downstream header injection at intermediate hops — the ARC spoke documents the ARC-AMS header-list authoring discipline that mirrors Rule 7's DKIM-Signature-side discipline; (iv) Rule 13 emergency revocation playbook vs ARC-chain trust withdrawal cascade — Rule 13 documents the emergency-key-revocation playbook for a compromised DKIM selector key; ARC-chain signers whose ARC-Seal private key is similarly compromised follow a parallel revocation discipline whose downstream receiver-side ARC-chain trust withdrawal cascade rolls back per-message verdicts attributed to the compromised ARC-signer — the ARC spoke documents the per-ARC- signer revocation discipline parallel to Rule 13's per-DKIM-selector revocation discipline. Read the ARC spoke when designing the per-publisher DKIM-best- practices discipline THIS page synthesises across forwarder-survival paths whose per-hop attestation chain compensates for the per-message DKIM-signature invalidation Rule 5's c=relaxed/relaxed canonicalization cannot fully prevent.
• SPF forwarding issues — the SPF-SECOND-HOP-FORWARDER-BREAKAGE- ROOT-CAUSE-PRIMER companion to this DKIM- best-practices 13-rule operator-discipline reference. Where THIS page synthesises the 13-rule DKIM operator discipline that maximises per-message DKIM-Signature forward-survivability across the per- forwarder per-hop body-rewrite boundary (Rule 5 c=relaxed/relaxed canonicalization + Rule 7 oversigning stable headers + Rule 8 l=-tag avoidance), the SPF-forwarding-issues spoke is the FOUNDATIONAL root-cause primer documenting why the SPF envelope-MAIL-FROM- layer authentication-leg STRUCTURALLY FAILS at the second-hop forwarder boundary — the per-forwarder per-hop envelope-rewrite class of failure modes (mailing-list-manager rewrites RFC5321.MailFrom to the list address; .forward / Sieve / Office-365- routed-rule forwards substitute the forwarding-mailbox identity for the original sender; corporate-gateway forwards rewrite the envelope-domain to the gateway-domain) whose downstream-receiver-side per-message SPF verdict collapses to spf=fail / spf=softfail per RFC 7208 §2.6 + RFC 5321 §3.9 forwarder rewrite norms at FOUR per-DKIM-best-practice-vs-SPF-forward- breakage coupling dimensions: (i) SPF-leg structurally fails at forwarder boundary while DKIM-leg structurally survives — Rule 5 c=relaxed/ relaxed-canonicalization as the operator- side instrumentation — SPF authentication per RFC 7208 §5 binds the per-message verdict to the connecting-MTA- IP + RFC5321.MailFrom envelope-domain, both of which are rewritten at every forwarder hop; DKIM cryptographic signatures per RFC 6376 §3 are bound to the MESSAGE content (header + body) and SURVIVE forwarder rewrites THAT DON'T MODIFY SIGNED HEADERS OR BODY; THIS page's Rule 5 c=relaxed/ relaxed-canonicalization choice is the operator-side instrumentation that maximises the per-message DKIM-Signature's survival across the forwarder whitespace/ end-of-line normalisation rewrites that the SPF-forwarding-issues spoke documents as the SPF-leg's structural-failure boundary; (ii) SRS (Sender Rewriting Scheme) per-hop envelope-MAIL- FROM-rewrite remediation vs Rule 11 per- receiver dkim=pass-rate monitoring discipline — SRS per the SPF-forwarding-issues spoke is the canonical per-forwarder per-hop envelope-MAIL-FROM- rewrite remediation that re-establishes the SPF-leg verdict at the post-forwarder receiver-side BUT only at the forwarder- domain (not the original-sender domain); DMARC alignment per RFC 7489 §3.1.1 REQUIRES the SPF authenticated envelope- domain to align with the RFC5322.From- domain, which SRS rewriting STRUCTURALLY BREAKS — so even SRS-rewritten forwarded mail relies on the DKIM-aligned-pass-leg for DMARC composite-verdict alignment, making Rule 11 per-receiver dkim=pass-rate monitoring the load-bearing observability discipline for SRS-rewritten-forwarder deliverability triage; (iii) per- forwarder per-hop SPF-leg-failure as Rule 10 per-stream selector-isolation triage signal — Rule 10 recommends per- stream selector isolation so per-forwarder per-hop per-message verdict-drift can be attributed to a single per-publisher per- stream selector; the SPF-forwarding-issues spoke documents the per-receiver per-day DMARC RUA policy_evaluated/ spf=fail + per-source-IP forwarder- cohort attribution stream THIS page's Rule 11 monitoring discipline consumes to distinguish per-publisher per-stream forwarder-induced SPF-leg-failure from per-publisher per-stream attacker spoof — without the forwarder-cohort attribution the per-stream selector-isolation cannot differentiate legitimate-forwarder vs spoof root-cause; (iv) per- forwarder per-hop ARC-chain-of-custody as Rule 5 + Rule 7 + Rule 8 composite- forwarder-survival discipline upstream dependency — the SPF-forwarding- issues spoke documents the per-forwarder per-hop ARC-chain cryptographic-attestation protocol (per the adjacent ARC-explained spoke above this entry) as the per-message cross-hop DKIM-verdict-preservation mechanism whose downstream-receiver-side honour-policy materially depends on the per-publisher per-message DKIM-Signature body-hash + header-list discipline THIS page's Rules 5/7/8 produce; ARC-chain honour at Gmail + Microsoft EOP requires the per-forwarder per-hop ARC-Message- Signature to attest a VALID per-message DKIM verdict at the original-hop boundary, which is ONLY possible when the per- publisher per-message DKIM-Signature was produced under Rules 5/7/8 (c=relaxed/ relaxed + oversigning + no l=). Read the SPF-forwarding-issues spoke when designing the per-publisher DKIM-best-practices 13-rule discipline THIS page synthesises across forwarder-survival paths where the SPF-leg's structural-failure at the second- hop boundary forces the DKIM-aligned-pass- rate floor to bear SOLE DMARC composite- verdict-alignment load.
• Why SPF alone is insufficient — the DKIM-AS-SECOND-LEG-CRYPTOGRAPHIC- COMPLEMENT-CLOSING-THE-SPF-IP-ONLY- AUTHENTICATION-GAPS companion to this DKIM-best-practices 13-rule operator- discipline reference. Where THIS page synthesises the 13-rule DKIM operator discipline (RSA-2048-minimum / SHA-256- hash / per-selector-naming-hygiene / c=relaxed/relaxed-canonicalization / oversigning-stable-headers / annual- rotation-overlap / etc.), the why-SPF- alone-is-insufficient spoke is the FOUNDATIONAL why-DMARC-exists reference whose 4-class SPF-insufficiency catalogue is structurally closed by the DKIM cryptographic-signature complement THIS page's 13-rule discipline produces. The DKIM-AS-SECOND-LEG-CRYPTOGRAPHIC- COMPLEMENT-CLOSING-THE-SPF-IP-ONLY- AUTHENTICATION-GAPS cross-reference establishes FOUR structurally-distinct DKIM-complements-SPF-insufficiency dimensions: (i) forwarder- rewrite-breaks-SPF-but-survives-DKIM dimension — SPF authentication per RFC 7208 §5 binds the receiver-side verdict to the connecting-MTA-IP and the RFC5321.MailFrom envelope domain; forwarders rewrite the envelope (typical mailing-list-manager / .forward / Office-365-routed-rule-forward / corporate- gateway-forward behaviours per RFC 5322 §3.6.2 deprecated SMTP rewrite norms), which collapses the SPF authentication verdict at the receiver-side; DKIM cryptographic signatures per RFC 6376 §3 are bound to the MESSAGE content (header + body) — they SURVIVE forwarders that don't modify the signed headers or body; the 13-rule discipline THIS page synthesises (c=relaxed/relaxed + oversigning + stable-header-list) is the operator-side instrumentation that maximises forward-survivability of the DKIM verdict, structurally closing the forwarder-induced SPF-insufficiency gap; (ii) IP-only-authentication- misses-header-spoofing dimension — SPF authentication produces a verdict against the RFC5321.MailFrom envelope domain but NEVER against the RFC5322.From header-displayed domain; attackers can publish a permissive SPF policy for their own envelope-domain ( v=spf1 +all) and forge a VICTIM-domain in the RFC5322.From header that mail clients display to end users — SPF passes for the attacker's envelope but the displayed identity is the victim; DKIM cryptographic signature per RFC 6376 §3.5 binds the d=-domain to the cryptographically-verified message, and DMARC alignment per RFC 7489 §3.1.1 requires the DKIM d=-domain to align with the RFC5322.From-domain for the DMARC verdict to pass — structurally closing the IP-only- authentication-misses-header-spoofing gap that SPF alone cannot address; THIS page's 13-rule discipline (cryptographic- key-strength + per-selector-naming- hygiene + alignment-friendly d-domain- choice) is the operator-side instrumentation that produces the DMARC-aligned DKIM signatures the anti-spoofing primitive depends on; (iii) SPF-lookup-limit-causes-permerror- but-DKIM-has-no-lookup-budget dimension — SPF RFC 7208 §4.6.4 imposes a 10-DNS-lookup budget across the entire include: / a: / mx: / exists: / redirect= / ptr: mechanism cascade; multi-tenant publishers (SaaS senders + marketing-ESP + transactional-ESP + invoicing-platform + analytics-pixel- sender) routinely exceed this budget, producing receiver-side spf=permerror verdicts that collapse the SPF authentication contract; DKIM has NO equivalent lookup-limit (one DNS-TXT lookup per <selector>._domainkey.<d- domain> per signature), structurally avoiding the lookup-budget exhaustion failure-mode that affects SPF in multi-tenant publishing contexts; THIS page's 13-rule discipline (per- provider-selector-hygiene + provider- managed-key-coordination) is the operator-side instrumentation that produces robust DKIM signatures in the SAME multi-tenant publishing contexts where SPF lookup-budget exceeds the RFC 7208 §4.6.4 limit; (iv) SPF- lacks-alignment-to-RFC5322-From-but-DKIM- has-d-domain-alignment dimension — SPF authentication produces a verdict for the RFC5321.MailFrom envelope domain; DMARC alignment per RFC 7489 §3.1.2 requires the RFC5321.MailFrom domain to align (relaxed or strict) with the RFC5322.From header-domain for the SPF leg of DMARC to pass; this alignment is a SECONDARY layer the operator must configure on top of SPF — SPF alone does NOT enforce this alignment; DKIM cryptographic-signature d=-domain is selected by the signing-operator (per the 13-rule discipline THIS page documents in the per-provider-d-domain-choice rule); DMARC alignment per RFC 7489 §3.1.1 requires the DKIM d=-domain to align with the RFC5322.From-domain for the DKIM leg of DMARC to pass — the operator has DIRECT control over the d=-domain choice via the DKIM signer configuration (whereas SPF envelope-domain control is constrained by the SMTP-handshake topology of the outbound mail path); THIS page's 13- rule discipline (alignment-friendly d- domain-choice + provider-managed-key- coordination) is the operator-side instrumentation that produces DKIM signatures that structurally align with the RFC5322.From-domain, closing the SPF-lacks-alignment gap. Pair this page (the DKIM-best-practices 13-rule operator-discipline reference) with the why-SPF-alone-is-insufficient spoke (the foundational why-DMARC-exists reference) when an operator authors the cross- protocol authentication-stack rollout plan and needs to apply the same DKIM- as-second-leg-cryptographic-complement discipline as the structural closing layer for the 4-class SPF-insufficiency catalogue that motivates the DMARC authentication-stack adoption.
• DKIM troubleshooting — cross-symptom decision tree.
• DMARC troubleshooting — the DKIM-BEST-PRACTICES-AS-LOAD- BEARING-PRECONDITION-FOR-DMARC- DIAGNOSTIC companion to this DKIM- best-practices 13-rule synthesis. Where THIS page documents the canonical operator-discipline floor (RSA-2048 key strength + dual-selector rotation + 90-180-day cadence + relaxed canonicalization + h= mandatory header list + sole-d=-tag publication discipline + per-mail-stream selector partitioning + post-incident-response selector retirement + per-selector TXT-record-size 255-octet chunking discipline + per-signature timestamp-tag t= publication + per-stream-failure- alerting + per-publisher per-domain DKIM-aligned-pass-rate baseline confirmation + per-incident bh=-body-hash-rollback hot-fix), the DMARC-troubleshooting spoke documents the receiver-side composite-verdict diagnostic catalogue whose DKIM-aligned-pass leg consumes the per-message dkim=<verdict> production-quality output the 13 rules collectively produce at four DKIM-deployment-discipline-to-DMARC- diagnostic-class coupling dimensions: (i) Rule 1-3 (key strength + selector + rotation) as upstream of dkim=temperror + dkim=permerror diagnostic class — DNS- publication discipline failures produce per-message verdicts the DMARC-troubleshooting spoke documents; (ii) Rule 4-6 (canonicalization + header list + d=-tag) as upstream of dkim=pass + DMARC-fail (alignment MISS) — signing-identity-publication discipline failures produce DKIM-aligned-pass MISS clusters; (iii) Rule 7-9 (per-stream partitioning + retirement + TXT chunking) as upstream of per-stream-attributable dkim=fail clusters — per- mail-stream signer-discipline failures produce per-source-IP attributable dkim=fail clusters; (iv) Rule 10-13 (timestamp + alerting + baseline confirmation + hot-fix) as upstream of incident- response-loop closure — per-publisher per-domain DKIM-aligned-pass-rate monitoring baseline failure-detection discipline produces the DMARC- diagnostic-workflow ingest signal the spoke's per-incident symptom→cause→fix ladder consumes. Read the DMARC- troubleshooting spoke alongside this DKIM-best-practices reference when sequencing the DKIM-side remediation that unblocks publisher p=quarantine → p=reject cutover, when prioritising the 13-rule deployment-discipline floor against per-receiver per-publisher diagnostic-class failure-row clusters, or when composing per-incident response runbooks bridging the canonical operator deployment discipline THIS page synthesises and the receiver-side diagnostic catalogue the DMARC-troubleshooting spoke documents.
• DKIM for Microsoft 365 — provider deployment guide.
• DKIM for Google Workspace — provider deployment guide.
• DMARC for SaaS senders — the DKIM-BEST-PRACTICES-AS-SAAS- PLATFORM-MANAGED-DKIM-SIGNING-DELEGATION consumer companion to this DKIM-best- practices 13-rule operator-discipline synthesis. Where THIS page documents the 13 production-deployment rules (Rule 1 sign-every-message, Rule 2 RSA-2048+ or Ed25519 algorithm choice, Rule 3 dual-selector zero- downtime rotation, Rule 4 per-purpose selector isolation, Rule 5 relaxed canonicalisation default, etc.) — i.e. the OPERATOR-CONTROLLED-DKIM-DEPLOYMENT- DISCIPLINE side of DKIM production practice — the DMARC-for-SaaS-senders spoke is the SAAS-PLATFORM-MANAGED-DKIM- DELEGATION-CONSUMER companion documenting how each rule re-interprets when the customer-tenant operator DELEGATES DKIM signing to a SaaS marketing platform's managed-key infrastructure. Concretely, the spoke documents FOUR SaaS-platform- DKIM-deployment-discipline-consumption dimensions: (i) SaaS-platform- managed CNAME-delegated DKIM signing substitutes operator-controlled key custody with platform-managed key custody — the customer-tenant publishes a CNAME record at k1._domainkey.<customer-domain> pointing to the SaaS platform's key- management zone (e.g. k1.<saas-platform-domain>), and the platform generates, stores, and rotates the DKIM signing key on the customer's behalf — Rule 1 (sign-every-message) becomes a platform-managed contract the customer- tenant operator can only AUDIT (via per-message DKIM-Signature-header verification at the receiver), not DIRECTLY CONTROL; (ii) SaaS- platform key-size and algorithm choices bind the customer-tenant to the platform's baseline — Rule 2 (RSA-2048+ or Ed25519) is satisfied or NOT satisfied by the platform's per-customer-tenant key-generation defaults; Salesforce Marketing Cloud, HubSpot, and Marketo all generate RSA-2048 keys by default but some legacy platform tenants may still have RSA-1024 keys from before the 2024 receiver-side cryptographic- strength expectation tightening — the SaaS-senders spoke documents the per- platform key-size-audit and key- regeneration request workflow the customer-tenant operator must drive through platform support; (iii) SaaS-platform key-rotation cadence is platform-managed and operator-INVISIBLE — Rule 3 (dual-selector zero-downtime rotation) is implemented by the SaaS platform's own internal key-rotation infrastructure on a platform-managed cadence the customer-tenant operator cannot directly inspect — the customer-tenant operator's only signal that rotation occurred is the per-message DKIM- Signature-header s=<selector> field changing in receiver-side per-message inspection (typically through the DMARC RUA aggregate-report stream's per-row auth_results/dkim/selector field if exposed by the receiver), and operator-visibility of platform- managed rotation is therefore strictly OBSERVATIONAL rather than CONTROL-PLANE; and (iv) SaaS-platform shared- IP-pool reputation cross-contamination bypasses the DKIM-best-practices- protection envelope — even when the customer-tenant operator's per-tenant DKIM-signing identity is correctly configured per all 13 rules THIS page documents, a sibling customer-tenant on the same SaaS- platform shared-IP-pool emitting high- volume spam can drive the platform- managed SPF-include's IP-pool reputation down — depressing the receiver-side disposition tier for legitimate operator mail even when the operator's per-tenant DKIM- Signature is cryptographically valid and DMARC-aligned. The 13-rule DKIM-best-practices discipline THIS page documents protects the cryptographic-and-alignment surface of the customer-tenant's per-platform signing identity, but does NOT protect against shared-IP-pool reputation cross-contamination — a structurally-orthogonal defense surface the SaaS-senders spoke documents separately. Read the DMARC-for-SaaS-senders spoke alongside this DKIM-best-practices reference when the customer-tenant's outbound mail-flow inventory includes any SaaS marketing platform — the 13 rules THIS page synthesises still apply, but their CUSTOMER-TENANT-CONTROLLABILITY boundary shifts when DKIM signing is delegated to a SaaS platform's managed-key infrastructure.
• DMARC multi-domain strategy — the DKIM-BEST-PRACTICES-AS-PER- DOMAIN-DKIM-DEPLOYMENT-DISCIPLINE- CATALOGUE-APPLIED-UNIFORMLY-ACROSS- PORTFOLIO-DOMAINS companion to this DKIM-best-practices 13-rule operator-discipline synthesis. Where THIS page documents the 13 production-deployment rules (Rule 1 sign-every-message, Rule 2 RSA-2048+ or Ed25519 algorithm-and- keysize discipline, Rule 3 selector- naming-discipline, Rule 4 annual rotation-cadence, Rule 5 dual- selector overlap window during rotation, Rule 6 zone-walking protection, Rule 7 signed-headers- list discipline, Rule 8 body-length- tag-l= avoidance, Rule 9 t=y testing- flag burn-in, Rule 10 t=s strict- domain-binding, Rule 11 multi- signature dual-algorithm hedging, Rule 12 selector-revocation-via- empty-p= discipline, Rule 13 post-rotation aggregate-report- validation), the multi-domain strategy spoke documents how a PORTFOLIO-MANAGEMENT operator running a publisher with MULTIPLE PROTECTED DOMAINS must APPLY THE 13-RULE DISCIPLINE UNIFORMLY across the entire portfolio — the attacker's bypass-vector ceiling is determined by the WEAKEST per- domain discipline application, not the strongest. FOUR structurally- distinct PER-DOMAIN-DKIM-DISCIPLINE- CONSISTENCY dimensions emerge from cross-mapping the 13-rule catalogue against the portfolio-management workflow: (1) Portfolio-wide Rule 2 algorithm-and-keysize-floor coordination at the per-domain-DKIM- signing-infrastructure boundary — the multi-domain spoke documents how an acquired-company domain that was signing with RSA-1024 (legacy) creates a portfolio-wide attacker- bypass window via the cryptographic-key-recovery vector on the acquired domain's selector WHILE the org-domain and sister- brand-domains have RSA-2048+ posture. Multi-domain-strategy requires Rule 2 application audited per- domain at portfolio-acquisition- integration time, not just at org-domain-initial-deployment time. THIS page's Rule 2 keysize-floor guidance is the per-domain operational primitive the multi-domain spoke proves must propagate to portfolio-wide audit cadence. (2) Portfolio-wide Rule 4 rotation-cadence coordination at the per-domain-key-rotation- synchronisation-window boundary — the multi-domain spoke documents the operational hazard where per-domain DKIM rotation cadences DRIFT (org-domain rotates annually, sister-brand rotates biennially, acquired-domain rotates ad-hoc when keys leak) producing portfolio-wide windows where SOMEWHERE in the portfolio a long-lived key is operational. Multi-domain strategy requires cross-domain rotation-cadence synchronisation (single calendar for portfolio-wide rotation events) such that all portfolio domains rotate in the same operator- defined window. THIS page's Rule 4 annual-rotation-cadence guidance is the per-domain operational primitive the multi-domain spoke proves must extend to portfolio- wide rotation-calendar coordination. (3) Portfolio-wide Rule 11 multi- signature dual-algorithm-hedging coordination at the per-domain- receiver-acceptance-baseline boundary — the multi-domain spoke documents the receiver-side algorithm-acceptance baseline problem: a portfolio with mixed RSA-only and dual-RSA+Ed25519 per-domain posture creates per-domain receiver-acceptance variability. Multi-domain strategy requires Rule 11 portfolio-wide application — every domain ships dual-algorithm signatures so the receiver-side acceptance baseline is uniform across the portfolio (no per-domain receiver-acceptance divergence creating attacker-bypass windows). THIS page's Rule 11 multi-signature-hedging guidance is the per-domain operational primitive the multi-domain spoke proves must propagate to portfolio- wide dual-algorithm-publication discipline. (4) Portfolio- wide Rule 13 post-rotation aggregate-report-validation coordination at the per-domain- RUA-stream-consumer joint-portfolio- validation boundary — the multi-domain spoke documents the per-domain post-rotation validation coordination problem: a portfolio with per-domain rotation events spread across the year means per-domain post-rotation validation runs in isolation. Multi-domain strategy requires Rule 13 portfolio- wide application — the portfolio-management operator runs cross-domain RUA-stream-joint- validation in a single workflow, comparing per-domain dkim-pass-rate baselines before-vs-after rotation across the portfolio in a unified dashboard. THIS page's Rule 13 post-rotation aggregate-report- validation guidance is the per- domain operational primitive the multi-domain spoke proves must extend to portfolio-wide joint- validation infrastructure. Read the multi-domain spoke alongside THIS page when the portfolio- management operator is sizing the per-domain DKIM operational discipline against THE WEAKEST-LINK threat-model: this page tells you WHAT THE RULE IS at the per-domain boundary, the multi-domain spoke tells you HOW THE RULE COMPOSES across the portfolio AND WHY per-domain weakest-link discipline determines portfolio-wide attacker- bypass-vector ceiling.
• Reverse DNS / PTR records for mail servers — the REPUTATION-AGGREGATE-INPUT IP- identity-layer companion documenting the IN-ADDR.ARPA / IP6.ARPA reverse-zone PTR record publication discipline whose FCrDNS (Forward-Confirmed reverse DNS) verification operates as the IP-IDENTITY-LAYER below the DKIM message-identity-layer THIS best- practices synthesis documents. Where THIS page documents the 13-rule production- deployment-defaults DKIM signers should adopt (the 2048-bit RSA / Ed25519 algorithm floor, the c=relaxed/relaxed canonicalisation default, the 90-day rotation cadence, the l=-tag avoidance, the RFC 9103 x= expiration tag, the dual-selector zero- downtime rotation pattern), the reverse-DNS- PTR spoke is the IP-IDENTITY-LAYER companion documenting the parallel IP-publication discipline that EVERY receiver-side reputation aggregator (Gmail Postmaster Tools, Microsoft SNDS / JMRP, Yahoo Sender Hub) consumes ALONGSIDE the DKIM-d= identity layer this page covers. The four-axis DKIM-BEST-PRACTICES-VS-FCrDNS-DISCIPLINE comparison exposes the structurally-distinct REPUTATION-AGGREGATE-INPUT roles: (i) DKIM publishes the d= signing-domain identity, FCrDNS publishes the connecting-IP identity — receiver-side reputation aggregators score BOTH identities independently then combine; (ii) DKIM alignment uses From: org-domain ↔ d= match, FCrDNS alignment uses connecting-IP ↔ HELO-name match — both are alignment- check mechanisms but operate at different layers; (iii) DKIM-best-practices rotation cadence (90-day) interacts with FCrDNS rotation cadence (typically steady-state) — DKIM rotation does NOT trigger FCrDNS-record churn, but a new sending-IP brought online for higher-volume rotation phases WILL require new PTR records + warm-up windows; (iv) operators running PRO-grade DKIM-best-practices on DKIM-aligned-but-FCrDNS-misaligned IPs observe inbox-placement degradation that masks as DKIM-signer reputation — the operator-debugging workflow MUST evaluate BOTH layers separately. Read the reverse-DNS-PTR spoke when scoping the IP- identity-layer prerequisites that EVERY DKIM-best-practices deployment relies on but does not document directly.
• MTA-STS explained - the DKIM-APPLICATION-LAYER-CRYPTOGRAPHIC- PUBLISHER-DISCIPLINE-PARALLEL-TO-MTA-STS- TRANSPORT-LAYER-PUBLISHER-DISCIPLINE companion to this DKIM-best-practices 13-rule operator-discipline synthesis. Where THIS page documents the 13-rule application-layer cryptographic-publisher- discipline catalogue (key-algorithm selection, key-size discipline, per- selector publication discipline, key rotation cadence, private-key-custody discipline, etc.), the dedicated MTA-STS- explained pillar documents the STRUCTURALLY-PARALLEL transport-layer publisher-discipline at four cross-layer publisher-discipline-parallel dimensions whose operator-discipline framework parallels the DKIM-application-layer publisher-discipline this page synthesises: (i) both layers require publisher- side per-domain publication discipline at a structurally-analogous DNS sub- owner-name (DKIM at <selector>._domainkey.<domain> TXT-RR with v=DKIM1 + p=<public-key> per RFC 6376 §3.6.1; MTA-STS at _mta-sts.<domain> TXT-RR with v=STSv1 + id=<policy-id> per RFC 8461 §3.1) - both DNS sub-owner- names require the publisher's per-domain publication discipline at the apex zone and inherit the same DNS-publication- cascade prerequisites including DNSSEC- signing if the operator chooses DNSSEC-anchored publication; the MTA-STS-explained pillar documents the per-sub-owner-name TXT-RR publication discipline that parallels DKIM's per- selector publication discipline this page operationalises on; (ii) both layers require publisher-side cryptographic-material renewal discipline with rotation-cadence operator-decision framework - DKIM requires per-selector key rotation (operator-decision typical every 90-180 days per the 13-rule discipline this page documents) with overlapping-publication-window discipline during rotation to avoid per-receiver cache-stale-key transient failures; MTA-STS requires the policy-host HTTPS leaf cert renewal (Let's Encrypt 90-day cadence typical) with the operator responsible for renewal-cycle automation to avoid post-renewal cert-validation failures at sending MTAs - BOTH layers' renewal cycles are structurally equivalent publisher-side operational burden that the operator MUST automate for steady-state correctness; the MTA-STS-explained pillar documents the policy-host HTTPS cert renewal discipline that parallels DKIM's per-selector key rotation discipline this page's 13-rule catalogue prescribes; (iii) both layers encode a publisher-side ENFORCEMENT-STRICTNESS commitment via publisher-tunable operator-discipline dials - DKIM's t=y test- flag-vs-non-test-flag plus the publisher's choice of whether to sign ALL mail-streams with selector-key- rotation discipline is the publisher's graded commitment; MTA-STS's mode: enforce vs mode: testing vs mode: none is the publisher's tiered commitment - both layers' commitment-tier ramps are operator-rollout-staged with publisher-observed evidence-stream feedback driving the ramp-exit decisions; the MTA-STS-explained pillar documents the mode-tier publisher-ramp discipline that parallels DKIM's test-flag-and-rotation-discipline operator-decision framework this page synthesises; and (iv) both layers produce a receiver-side observability evidence stream surfaced through publisher-side reporting infrastructure - DKIM verification outcomes surface in DMARC RUA aggregate reports as auth_results/dkim/result per-source-IP verdicts; MTA-STS TLS validation outcomes surface in TLS-RPT JSON aggregate reports at _smtp._tls.<domain> rua=mailbox as per-receiver per-day validation-failure-rate evidence - both reporting layers produce per-publisher per-receiver verdict-distribution evidence the publisher consumes for operator-discipline-rollout decisions and steady-state monitoring; the MTA-STS-explained pillar documents the TLS-RPT-as-publisher-side-observability reporting layer that parallels the RUA-as-publisher-side-observability DKIM-result reporting layer this page's 13-rule discipline operationalises on for steady-state correctness verification.
• TLS-RPT record syntax — the DKIM-OPERATOR-DISCIPLINE-PARALLEL- TO-TLS-RPT-PUBLICATION-DISCIPLINE-AT- TRANSPORT-LAYER-FAILURE-REPORTING- INFRASTRUCTURE companion documenting how the per-domain DNS-record-publication- discipline this 13-rule DKIM operator synthesis embodies STRUCTURALLY PARALLELS the per-domain DNS-record-publication- discipline operators apply to the transport-layer TLS-RPT failure-reporting infrastructure. Where THIS page documents the 13-rule message-layer DKIM operator discipline (Rule 1 key publication, Rule 2 algorithm-choice, Rule 4 90-day rotation cadence, Rule 9 selector-hygiene, Rule 11 daily-RUA-monitoring), the TLS- RPT-record-syntax spoke is the TRANSPORT- LAYER PUBLICATION-DISCIPLINE companion documenting the structurally-parallel operator-discipline at the _smtp._tls.<domain> TXT-record publication boundary. The four-axis DKIM-MESSAGE-LAYER-VS-TLS-RPT- TRANSPORT-LAYER comparison exposes the structurally-distinct PUBLICATION- DISCIPLINE parallels: (i) DKIM <selector>._domainkey.<domain> TXT-record publication discipline → TLS-RPT _smtp._tls.<domain> TXT-record publication discipline — both publish at per-subdomain underscore-prefixed locations (the DKIM _domainkey namespace, the TLS-RPT _smtp._tls namespace), both use the v=<protocol-version> version-tag-first conformance pattern (DKIM's v=DKIM1, TLS-RPT's v=TLSRPTv1), both face the same byte-syntax-bug-risks (mis-formatted tag, missing required tag, accidentally- truncated record at 255-byte segment boundary) the spoke documents at the parallel transport-layer-policy- publication boundary; (ii) DKIM Rule 4 90-day rotation cadence → TLS-RPT rua-endpoint rotation cadence as parallel operator-discipline — DKIM Rule 4 mandates a 90-day key- rotation cadence requiring per-rotation dual-selector publication discipline; the TLS-RPT operator-discipline parallel is the per-domain rua=mailto: or rua=https: reporting- endpoint rotation discipline (typical cadence: reporting-endpoint URL consolidation across reorganized DMARC- analyzer-vendor tenancy, or per-domain TLS-RPT reporting-endpoint failover coordination), the spoke documents the per-rotation publication-quality KPI the operator monitors; (iii) DKIM Rule 11 daily-RUA-monitoring observability discipline → TLS-RPT per-period transport-failure-report observability discipline — DKIM Rule 11 mandates daily-RUA-monitoring of per-domain DKIM-pass / fail / permerror / temperror outcome rates; the TLS-RPT observability parallel is the per-day per-domain transport- failure-report ingestion of TLS-PASS / TLS-FAIL / STARTTLS-NEGOTIATION-FAIL / DANE-VALIDATION-FAIL / MTA-STS-POLICY- FETCH-FAIL outcome rates the rua= reporting endpoint receives, the spoke documents the per- report-period byte-syntax operators consume during daily transport-layer triage; (iv) DKIM Rule 11 KPI- threshold-alert escalation discipline → TLS-RPT-failure-report alert- escalation discipline — DKIM Rule 11 specifies per-domain KPI thresholds (DKIM-pass-rate ≥98% steady- state, DKIM-fail-rate <1% over 7-day rolling window) the operator alerts on; the TLS-RPT operator- discipline parallel is the per-period transport-failure-rate threshold (TLS-PASS ≥99% steady-state for MTA-STS- deployed domains, sudden spike in STARTTLS-NEGOTIATION-FAIL count as downgrade-attack-detection signal), the spoke documents the TLS-RPT-specific alert-threshold reference operators extend the DKIM-Rule-11-discipline muscle-memory into. Read the TLS-RPT- record-syntax spoke when the operator's DKIM-best-practices muscle-memory (per- domain DNS-RR publication-discipline, per-domain DNS-RR publication-quality KPI, per-day observability discipline, per-domain KPI-threshold-alert escalation) needs to extend to the transport-layer failure-reporting infrastructure that operates on STRUCTURALLY-PARALLEL DNS- TXT-RR-publication primitives.
• Email deliverability — the DKIM-CRYPTOGRAPHIC-POSTURE-AS-LOAD- BEARING-DELIVERABILITY-DRIVER-FOR-INBOX- PLACEMENT-AT-MAILBOX-PROVIDER-RECEIVE-SIDE companion documenting the umbrella inbox- placement outcome (Gmail / Yahoo / Outlook / AOL / Apple iCloud / Fastmail mailbox-provider inbox-vs-junk-folder routing decisions) every 13-rule operator-discipline rule on this DKIM- best-practices page silently invests in. Where THIS page documents the PRODUCTION- DEPLOYMENT DEFAULTS a DKIM signer SHOULD adopt (the 2048-bit RSA / Ed25519 algorithm floor per RFC 8301 + RFC 8463, the c=relaxed/relaxed canonicalisation default, the 90-day rotation cadence, the l=-tag avoidance, the RFC 9103 x= expiration tag, the dual- selector zero-downtime rotation pattern), the email-deliverability spoke is the UMBRELLA- OUTCOME companion documenting WHY each best- practices rule matters at the receiver-side deliverability boundary. The four-axis DKIM- BEST-PRACTICES-VS-DELIVERABILITY-OUTCOME comparison exposes the structurally-distinct DKIM-POSTURE-AS-DELIVERABILITY-DRIVER roles: (i) mailbox providers score DKIM- aligned-pass as the primary cryptographic- identity-trust signal in their inbox-placement decision tree — a domain's DKIM- aligned-pass-rate over the last 7-30 days is the load-bearing input to Gmail Postmaster Tools' "Domain reputation" metric and the equivalent Microsoft SNDS / Yahoo Sender Hub / Apple Postmaster receive-side scores; the 13-rule best-practices discipline ON THIS PAGE is the operational recipe for sustaining that DKIM-aligned-pass-rate above the 99% threshold mailbox providers treat as "trusted-sender" qualifier; (ii) weak DKIM keys (1024-bit RSA, missing Ed25519 fallback) produce mailbox-provider-side downgrade flags that surface as silent spam-folder routing — the deliverability spoke documents the specific receive-side checks (Gmail's p= key-strength evaluation, Outlook's DKIM-key-size composite score, Yahoo's dkim-modulus-bits metric) the 2048-bit algorithm-floor rule on this page is designed to clear; (iii) DKIM key rotation cadence directly drives mailbox- provider anti-replay confidence — receive-side anti-replay heuristics treat a stable-for-365-days selector with suspicion (replay-attack surface) while a 90-day- rotating dual-selector pattern (this page's zero-downtime rotation rule) produces measurable inbox-placement improvement at the 30-day moving average; (iv) the l=-tag avoidance rule on this page is load-bearing for deliverability because mailbox providers penalize partial- body-signed messages as a known replay-vector signal — the deliverability spoke documents the per-provider penalty magnitudes the avoidance rule prevents. Read the email-deliverability spoke when scoping the umbrella inbox-placement outcome each 13-rule best-practices rule on this page is engineered to optimise, and when building the deliverability-monitoring feedback loop that surfaces best-practices- rule-violation churn at the mailbox-provider receive boundary.
• DMARC myths and misconceptions — the cluster-spanning myths catalogue this DKIM-best-practices page refutes the DKIM-specific myths from — the CLUSTER-SPANNING MYTHS CATALOGUE operators arrive at after this page's 13-rule best-practices discipline REFUTES the canonical DKIM myths in passing. Where THIS page documents the PRODUCTION-DEPLOYMENT DEFAULTS a DKIM signer SHOULD adopt (the 2048-bit RSA / Ed25519 algorithm floor per RFC 8301 + RFC 8463, the c=relaxed/relaxed canonicalisation default, the 90-day rotation cadence, the l=-tag avoidance, the RFC 9103 x= expiration tag, the dual-selector zero-downtime rotation pattern), the myths-catalogue spoke is the OPERATIONAL CROSS-PROTOCOL TAXONOMY of the full myths-and-misconceptions family the DKIM-specific myths this page refutes are catalogued in: the DKIM-protocol myths (DKIM proves message integrity end-to-end across forwarders, ED25519 is required for modern compliance, the l= tag bounds replay cleanly, single-selector deployment is sufficient, rotation is optional once deployed, weak-key reputation transfer is a myth) are catalogued ALONGSIDE the cluster's adjacent myth families: the SPF myths (SPF authenticates From:, SPF stops spoofing, ~all is safer than -all), the DMARC-protocol myths (DMARC blocks all phishing, p=none is safe forever, pct= partially deploys safely, sp= inherits automatically), the alignment myths (relaxed alignment is permissive, strict alignment is always safer, organizational-domain extraction is intuitive), the BIMI myths (BIMI requires VMC at every receiver, BIMI improves deliverability directly), the transport-security myths (MTA-STS replaces DANE, TLS encryption stops phishing), and the threat-model myths (display-name spoofing is cosmetic, BEC is solved by authentication alone, DKIM replay is theoretical). Read the myths-catalogue spoke when stakeholders arrive with DKIM-specific misconceptions this page's 13-rule discipline refutes in operational form ("we have DKIM so we're protected", "rotation is cosmetic", "single selector is enough", "the l= tag is a security control") — the catalogue is the cluster-spanning navigation reference where each myth gets its dedicated refutation paragraph the operator can quote in stakeholder-management conversations.
• Phishing protection — the DKIM-CRYPTOGRAPHIC-HYGIENE-AS- PHISHING-DEFENSE-FOUNDATION companion to this 13-rule DKIM best-practices discipline. Where THIS page documents the PRODUCTION-DEPLOYMENT DEFAULTS a DKIM-deployed operator must adhere to (RSA-2048 floor key length per RFC 8301, ≥3-month key-rotation cadence, dual- selector overlap during rotation, t=y test-mode boundary discipline, relaxed canonicalization default per RFC 6376 §3.4, the 15-rule operator-discipline synthesis), the phishing-protection spoke is the THREAT-CATALOGUE DEFENSE-IN-DEPTH companion documenting how the cryptographic-hygiene posture this page enforces is the application-layer FOUNDATION layer of the phishing-defense stack — a defense-in-depth dimension structurally DOWNSTREAM of every best-practice rule on this page because (i) RSA key-length regression below RFC 8301's 2048-bit floor produces dkim=permerror at the receiver, which DMARC alignment then evaluates as DKIM-fail, which collapses the DKIM defense layer in the phishing-protection stack — a sustained regression of the rule 1 best-practice opens a phishing-vector against the publisher's protected domain, (ii) a botched DKIM key-rotation (rule 3) that forgets the overlap-window discipline breaks dkim=pass for the entire mail flow until the key is republished — a publisher-side outage that is operationally indistinguishable from a phishing campaign downgrading the publisher's DMARC-pass-rate during the attack window, (iii) the canonicalization-default rule (rule 5) determines whether the DKIM signature survives forwarder body-modification — the phishing-protection spoke's defense-in-depth model explicitly depends on DKIM-signed mail surviving every legitimate forwarder hop so the forensic-attribution chain remains intact through the phishing-incident investigation. Read the phishing- protection spoke once the 13-rule best-practices discipline on this page is fully deployed and the operator needs the threat-catalogue context for how each rule contributes a structural defense layer the phishing-protection spoke synthesises across the DMARC+DKIM+SPF+BIMI+MTA-STS defense-in-depth stack.
• MTA-STS policy file syntax — the MTA-STS-HTTPS-POLICY-FILE- PUBLICATION-DISCIPLINE-AS-LOAD- BEARING-TRANSPORT-LAYER-PUBLISHER- OPERATIONAL-DISCIPLINE-PARALLEL-TO- DKIM-MESSAGE-LAYER-SELECTOR- PUBLICATION-DISCIPLINE companion to THIS DKIM best-practices reference. Where THIS page documents the 13-rule DKIM publisher-side operational discipline (per-selector 2048-bit- minimum key-sizing, per-selector quarterly-rotation cadence, per- selector PRIMARY/SECONDARY dual- publication during rotation, per- selector empty-p= retirement publication, per-tenant per-third-party-sender per-selector partitioning, per-tenant per- subdomain per-selector publication topology), the MTA-STS-policy- syntax spoke is the TRANSPORT-LAYER PUBLISHER-OPERATIONAL-DISCIPLINE PARALLEL REFERENCE documenting the publisher-side per-policy-id publication-and-rotation operational discipline whose every per-publisher operational primitive is the TRANSPORT-LAYER sibling to the DKIM MESSAGE-LAYER per-selector operational primitive THIS page documents at FOUR cross-layer per- publisher-publication-discipline- coupling dimensions: (i) per- publisher per-policy-id rotation cadence vs per-DKIM-selector rotation cadence — both publication disciplines document a per-publisher per-publication- instance rotation cadence the receiver-side verifier observes deterministically (DKIM per-selector quarterly-rotation publication discipline vs MTA-STS per-policy-id rollover publication discipline with _mta-sts TXT id:-bump and HTTPS policy-host re-publication), and the MTA-STS-policy-syntax spoke documents the per-policy-id rotation cadence and per-receiver per-policy cache-invalidation contract whose every per-policy rotation-event is the transport- layer sibling to the per-DKIM- selector rotation-event discipline THIS page documents; (ii) per-publisher HTTPS- certificate-rotation discipline vs per-DKIM-selector key-rotation discipline — both publication disciplines impose a per-publisher cryptographic-key / certificate-rotation cadence the receiver-side verifier cryptographically validates (DKIM per-selector public-key rotation cadence vs MTA-STS per-policy- host HTTPS certificate rotation cadence governing per-policy- host TLS-cert-validation), and the MTA-STS-policy-syntax spoke documents the per-policy-host HTTPS-certificate-rotation coordination discipline whose cryptographic-rotation cadence is the transport-layer sibling to the per-DKIM-selector key-rotation discipline THIS page's rotation-rule documents; (iii) per-publisher mode:none → mode:testing → mode:enforce progressive-rollout publication discipline vs per-DKIM-publication- then-DMARC-alignment-ramp publication discipline — both publication disciplines document a per-publisher progressive-rollout-with- observation publication discipline that ramps publisher- side enforcement from observation-only to full- enforcement against published per-receiver verdict streams (DKIM publication-then- p=none-then- p=quarantine-then- p=reject ramp vs MTA-STS mode:none- then-mode:testing- then-mode:enforce ramp), and the MTA-STS-policy- syntax spoke documents the per- mode progressive-rollout-with- TLS-RPT-observation discipline whose every per-mode ramp-stage is the transport-layer sibling to the DKIM publication-and- DMARC-alignment ramp discipline THIS page references; (iv) per-publisher publication-discipline-as- load-bearing-foundation: every downstream message-authentication outcome (DMARC alignment, ARC chain preservation, BIMI logo rendering) depends on the per-publisher DKIM publication discipline THIS page documents, and every downstream transport- layer enforcement outcome (TLS- RPT failure observation, DANE/MTA-STS combined enforcement, downstream deliverability) depends on the per-publisher MTA-STS publication discipline the MTA-STS-policy-syntax spoke documents — both publication disciplines are the load-bearing per-publisher operational foundations whose per-publication misconfiguration cascades downstream to every adjacent receiver-side enforcement outcome, and the MTA-STS-policy-syntax spoke documents the transport-layer publication-discipline-as- load-bearing-foundation parallel to the DKIM message-layer publication-discipline-as-load- bearing-foundation THIS page establishes. Read THIS page when authoring the per-DKIM- publisher operational discipline; read the MTA-STS-policy-syntax spoke when authoring the per-MTA-STS-publisher operational discipline — both publication-disciplines form the load-bearing per-publisher operational-discipline stack every adjacent receiver-side enforcement outcome depends on.
• DMARC attacker-bypass techniques (defender's red-team catalogue) — the DKIM-PUBLICATION-DISCIPLINE-WEAKNESS- CLASS-AS-LOAD-BEARING-DMARC-BYPASS-VECTOR companion to this DKIM best-practices reference. Where THIS page documents the canonical DKIM publication discipline (≥2048-bit RSA OR Ed25519 key strength, per-selector dual-key overlap rotation cadence, selector-namespace lifecycle, canonicalisation-mode choice, replay-window bounding), the DMARC-attacker-bypass spoke is the OPERATOR-SIDE 22-technique attacker- bypass classification framework whose DKIM-CRYPTOGRAPHIC-WEAKNESS-EXPLOITATION technique class consumes the publication- discipline weakness modes at FOUR DKIM- weakness-induction-and-exploitation dimensions: (i) weak-key-factoring attacker forgery via 1024-bit RSA selector — the attacker factors the publisher's legacy 1024-bit RSA selector public key (computationally tractable for nation- state-class adversaries per the documented RSA-1024 factoring research), recovers the private key, and forges arbitrary DKIM- signed messages indistinguishable from legitimate publisher mail at the per- message DKIM verification boundary, collapsing the DKIM leg of the RFC 7489 §6.6.2 OR-conjunction by producing per- message dkim=pass with attacker-controlled content — the attacker-bypass spoke documents this as the canonical weak-key-factoring DKIM-forgery attacker- bypass class the ≥2048-bit RSA discipline THIS page documents protects against; (ii) stale-selector replay attacker exploitation via missing key- rotation discipline — the attacker captures a legitimately-signed message signed with a long-lived (multi-year unrotated) selector, replays the message body to arbitrary recipients, and benefits from per-message dkim=pass at the receiver because the publisher never rotated the selector and never bounded the per- selector signing-lifetime via the dual- key overlap rotation cadence THIS page documents — the attacker-bypass spoke documents this as the canonical stale-selector-replay attacker-bypass class the per-selector dual-key overlap rotation cadence THIS page documents protects against; (iii) retired-selector- revival attacker exploitation via missing key-revocation discipline — the attacker identifies a previously-rotated-out selector whose private key was leaked or compromised at any point in its operational lifetime, and signs forged messages with the leaked private key against a publisher whose retired-selector public- key TXT was NEVER explicitly revoked via the p= empty-value revocation signal nor removed from DNS, producing per-message dkim=pass at receivers still resolving the retired selector — the attacker-bypass spoke documents this as the canonical retired-selector- revival attacker-bypass class the per-selector revocation-vs-removal discipline THIS page documents protects against; (iv) l=-tag-bounded-body partial-coverage attacker exploitation — the attacker exploits the publisher's l=-tag-bounded body-hash coverage to append arbitrary attacker-controlled content past the l= byte boundary WITHOUT invalidating the body-hash, producing per-message dkim=pass with partial attacker-controlled content appended to a legitimately-signed body — the attacker-bypass spoke documents this as the canonical l=-tag-bounded-body partial-coverage attacker-bypass class the no-l=-tag whole-body coverage discipline THIS page documents protects against. Read the DMARC-attacker-bypass spoke ALONGSIDE this DKIM best-practices reference when designing the per- publisher per-domain DKIM-attacker- bypass-defense posture and when investigating per-receiver per-source- IP per-day dkim=pass surge evidence whose attribution to legitimate-sender- vs-attacker-forgery requires the attacker-bypass classification framework — the spoke is the canonical 22- technique attacker-bypass classification framework whose DKIM-cryptographic- weakness-exploitation technique class consumes the publication-discipline weakness modes this page documents.
• DMARC for cPanel-hosted domains — the PER-CPANEL-WHM-EMAIL- DELIVERABILITY-DKIM-KEY- MANAGEMENT-INTERFACE companion to this DKIM-best-practices reference. Where THIS page documents the DKIM publication- discipline best-practices (the ≥2048-bit RSA key-length floor per RFC 8301, the per-publisher per-selector rotation cadence, the <selector>._domainkey.<d-domain> TXT-record publication discipline, the per-rotation dual-selector overlap-window discipline, the emergency-revocation via empty p= tag, the algorithm-upgrade pathway from rsa-sha256 to ed25519-sha256 per RFC 8463), the dmarc_for_cpanel spoke documents the per-cPanel- WHM Email Deliverability + Exim-managed DKIM-key infrastructure whose per-tenant DKIM-key-generation + DKIM-selector-rotation interface IS the canonical load-bearing per-tenant DKIM-publication- operational infrastructure the per-publisher DKIM-best-practices THIS page documents resolves to at the per-cPanel-tenant deployment boundary. FOUR structurally-distinct PER-CPANEL- WHM-DKIM-INTERFACE-VS-DKIM- PUBLICATION-DISCIPLINE-STAGE- COUPLING-DIMENSIONS the dmarc_ for_cpanel spoke operationally documents: (i) per-cPanel- "Email Deliverability" → "Manage" → "Repair" DKIM-key-auto- generation coordinated with the canonical default._domainkey.<d-domain> TXT-record-publication AS LOAD- BEARING-PER-TENANT-INITIAL-DKIM- DEPLOYMENT-PRIMITIVE — cPanel's Email Deliverability interface auto-generates the per-tenant 2048-bit RSA DKIM private-key + per-tenant default._domainkey.<d-domain> TXT-record matching the RFC-8301 2048-bit-RSA floor THIS page's key-length-floor discipline catalogues; the dmarc_for_cpanel spoke documents the canonical per-tenant Email Deliverability → Repair workflow + the canonical default-selector publication shape every per- tenant initial DKIM deployment THIS page's initial-publication discipline depends on at the per-cPanel-tenant deployment boundary; (ii) per-cPanel- WHM "Manage External Authentication" → per-tenant custom-selector DKIM-key generation coordinated with the per-tenant per-rotation dual- selector publication-window AS LOAD-BEARING-PER-TENANT-KEY- ROTATION-OPERATIONAL-PRIMITIVE — per-tenant DKIM- key-rotation requires generating a new selector (e.g., s2026._domainkey.<d-domain>) while keeping the old selector published for the rotation overlap-window THIS page's dual-selector overlap-window discipline catalogues; the dmarc_for_cpanel spoke documents the canonical per-cPanel-WHM per-tenant custom-selector key- generation workflow + the per- tenant 7-to-14-day dual-selector publication-window coordination + the canonical per-mail-stream DKIM-Signature s=-tag-cutover discipline every per-tenant key- rotation outcome THIS page's per-publisher rotation-cadence discipline depends on at the per-cPanel-tenant deployment boundary; (iii) per- cPanel-tenant Zone Editor TXT- record-publication discipline coordinated with the per-tenant DKIM-public-key v=DKIM1; k=rsa; p=<base64> byte- publication AS LOAD-BEARING- PER-TENANT-DKIM-DNS-PUBLICATION- DISCIPLINE-PRIMITIVE — per-tenant DKIM-key publication REQUIRES the <selector>._domainkey.<d-domain> TXT-record to be published via the per-tenant Zone Editor (or WHM Zone Templates for reseller- deployments); the dmarc_for_ cpanel spoke documents the canonical per-tenant Zone Editor TXT-record publication workflow + the 255-octet character-string- fragmentation per RFC 1035 §3.3.14 for ≥2048-bit base64-encoded public-key payloads every per- tenant DKIM-TXT-record publication outcome THIS page's DNS- publication-byte-grammar discipline depends on at the per-cPanel-tenant deployment boundary; (iv) per- cPanel-WHM Exim Configuration Manager → DKIM-signing-enable- per-domain toggle coordinated with the per-tenant per-source- IP outbound DKIM-Signature header emission AS LOAD-BEARING-PER- TENANT-DKIM-SIGNING-EGRESS- DISCIPLINE-PRIMITIVE — cPanel's Exim configuration controls the per-tenant per- source-IP outbound DKIM-signing behaviour at the SMTP-egress boundary; the per-tenant Exim DKIM-signing toggle MUST be coordinated with the per-tenant DKIM-key publication state and the per-tenant per-selector rotation-cutover state; the dmarc_for_cpanel spoke documents the canonical per-cPanel-WHM Exim Configuration Manager DKIM- signing-enable workflow + the per-tenant per-source-IP DKIM- Signature header emission verification (via WHM's mail- queue inspection or per-message Send-mail-test) every per-tenant DKIM-Signature-header-emission outcome THIS page's per-publisher DKIM-signing-egress discipline depends on at the per-cPanel- tenant deployment boundary. Read the dmarc_for_cpanel spoke ALONGSIDE this DKIM-best- practices reference whenever a per-cPanel-managed-hosting-tenant publisher scopes a per-tenant DKIM-publication-and-rotation deployment plan — the per-cPanel- WHM Email Deliverability + Zone Editor + Exim Configuration Manager stack THIS deployment spoke documents IS the canonical load-bearing per-shared-hosting- tenant DKIM-publication- operational infrastructure every per-tenant DKIM-best-practice outcome THIS page's publication- discipline catalogue depends on at the per-tenant deployment boundary.
• CAA records explained — the TLS-cert-issuance-authorisation DNS-policy-record companion that locks down WHICH Certificate Authorities may issue TLS certificates for your domain. The 13-rule DKIM-best-practices discipline THIS page synthesises hardens the cryptographic surface at the per-message-signature layer — CAA hardens the parallel cryptographic surface at the TLS-certificate layer that BIMI's VMC certificate (per BIMI Group Working Specification) and MTA-STS (per RFC 8461 §3.2's mta-sts.<domain> HTTPS endpoint) both rely on. Without a published CAA record naming your authorised CAs, ANY publicly-trusted CA may issue a TLS certificate for mta-sts.<domain> or any other email-related host on your domain — silently weakening the TLS-cert layer the rest of the email-authentication stack depends on. Read this CAA reference alongside the DKIM-best-practices 13-rule discipline when auditing zone-level cryptographic-policy hygiene.
• Business Email Compromise (BEC) — the FINANCIAL-IMPACT THREAT-MODEL downstream consumer of this DKIM-best-practices 13-rule operator discipline. Where THIS page synthesises the per-publisher per-selector cryptographic-publication discipline (RSA-2048 minimum, Ed25519 future-proofing, quarterly rotation, private-key custody, relaxed canonicalisation) every operator owes their domain, the BEC spoke documents the FBI-IC3-tracked $2.9B-2024-loss attack class whose exact-domain From-header impersonation stage the DKIM private-key-secrecy primitive THIS page architectures is the load-bearing application-layer cryptographic defence against. Read THIS page when AUDITING the per-publisher DKIM-operational-discipline posture; read the BEC spoke when COMMUNICATING the downstream business-risk justification for that posture to non-technical stakeholders.
• DMARC for transactional email — the PER-ESP-PER-CUSTOMER-DOMAIN- CNAME-DELEGATED-DKIM-SIGNER-PER- SELECTOR-KEY-CUSTODY companion to this DKIM-best-practices operator reference. Where THIS page documents the 13-rule canonical DKIM operational discipline (publisher-managed private-key secrecy at HSM-backed storage, 2048-bit RSA minimum per RFC 8301, quarterly / biannual rotation cadence, dual- selector overlap window, per-selector public-key TXT publication with p= tag binding), the transactional-email spoke is the per- ESP per-customer-domain deployment- execution companion documenting FOUR transactional-DKIM-execution-constraint dimensions whose per-customer satisfaction gates the per-message DKIM-verification verdict at the receiver-side: (i) per-ESP- managed private-key custody at the CNAME-delegated signer boundary is the canonical transactional-ESP deviation from the operator-managed HSM-backed secrecy discipline — SendGrid, Mailgun, Amazon SES, Postmark, and SparkPost each manage their tenants' DKIM private keys in ESP-side HSM infrastructure accessed via the CNAME-delegated signer pattern (the customer publishes s1._domainkey.<customer-domain> as a CNAME to s1.domainkey.u123.wl456.sendgrid.net), delegating key custody to the ESP; the transactional-email spoke documents the per-ESP HSM-backed custody discipline, the per-ESP access-control posture, and the per-customer-domain escalation path to BYOK if regulatory or compliance requirements demand customer-side key custody; (ii) per-customer- domain per-selector public-key publication at the customer's DNS zone preserves the per-publisher verifiable-attribution contract this page documents — though the private key lives at the ESP, the CNAME chain anchors the per-selector public-key TXT at the customer's organisational domain (the d=-tag FQDN-equal to the RFC 5322 From- domain), preserving the per-publisher cryptographic identity contract the DKIM-alignment-with-DMARC evaluation depends on; the transactional-email spoke documents the per-customer-domain CNAME-chain authoring discipline that anchors the per-publisher attribution; (iii) per- ESP DKIM-key rotation cadence variance across the five major transactional ESPs determines whether per-customer-domain operations meet the canonical quarterly-or-biannual rotation discipline this page documents — SendGrid rotates quarterly via the dual-selector pattern (s1 / s2 CNAME swap), Mailgun rotates on operator-initiated trigger, Amazon SES rotates per Identity Verification cycle, Postmark rotates on selector cycle, SparkPost rotates per per-customer-domain configuration; the transactional- email spoke documents the per-ESP rotation cadence and the per- customer-domain operator-discipline for satisfying the dual-selector overlap window this page documents; (iv) per-customer-domain escalation path to operator-managed BYOK (Bring-Your-Own-Key) signing is the structurally-required remediation when regulatory or compliance constraints demand customer-side key custody — the transactional-email spoke documents the per-ESP BYOK provisioning discipline (the per-ESP custom-key-upload UI affordance, the per-customer- domain HSM-backed key generation requirements, the per-ESP signing-pipeline integration discipline) and the per-customer- domain operator-escalation path from ESP-managed to BYOK-managed per-selector key custody. Read the transactional-email spoke ALONGSIDE this DKIM-best-practices operator-reference whenever the operator scopes the per-customer- domain DKIM-execution discipline on SendGrid / Mailgun / Amazon SES / Postmark / SparkPost — the 13-rule DKIM operational discipline THIS page architectures IS the load-bearing publisher-side per- message cryptographic-attribution primitive the transactional-email deployment guide encodes the per-ESP per-customer-domain execution discipline for.
• DMARC aggregate (RUA) reports — the RFC-7489-§7.2 XML-AGGREGATE- EVIDENCE-STREAM companion to this DKIM-best-practices reference. Where THIS page documents the 13-rule per- publisher per-domain DKIM operational discipline (RSA-2048 key floor, quarterly rotation cadence, dual- selector rotation pattern, canonicalization choice, header-list commitment, hash-algorithm choice, per-tenant DKIM-signer scope), the aggregate-reports spoke is the receiver-side daily per-publisher per-domain feedback evidence-stream documenting the FOUR per-day per- receiver per-source-IP row-level evidence channels that surface DKIM- best-practice compliance vs drift: (i) the per-row <auth_results> <dkim> sub-element sequence enumerating per-source-IP per-day DKIM-verifier verdicts (pass / fail / policy / neutral / temperror / permerror) the per- publisher per-domain operator consumes daily to measure the per- rule per-selector signature-pass rate the 13-rule discipline targets; (ii) the per-row <policy_evaluated> <dkim> alignment verdict whose pass / fail distribution across per-day per-source-IP rows is the per-publisher per-domain per-rule alignment-compliance measurement surface (every rule on THIS page either preserves or breaks the d=-tag organizational-domain alignment the aggregate-evaluator records); (iii) the per-row <auth_results> <dkim> <selector> element identifying WHICH per-publisher per-domain selector signed each per- source-IP per-day row, surfacing dual-selector-rotation operational evidence (both old + new selectors actively signing during the grace- period overlap THIS page's quarterly- rotation rule mandates), per-rule selector-naming-convention drift, and per-tenant unauthorized-signer appearance; (iv) the per-row <auth_results> <dkim> <domain> element recording the actual signing-domain each per-source-IP per-day row used, surfacing per-publisher per-domain third-party-signer d=-tag-mismatch drift (every per-rule per-relay unauthorized-signer adoption surfaces here as a per-source-IP per-day row whose signing-domain DOES NOT match the per-publisher organizational domain). Read THIS page when AUTHORING the per-publisher per- domain 13-rule DKIM operational discipline; read the aggregate- reports spoke when MEASURING the per-rule per-selector per-source- IP compliance against the 13-rule discipline via the daily per- receiver RFC-7489-§7.2-XML evidence stream the per-publisher per-domain RUA mailbox accumulates.
• SPF qualifiers explained — the LOAD-BEARING per-publisher per-domain PER-PUBLISHER-PER-DOMAIN- SPF-TERMINAL-QUALIFIER-BEST-PRACTICE- RULE-SET-PEER-OF-PER-PUBLISHER-PER- SELECTOR-DKIM-SIGNING-BEST-PRACTICE- RULE-SET companion documenting the seven canonical SPF-qualifier-choice mistakes (+all in production opening the publisher's SPF authorization to every sender on the public Internet, indefinite ~all never advancing past deployment-monitoring, ?all as a soft-enforcement misunderstanding producing spf=neutral equivalent to publishing no SPF record at all, omitted terminal qualifier defaulting to +all on a single- mechanism trailing-space typo, incoherent ~all + DMARC p=reject producing receiver-side enforcement-vs-publisher- side-deployment-monitoring contradiction, premature ~all → -all flip without ≥30 days of aggregate-report evidence, per- mechanism - on an uncontrolled include: producing third-party-vendor-managed- IP-range-coverage-gap rejections) and the canonical ~all → -all enforcement-ramp playbook as the SPF-PILLAR STRUCTURAL TWIN of the DKIM-PILLAR 13-rule signing-discipline catalogue THIS page documents. Where THIS page documents the per-publisher per- selector DKIM-SIGNING DISCIPLINE BEST-PRACTICE RULE-SET (RSA-2048 key size, ≥90-day rotation cadence, relaxed/relaxed canonicalization, body- length-tag disuse, dual-selector overlap-window rotation, signed-header- list discipline, etc.), the qualifiers spoke documents the PARALLEL SPF-PILLAR per-publisher per-domain SPF-TERMINAL- QUALIFIER-CHOICE BEST-PRACTICE RULE-SET — the seven publisher-side qualifier mistakes and the canonical ~all-monitoring → -all-enforcement ramp playbook that PARALLELS the per- selector DKIM-rotation-overlap-window ramp playbook THIS page documents. Read THIS page when AUTHORING the per-publisher per-selector DKIM- signing-discipline best-practice rule- set across the 13 catalogued rules; read the qualifiers spoke when AUTHORING the PARALLEL per-publisher per-domain SPF-terminal-qualifier-choice best- practice rule-set that completes the per-publisher per-domain LAYERED AUTHENTICATION-DISCIPLINE BEST-PRACTICE DOCTRINE the two pillar-spokes co-author.
• DMARC forensic (failure / RUF) reports — the DMARC forensic-reports spoke documents the RFC 6591 ARF + RFC 7489 §7.3 + RFC 8460 per-message failure-envelope grammar that the receiver- side DMARC evaluator emits to the publisher-published ruf= mailbox carrying per-failure DKIM- diagnostic block evidence which closes the per-publisher per-domain DKIM-best- practice operator-discipline feedback loop the 13 catalogued rules on THIS page depend on for empirical regression detection. Four BEST-PRACTICE-RULE-VS- FORENSIC-DIAGNOSTIC-BLOCK coupling axes the forensic-reports spoke documents: (i) the RFC 8301 RSA-2048 key- strength-floor best-practice rule's per-publisher per-selector compliance is empirically verified through the per- failure ARF envelope's dkim=fail evidence-row when a receiver-side verifier rejects an RSA-1024 signature for being below the per-receiver key-strength floor — without forensic-report consumption, the per-publisher per-selector sub-floor key-strength regression remains invisible at the per-publisher per-domain per-receiver per-day evidence granularity; (ii) the per-selector key-rotation cadence best-practice rule (90–180-day rotation with 7-day overlap window) is empirically verified through the per- failure ARF envelope's dkim=permerror + policy.dkim-domain=<rotated-out- selector> evidence-row when a receiver-side resolver fails to fetch the deprecated-selector TXT record — the forensic-reports spoke catalogues per-selector permerror evidence rows as the canonical operator-discipline validation signal that a per-publisher per-domain selector rotation was completed WITHOUT prematurely removing the deprecating selector before the per- receiver verifier-side resolver-cache warmed up; (iii) the canonicalization-mode-consistency best- practice rule (c=relaxed/relaxed as the per-publisher default across the outbound-egress signing-MTA fleet) is empirically verified through the per- failure ARF envelope's dkim=fail + policy.dkim-domain=<publisher> evidence-row when a signing-MTA cohort regression to c=simple/simple produces per-message dkim=fail verdicts on cryptographically-legitimate publisher- signed mail traversing legitimate per- receiver whitespace-normalising relay paths — the forensic- reports spoke catalogues this evidence-row class as the canonical operator-discipline regression signal indistinguishable from attacker spoofing at the per-publisher per- domain per-receiver per-day evidence granularity; (iv) the multi-signature any-aligns-wins best- practice rule (per-publisher per-domain dual-algorithm signing posture: RSA-2048 + Ed25519) is empirically verified through the per-failure ARF envelope's per- signature attribution evidence at the per-publisher per-domain per-receiver per- day evidence granularity — per-publisher per-domain multi-signature deployments populate the per-failure ARF envelope with per-signature dkim=pass / dkim=fail / dkim=permerror rows whose per-signature attribution evidence is the canonical operator-discipline validation signal that the per-publisher per-domain verifier-coverage divergence-mitigation best-practice rule is operating as designed across the heterogeneous per- receiver verifier population. Read THIS page when AUTHORING the per-publisher per-domain 13-rule DKIM best-practice operator-discipline rule-set; read the forensic-reports spoke when CONSUMING the per-publisher per-domain per-failure ARF envelope evidence stream that empirically validates per-rule operator-discipline compliance and surfaces per-rule regression at the per-publisher per-domain per-receiver per-day evidence granularity.
• SPF PermError vs TempError Four cross-protocol operator-discipline coupling dimensions: (i) per-publisher per-domain DKIM Rule 1 (2048-bit RSA modulus floor) vs per-publisher per-domain SPF permerror from include:-chain expansion exceeding RFC 7208 §4.6.4 ten-DNS-query budget — both error classes arise from per-publisher per-domain DNS-RR-publication-discipline-violation at the per-protocol authoring boundary, both produce per-receiver authentication-fail verdicts at the per-message evaluation boundary, and both drive identical operator-side per-domain DMARC-aligned-fail RUA rows the per-publisher per-domain analytics team consumes; (ii) per-publisher per-selector DKIM Rule 3 (key-rotation cadence) vs per-publisher per-domain SPF temperror from transient receiver-side DNS-resolver outages — the per-rotation overlap-window discipline on the DKIM side has no SPF analog, but the per-publisher per-domain per-receiver temperror retry-behaviour is governed by the per-publisher SPF-record TTL — short TTLs amplify per-receiver per-message temperror retries, long TTLs amplify per-receiver per-resolver-cache stale-record-window exposure; (iii) per-publisher per-domain DKIM-record canonicalization (c=relaxed/simple tag choice) vs per-publisher per-domain SPF-record %{i}/%{p} macro-expansion permerror — both error classes arise from per-publisher per-domain authoring-discipline-violation at the per-protocol byte-syntax boundary, both produce per-receiver per-message authentication-fail verdicts, and both surface in the unified per-publisher per-domain per-receiver per-day RUA evidence stream this DKIM best-practices reference documents the operator-discipline producer of; (iv) per-publisher per-domain DKIM Rule 7 (forensic-RUF AFRF embedded evidence consumption) vs per-publisher per-domain SPF-permerror-vs-temperror RUF AFRF embedded-evidence consumption — both per-rule consumption disciplines tap the same per-publisher per-domain per-failure ARF-MIME envelope evidence stream the per-publisher per-domain forensic-reports spoke documents, and both feed the unified per-publisher per-domain operator-discipline-regression-detection workflow this DKIM best-practices reference structurally relies on. Read the SPF-permerror-vs-temperror spoke alongside this DKIM best-practices reference when the per-publisher per-domain operator is auditing both authentication-layer per-rule operator-disciplines (DKIM per-rule and SPF per-error-code) against the unified per-publisher per-domain per-receiver per-day RUA evidence stream, when investigating per-publisher per-domain DMARC-aligned-fail rows correlating to BOTH per-publisher per-domain DKIM-rule-violation AND per-publisher per-domain SPF-record-publication-violation, or when authoring per-publisher per-domain per-protocol operator-discipline runbooks that must coordinate per-protocol per-rule authoring discipline against the unified per-publisher per-domain per-receiver per-message authentication-verdict evidence stream.
• DNS propagation timelines — the TTL-bounded publish-and-verify-cycle primitive whose four DNS-propagation-vs- DKIM-best-practices-operator-discipline coupling dimensions this 15-rule reference materially depends on: (i) Rule 3 (per-publisher per-selector key-rotation cadence with dual-selector overlap-window coexistence) STRUCTURALLY REQUIRES per-publisher per-selector overlap-window period exceeding the previous selector's published TTL — without TTL-bounded overlap-window discipline, post-cutover per-receiver per-message dkim=fail verdicts surface on cryptographically- legitimate mail signed by the new selector whose public-key TXT record has not yet propagated through every per-receiver per-resolver cache, defeating Rule 3's seamless-rotation operator-discipline intent and producing per-publisher per- domain DMARC-aligned-fail RUA rows the operator's analytics team cannot distinguish from a Rule 3 violation; (ii) Rule 1 (RFC 8301 RSA-2048 key-strength floor enforcement via re-publication of every sub-2048-bit selector) STRUCTURALLY DEPENDS on RFC 2308 negative-cache window discipline for the per-publisher per-selector revocation-via-empty-p= propagation-tail — when Rule 1 remediation requires emergency revocation of a sub-2048-bit selector via empty- p= publication, per-receiver per-resolver negative-cache TTL governs the propagation window before per-receiver caches expire the revoked record AND begin rejecting mail signed by the under-strength selector — long negative-cache TTLs magnify Rule 1 remediation latency at scale; (iii) Rule 4 (per-publisher per-selector CNAME-delegated DKIM publication for per-ESP / per-mailbox-provider canonical- name authoring discipline) STRUCTURALLY DOUBLES the TTL-bounded propagation window — per-receiver verification MUST resolve the CNAME alias chain BEFORE retrieving the per-selector TXT record, compounding the per-selector TTL with the per-CNAME-alias TTL the ESP publishes independently, widening the per-publisher per-selector publish-and-verify cycle Rule 4's CNAME-delegation discipline structurally relies on; (iv) Rule 8 (per- publisher per-domain RUA aggregate-report consumption-discipline as the empirical feedback loop validating per-rule operator- discipline compliance) STRUCTURALLY CONSUMES the per-receiver per-day RUA auth_results evidence stream surfaced AFTER per-receiver per-resolver cache TTL has elapsed — per-publisher per-domain per-receiver per-day RUA-row evidence validating Rule 1-7 compliance materialises ONLY after the post-publish TTL-bounded propagation tail completes, defining a per-publisher per-domain per-rule operator- discipline regression-detection latency floor the per-publisher per-domain analytics team's per-rule feedback-loop runbook must explicitly account for. Read the DNS- propagation timelines spoke alongside this 15-rule DKIM best-practices reference when planning per-publisher per-selector key- rotation cadence (Rule 3), when authoring per-publisher per-domain emergency-revocation runbooks for under-strength key remediation (Rule 1), or when interpreting per-publisher per-domain per-receiver per-day RUA-row evidence under post-publish TTL-bounded propagation-tail latency (Rule 8).
• RFC 6376 — DKIM specification
• RFC 8301 — DKIM cryptographic algorithm update
• RFC 8463 — Ed25519 signature algorithm for DKIM
• RFC 8617 — ARC (Authenticated Received Chain)
• Email Header Analyzer — the diagnostic surface for every rule on this page.
• Domain Security Checker — DNS-side validation for every selector your domain publishes.
• DMARC policy rollout — the PER-PUBLISHER-DKIM-SIGNING- DISCIPLINE-BEST-PRACTICE-GREEN-STATE- BASELINE-AS-LOAD-BEARING-PRECONDITION- OF-PER-PUBLISHER-DMARC-RAMP-STEP- TIGHTENING companion to this DKIM- signing-discipline best-practice reference. Where THIS page documents the per- publisher per-selector DKIM-signing- discipline best-practice rule-set (per- publisher per-selector 2048-bit RSA key- size, per-publisher per-selector scheduled key-rotation cadence, per- publisher per-message simple-vs-relaxed canonicalization-choice rule-set, per- publisher per-message h= header-tag-coverage rule-set, per- publisher per-selector DNS publication discipline), the policy-rollout spoke is the per-publisher per-domain DMARC enforcement-progression discipline whose every p=none → p=quarantine → p=reject ramp-step tightening commit is gated by the per-publisher per- selector DKIM-signing-discipline green- state-baseline THIS page documents at FOUR per-DKIM-best-practice-rule-vs-DMARC- policy-ramp-step coupling dimensions: (i) per-publisher per-selector 2048- bit RSA key-size discipline is the load- bearing per-publisher per-selector cryptographic-strength-floor of the per- publisher per-message DKIM-aligned-pass rate the policy-rollout reads — the policy-rollout spoke documents how every per-publisher per-domain ramp-step commit reads the per-publisher per- message DKIM-aligned-pass rate as the load-bearing per-publisher per-domain authentication-leg-health indicator, and the per-publisher per-selector 2048-bit RSA key-size discipline THIS page documents is the load-bearing per- publisher per-selector cryptographic- strength-floor preventing per-receiver per-message DKIM-key-too-weak verdict- rejection at modernised mailbox-provider receivers — a per-publisher per-selector 1024-bit RSA key collapses the per- publisher per-message DKIM-aligned-pass rate at every per-receiver per-message DKIM-evaluation boundary enforcing the modernised key-size floor, BLOCKING the per-publisher per-domain ramp-step tightening commit; (ii) per- publisher per-selector scheduled key- rotation cadence discipline is the load- bearing per-publisher per-selector publication-discipline-regression- resilience input the policy-rollout reads — the policy-rollout spoke documents how the p=quarantine → p=reject ramp-step commit decision reads the per-publisher per- selector publication-discipline- regression-resilience as the load- bearing per-publisher per-domain ramp- step-tightening-survival indicator, and the per-publisher per-selector scheduled key-rotation cadence discipline THIS page documents is the load-bearing per- publisher per-selector regression- resilience input — a per-publisher per- selector rotation event executed without the dual-selector overlap discipline THIS page documents collapses the per- publisher per-message DKIM-aligned-pass rate during the rotation-window and forces a per-publisher per-domain ramp- step rollback; (iii) per- publisher per-message simple-vs-relaxed canonicalization-choice discipline is the load-bearing per-publisher per- message per-forwarder DKIM-signature- survival input of the p=quarantine → p=reject ramp-step commit — the policy-rollout spoke documents how the p=quarantine → p=reject ramp-step commit decision reads the per-publisher per- message per-forwarder DKIM-signature- survival rate as the load-bearing per- publisher per-domain per-forwarder- topology forwarding-resilience indicator, and the per-publisher per- message simple-vs-relaxed canonicalization-choice discipline THIS page documents is the load-bearing per- publisher per-message per-forwarder canonicalization-survival input — a per- publisher per-message simple/ simple canonicalization choice produces per-forwarder per-message signature-survival collapse at every per-forwarder per-message canonicalization-rewriting hop, BLOCKING the per-publisher per-domain p=reject tightening commit until the per-publisher per-message relaxed/relaxed canonicalization choice is committed; and (iv) per-publisher per- message h= header-tag- coverage discipline is the load-bearing per-publisher per-message DKIM-signature- scope-completeness input of every per- publisher per-domain ramp-step — the policy-rollout spoke documents how every per-publisher per-domain ramp-step tightening commit reads the per-publisher per-message DKIM- signature-scope-completeness as the load-bearing per-publisher per-domain authentication-leg-binding-strength indicator, and the per-publisher per- message h= header-tag- coverage discipline THIS page documents is the load-bearing per-publisher per- message DKIM-signature-scope- completeness input — a per-publisher per-message h= tag omitting the From:, Subject:, To:, or Date: header-tag coverage produces per-receiver per- message header-tampering-attack-class false-positive-pass verdicts the per- publisher per-domain DMARC ramp-step cannot detect, weakening the per- publisher per-domain DMARC-authenticated identifier-binding so the policy- rollout discipline must wait for the per-publisher per-message h= header-tag-coverage green-state baseline THIS page documents BEFORE committing the per- publisher per-domain p=reject tightening.
• BIMI explained — the PER-PUBLISHER-DKIM-SIGNING- DISCIPLINE-BEST-PRACTICE-GREEN-STATE- BASELINE-AS-LOAD-BEARING-PRECONDITION- OF-PER-PUBLISHER-PER-DOMAIN-BIMI- LOGO-PUBLICATION-ELIGIBILITY companion documenting the BIMI logo-publication mechanism (the per-publisher per- domain default._bimi.<domain> IN TXT "v=BIMI1; l=<logo-URL>; a=<VMC-URL>" publication discipline + the per- publisher per-domain SVG-Tiny-PS-logo publication at the l=-URL HTTPS endpoint + the per-publisher per-domain Verified Mark Certificate publication at the a=-URL HTTPS endpoint) whose per-publisher per-domain logo- display eligibility at every Gmail / Yahoo / Apple Mail / Fastmail BIMI- consuming receiver is GATED on per- publisher per-domain DMARC enforcement at p=quarantine or p=reject per BIMI draft §5 — and STRUCTURALLY DEPENDS on the per-publisher per-selector DKIM- signing-discipline green-state- baseline THIS page documents across four per-DKIM-best-practice-rule-vs- BIMI-logo-publication-coupling dimensions: (i) per-publisher- per-selector-2048-bit-RSA-or-Ed25519- key-size-discipline-as-load-bearing- per-publisher-per-domain-BIMI-eligibility- precondition — BIMI logo- display eligibility requires per- publisher per-domain DMARC enforcement at p=quarantine+, which requires per-publisher per-selector per-message DKIM-aligned-pass baseline; per-publisher per-selector cryptographic-key-size discipline (THIS page's 2048-bit RSA / Ed25519 floor) is the per-message DKIM- signature-cryptographic-integrity precondition every per-publisher per- domain DMARC-aligned-pass evidence- stream consumer (BIMI-consuming receivers included) materially depends on; per-publisher per- selector 1024-bit RSA / SHA-1 discipline drift collapses per- publisher per-message DKIM-signature validation at modern BIMI-consuming receivers, collapsing per-publisher per-domain DMARC enforcement eligibility, collapsing per-publisher per-domain BIMI logo-display eligibility; (ii) per- publisher-per-selector-DKIM-key- rotation-cadence-discipline-as-load- bearing-per-publisher-per-domain-BIMI- eligibility-continuity-precondition — per-publisher per-selector DKIM- key-rotation discipline (THIS page's 90-day rotation cadence) MUST NOT introduce per-publisher per-message DKIM-signature-validation-gap windows during the rotation transition; per-publisher per- selector key-rotation execution defects (premature private-key retirement before the new selector's TTL-windowed receiver-side cache warm-up, dual-selector-publication gap, public-key DNS-publication propagation-window mis-estimation) collapse per-publisher per-message DKIM-aligned-pass rate during the transition window, collapsing per- publisher per-domain DMARC-enforcement- baseline continuity, collapsing per- publisher per-domain BIMI logo- display continuity at every BIMI- consuming receiver; (iii) per- publisher-per-message-DKIM- canonicalization-and-h=-header-tag- coverage-discipline-as-load-bearing- per-publisher-per-domain-BIMI- eligibility-per-receiver-handler- compatibility-precondition — per-publisher per-message DKIM canonicalization choice (THIS page's c=relaxed/relaxed default) AND per-publisher per- message h= header-tag- coverage discipline (THIS page's signed-header inventory) directly determine per-publisher per-message per-forwarder-hop DKIM-signature- preservation robustness; per- publisher per-message forwarder-hop DKIM-signature-survival is per- publisher per-domain DMARC-aligned- pass continuity is per-publisher per- domain BIMI logo-display continuity; (iv) per-publisher-per- selector-private-key-custody- discipline-as-load-bearing-per- publisher-per-domain-VMC-issuance- TRUST-CHAIN-INTEGRITY-precondition — BIMI VMC (Verified Mark Certificate) issuance at the a=-URL endpoint requires per-publisher per-domain trademark registration verification AND per- publisher per-domain DMARC-enforcement baseline AND per-publisher per-domain DKIM-signing-discipline operational soundness; per-publisher per-selector private-key custody discipline THIS page documents (per-selector key- storage HSM discipline, per-selector key-rotation custodian discipline, per-selector key-revocation emergency-handling discipline) IS the per-publisher per-domain VMC- issuance trust-chain integrity precondition every Mark Verifying Authority (DigiCert / Entrust) audit of per-publisher per-domain DKIM- signing posture relies on. Read THIS page when ARCHITECTING per-publisher per-selector DKIM-signing-discipline best-practice rule-set; read the BIMI-explained spoke when SCOPING per-publisher per-domain BIMI logo- publication eligibility as the LOAD- BEARING DOWNSTREAM CONSUMER of the per-publisher per-selector DKIM- signing-discipline green-state- baseline THIS page documents.
• MTA-STS vs DANE — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-AUTHENTICATION- PUBLICATION-DISCIPLINE-CHOICE-AS-LOAD- BEARING-PEER-TRANSPORT-LAYER-BEST- PRACTICE companion to this DKIM-best- practices reference. Where THIS page documents the per-publisher per-selector DKIM-signing-discipline best-practice rule-set at the application layer (per- publisher per-selector RSA-2048 / Ed25519 key-size best-practice, per-publisher per-selector rsa-sha256 / ed25519-sha256 algorithm best-practice, per-publisher per-selector rotation-cadence best- practice, per-publisher per-domain signing-coverage best-practice for outbound mail-flow), the MTA-STS-vs- DANE spoke is the peer per-publisher per-domain transport-layer authentication- publication-discipline best-practice choice whose Web-PKI-anchored MTA-STS approach (per-publisher per-domain _mta-sts.<domain> TXT- RR pointer + HTTPS-served .well-known/mta-sts.txt policy-file two-leaf publication) and DNSSEC-anchored DANE approach (per-MX- host _25._tcp.<mx-host> TLSA-RR single-leaf publication) are the two peer transport-layer authentication- publication-discipline best-practice choices pairing operationally with the per-publisher per-selector DKIM-signing- discipline best-practice rule-set THIS page documents at FOUR per-best-practice coupling dimensions: (i) per- publisher per-domain cryptographic- publication-discipline-best-practice- coverage parallelism — the per-publisher per-selector DKIM- signing-discipline best-practice rule- set THIS page documents at the application layer pairs operationally with the per-publisher per-domain peer transport-layer authentication- publication-discipline best-practice choice the MTA-STS-vs-DANE spoke documents (Web-PKI-anchored MTA-STS or DNSSEC-anchored DANE) — together the two layers compose the per-publisher per-domain complete cryptographic- publication-discipline best-practice coverage every per-publisher per-domain DMARC-deployment programme requires; (ii) per-publisher per-domain cryptographic-trust-anchor-publication- layer best-practice choice parallelism — per-selector-DKIM-TXT-anchored vs Web-PKI-anchored vs DNSSEC-anchored cryptographic-trust-root publication best-practice choices — the per-publisher per-selector DKIM TXT-RR public-key publication best- practice rule-set THIS page documents at the per-selector cryptographic-trust- anchor publication layer pairs operationally with the per-publisher per-domain MTA-STS Web-PKI-anchored certificate-validation trust-root publication best-practice and the per- publisher per-domain DANE DNSSEC- anchored TLSA-RR trust-root publication best-practice the MTA-STS-vs-DANE spoke documents the three per-cryptographic- trust-anchor-publication-layer best- practice rationales of; (iii) per-publisher per-domain Bulk- Sender-Requirements-2024 cross-layer cryptographic-publication-discipline- best-practice composition — the per-publisher per-domain Feb-2024 Gmail/Yahoo Bulk Sender Requirements deliverability-floor composition explicitly requires the per- publisher per-selector DKIM-signing- discipline best-practice rule-set THIS page documents AND per-publisher per- domain transport-layer authentication- publication-discipline best-practice (MTA-STS or DANE) the MTA-STS-vs-DANE spoke documents the choice rationale of as paired cross-layer cryptographic- publication-discipline best-practice components of the per-publisher per- domain complete cross-layer authentication-and-encryption deliverability posture; (iv) per-publisher per-domain operator-side cryptographic-publication- discipline-best-practice operational- complexity-vs-trust-root-strength trade-off coordination — the per-publisher per-selector DKIM-signing-discipline best-practice rule-set THIS page documents (operational complexity at the per- selector rotation-overlap cadence and empty-p= revocation- publication best-practice) pairs operationally with the per-publisher per-domain MTA-STS-vs-DANE best- practice operational-complexity-vs- trust-root-strength trade-off the MTA- STS-vs-DANE spoke documents (MTA-STS Web-PKI-anchored two-leaf publication operational best-practice vs DANE DNSSEC-anchored TLSA-RR publication operational best-practice), and the per-publisher per-domain operator-side per-layer cryptographic-publication- discipline-best-practice operational- complexity coordination is the load- bearing per-layer best-practice operational rhythm BOTH protocols share at the per-publisher per-domain cryptographic-publication-discipline- best-practice composition boundary. Read THIS page when ARCHITECTING per- publisher per-selector DKIM-signing- discipline best-practice rule-set; read the MTA-STS-vs-DANE spoke when CHOOSING per-publisher per-domain peer transport-layer authentication- publication-discipline best-practice approach (Web-PKI-anchored MTA-STS or DNSSEC-anchored DANE) as the load- bearing peer cryptographic-publication- discipline-best-practice component of the per-publisher per-domain complete cross-layer authentication-and- encryption publication-discipline-best- practice posture.
• SPF for Google Workspace — the PER-PUBLISHER-PER-TENANT-PER- GOOGLE-WORKSPACE-OPERATOR-SPF-PUBLICATION- BEST-PRACTICE-AS-LOAD-BEARING-PEER- PROTOCOL-LAYER-PER-TENANT-PER-OPERATOR- PUBLICATION-BEST-PRACTICE companion to this DKIM-best-practices reference. Where THIS page documents the per-publisher per- selector DKIM-signing-discipline best- practice rule-set at the application layer (per-publisher per-selector RSA-2048 / Ed25519 key-size best-practice, per- publisher per-selector rsa-sha256 / ed25519-sha256 algorithm best-practice, per-publisher per-selector rotation-cadence best-practice, per-publisher per-domain signing-coverage best-practice for outbound mail-flow), the SPF-for-Google-Workspace spoke is the peer per-publisher per-tenant per-operator SPF publication best-practice rule-set whose per-Google-Workspace-tenant SPF publication best-practice rule-set (canonical v=spf1 include:_spf.google.com ~all SPF-record template, per-tenant supplemental third-party-ESP include-statement best- practice composition (include:sendgrid.net, include:_spf.mailgun.org), per-tenant cumulative 10-lookup-limit budget best-practice arithmetic, per- tenant zone-editor commit best-practice cadence) pairs operationally with the per- publisher per-selector DKIM-signing- discipline best-practice rule-set THIS page documents at FOUR per-protocol-pillar best-practice coupling dimensions: (i) peer per-publisher per-tenant per- operator cross-protocol-pillar cryptographic-publication-discipline-best- practice-coverage parallelism — the per-publisher per-selector DKIM-signing-discipline best-practice rule- set THIS page documents at the per- selector cryptographic-publication- discipline layer pairs operationally with the per-publisher per-tenant per-Google- Workspace-operator SPF publication best- practice rule-set the SPF-for-Google- Workspace spoke documents at the per- tenant per-operator Admin-Console DNS- publication layer — together the two per- protocol-pillar publication-best-practice rule-sets compose the per-publisher per- tenant per-operator complete cross- protocol-pillar authentication-publication- best-practice coverage every per-publisher per-tenant per-operator DMARC-deployment programme requires; (ii) per- publisher per-tenant per-Google-Workspace- operator canonical-include-statement-best- practice as per-tenant per-operator publication-best-practice primitive parallelism — the per- publisher per-selector DKIM-signing- discipline best-practice rule-set THIS page documents at the per-selector cryptographic- publication best-practice layer pairs operationally with the per-publisher per- tenant per-Google-Workspace-operator canonical include:_spf.google.com include-statement-best-practice the SPF- for-Google-Workspace spoke documents the per-tenant per-operator publication- rationale of — the per-publisher per-tenant per-Google-Workspace-operator canonical- include-statement-best-practice is the per- publisher per-tenant per-operator SPF- publication best-practice primitive whose publication-discipline-correctness pairs operationally with the per-publisher per- selector DKIM-signing-discipline best- practice rule-set THIS page documents at the per-publisher per-tenant per-operator cross-protocol-pillar publication-best- practice-composition boundary; (iii) per-publisher per-tenant per- operator Bulk-Sender-Requirements-2024 cross-protocol-pillar cryptographic- publication-discipline-best-practice composition — the per- publisher per-tenant per-operator Feb-2024 Gmail/Yahoo Bulk Sender Requirements deliverability-floor composition explicitly requires the per-publisher per-selector DKIM-signing-discipline best-practice rule- set THIS page documents AND per-publisher per-tenant per-operator SPF publication best-practice (per-tenant per-Google- Workspace-operator canonical include:_spf.google.com ~all publication with per-tenant supplemental third-party-ESP include-statement composition) the SPF-for-Google-Workspace spoke documents the per-tenant per-operator publication-rationale of as paired cross- protocol-pillar cryptographic-publication- discipline best-practice components of the per-publisher per-tenant per-operator complete cross-protocol-pillar authentication-and-deliverability posture; (iv) per-publisher per-tenant per- operator cumulative-10-lookup-limit-budget best-practice arithmetic as load-bearing per-tenant per-operator SPF-publication- best-practice constraint — the per-publisher per-selector DKIM- signing-discipline best-practice rule-set THIS page documents pairs operationally with the per-publisher per-tenant per- Google-Workspace-operator SPF-publication- best-practice cumulative-10-lookup-limit- budget arithmetic the SPF-for-Google- Workspace spoke documents (per-Google- Workspace-tenant canonical include:_spf.google.com consumes 4 DNS lookups, per-tenant supplemental third-party-ESP include- statements consume additional 1-3 DNS lookups each, per-tenant cumulative budget best-practice cap at 10 hard-ceiling), and the per-publisher per-tenant per-operator cross-protocol-pillar publication-best- practice coordination is the load-bearing per-tenant per-operator publication-best- practice rhythm BOTH protocols share at the per-publisher per-tenant per-operator cross-protocol-pillar publication-best- practice-composition boundary. Read THIS page when ARCHITECTING per-publisher per- selector DKIM-signing-discipline best- practice rule-set; read the SPF-for- Google-Workspace spoke when ARCHITECTING per-publisher per-Google-Workspace-tenant per-domain SPF publication best-practice rule-set whose per-tenant per-operator SPF publication best-practice pairs operationally with the per-publisher per- selector DKIM-signing-discipline best- practice rule-set THIS page documents at the per-publisher per-tenant per-operator cross-protocol-pillar publication-best- practice-composition boundary.
• BIMI Verified Mark Certificates — the per-publisher per-domain BIMI VMC issuance as downstream consumer of DKIM- signing-discipline best-practice companion to this per-publisher per-selector DKIM- signing-discipline best-practice reference. Where THIS page documents the per-publisher per-selector DKIM-signing-discipline best- practice rule-set (key-size, key-rotation, algorithm-choice, canonicalization-choice, selector-naming, header-set composition, Bulk-Sender-Requirements-2024 compliance), the BIMI-VMC spoke documents the downstream consumer of that best-practice rule-set — the per-publisher per-domain VMC-issuance- readiness gate at Mark Verifying Authorities STRUCTURALLY DEPENDS on sustained per- publisher per-selector DKIM-signing- discipline best-practice compliance as the LOAD-BEARING upstream cryptographic-publication- discipline-best-practice precondition. Four DKIM-BEST-PRACTICE-VS-BIMI-VMC-ISSUANCE- READINESS cross-correlation axes the BIMI- VMC spoke documents: (i) the per- publisher per-selector DKIM-key-size best- practice THIS page documents (RSA-2048 floor per Bulk-Sender-Requirements-2024) is the upstream cryptographic-strength precondition the Mark Verifying Authority issuance discipline evaluates for per-VMC issuance readiness — sustained per-publisher per- selector DKIM-key-size best-practice compliance is a per-VMC issuance-readiness gate criterion; (ii) the per-publisher per-selector DKIM-key-rotation cadence best-practice THIS page documents (per-quarter rotation cadence + rotation- overlap-window discipline) is the upstream cryptographic-rotation-discipline precondition the per-VMC certificate-renewal cadence couples with — per-VMC renewal cadence coordination with per-DKIM-selector rotation cadence is a per-publisher per-domain publication-discipline-best-practice rhythm; (iii) the per-publisher per-selector DKIM-algorithm-choice best-practice THIS page documents (rsa-sha256 + ed25519-sha256 dual-algorithm publication discipline) is the upstream cryptographic-algorithm-choice precondition the Mark Verifying Authority issuance discipline evaluates — sustained per-publisher per-selector best-practice algorithm-choice compliance is a per-VMC issuance-readiness gate criterion; (iv) the per-publisher per-selector DKIM-aligned-pass coverage-rate best-practice produced by THIS page's per-selector canonicalization + header-set composition discipline is the upstream DMARC-enforcement- baseline precondition the Mark Verifying Authority issuance discipline evaluates — Mark Verifying Authorities require demonstrated per-publisher per-domain p=quarantine-or- stronger DMARC-enforcement with sustained DKIM-aligned-pass coverage BEFORE issuing a Verified Mark Certificate. Read THIS page when ARCHITECTING per-publisher per-selector DKIM-signing-discipline best- practice rule-set; read the BIMI-VMC spoke when SHIPPING the per-publisher per-domain VMC issuance-readiness rollout whose Mark Verifying Authority issuance gate consumes the per-publisher per-selector DKIM-signing- discipline best-practice compliance THIS page documents.
• DMARC monitoring — the per-publisher per-domain DMARC- monitoring KPI dashboard as downstream consumer of per-publisher per-selector DKIM-signing-discipline best-practice companion to this DKIM-best-practices operator-reference. Where THIS page documents the per-publisher per-selector DKIM-signing-discipline best-practice rule-set (the RSA-2048 key-strength floor, the per-quarter rotation cadence with overlap-window discipline, the canonical c=relaxed/relaxed canonicalization-mode choice, the per-message DKIM-Signature header publication composition), the DMARC- monitoring spoke is the OPERATOR-CONSOLE REFERENCE documenting the per-publisher per-domain KPI dashboard whose per-day per-receiver per-source-IP DKIM-aligned- pass coverage-rate / per-selector signature-rotation-cadence pass-rate-vs- overlap-window stability / per-selector key-strength-vs-Bulk-Sender-Requirements- 2024 sustained-floor compliance telemetry the per-publisher per-domain operator MUST track to detect per-selector DKIM- signing-discipline-best-practice regression BEFORE it propagates into Gmail/Yahoo bulk-sender 5xx-rejection cliffs. Four DKIM-BEST-PRACTICE-AS- MONITORING-KPI-UPSTREAM-INPUT cross- correlation axes the monitoring spoke documents: (i) per-selector RSA-2048 key-strength publication- discipline as upstream determinant of monitoring-KPI sustained DKIM-aligned- pass coverage-rate — the per- selector RSA-2048 key-strength publication-discipline (vs the per-selector RSA-1024 weak-key regression that emits per-day per- receiver dkim-fail attribution at Gmail/Yahoo/Microsoft 365 receivers enforcing the Bulk-Sender-Requirements- 2024 cryptographic-strength floor) is the LOAD-BEARING upstream determinant of the monitoring-KPI sustained DKIM- aligned-pass coverage-rate baseline; (ii) per-selector rotation- cadence-vs-overlap-window discipline as upstream cause of monitoring-KPI pass- rate-cliff alarm — a per- selector rotation-without-overlap-window publication-discipline regression (retiring the prior selector's TXT-RR BEFORE in-flight signed mail has aged out of the per-receiver per-day signing- retention window) emits per-day per- receiver per-source-IP DKIM-fail cliffs the monitoring-KPI dashboard surfaces as the operator-side discipline- regression alarm; the DMARC-monitoring spoke documents the rotation-cadence-vs- overlap-window-vs-pass-rate-cliff attribution rule the per-publisher per- domain operator applies to distinguish rotation-discipline regression from per-day per-receiver per-source-IP legitimate-traffic-pattern shift; (iii) per-selector canonicalization- mode publication-discipline correctness as upstream input to monitoring-KPI per-receiver per-intermediary body- mutation attribution — the per- selector c=relaxed/relaxed canonical canonicalization-mode best- practice publication-discipline is the upstream input to the per-publisher per- domain monitoring-KPI per-receiver per- intermediary body-hash-mismatch attribution stream; the DMARC-monitoring spoke documents the per-day per-receiver body-hash-mismatch-vs-canonicalization- mode-choice attribution rule the per- publisher per-domain operator applies to distinguish per-intermediary footer- injection mutation from per-selector canonicalization-mode publication- discipline regression; (iv) per-publisher per-domain Bulk-Sender-Requirements-2024 cryptographic-publication-discipline floor compliance as function of per- message DKIM-aligned-signing coverage- rate baseline stability — the per-publisher per-domain Bulk-Sender- Requirements-2024 cryptographic- publication-discipline floor compliance structurally depends on per-day per- receiver per-source-IP DKIM-aligned- signing coverage-rate baseline stability; the DMARC-monitoring spoke documents the per-publisher per-domain coverage-rate-baseline-vs-bulk-sender- compliance readiness gate the per- publisher per-domain operator applies BEFORE advancing the per-domain bulk- sender cryptographic-discipline floor against the per-selector signing- discipline-best-practice regression budget. Pair this page (the per- publisher per-selector DKIM-signing- discipline best-practice rule-set) with the DMARC-monitoring spoke (the operator-side per-publisher per-domain KPI dashboard reference) when designing the per-publisher per-selector DKIM- signing-discipline-to-monitoring-KPI feedback loop — the spoke documents the per-day per-receiver per-source-IP DKIM-aligned-pass coverage-rate KPI panel whose telemetry is the operationally-grounded discipline- regression-detection stream every per- publisher per-selector DKIM-signing- discipline best-practice STRUCTURALLY FEEDS as the upstream per-publisher per-selector publication-discipline- correctness baseline.
• Email security glossary — the cluster-wide threat-and-defense vocabulary reference whose ~80 per-term DefinedTerm definitions name the threat- modelling vocabulary, replay-attack taxonomy, and defense-in-depth layer catalogue the per-publisher per-selector DKIM-signing-discipline best-practice rule-set THIS page documents structurally intersects with. Where THIS page documents the per-publisher per-selector DKIM- signing-discipline best-practice rule-set (RFC 6376 §3.3 algorithm choice rsa-sha256 vs ed25519-sha256, RFC 8463 ed25519-sha256 adoption guidance, RFC 6376 §3.4 canonicalization-mode choice c=relaxed/relaxed baseline, key-length choice 2048-bit RSA Bulk-Sender- Requirements-2024 floor, selector-rotation 90-180-day cadence, overlap-window rotation discipline), the email-security- glossary spoke is the THREAT-MODELLING- AND-DEFENSE-VOCABULARY reference documenting the per-attacker per- publication-discipline threat-class taxonomy the DKIM best-practice rule-set structurally counters. Four DKIM-BEST-PRACTICE-TO-THREAT- VOCABULARY coupling dimensions the security-glossary spoke documents: (i) DKIM replay-attack threat class as load-bearing per-publisher per- selector signing-discipline best-practice countermeasure — the DKIM replay-attack threat class the security glossary catalogues (per-attacker capture of a legitimate per-publisher DKIM-signed message and per-attacker replay to new recipient with attacker- controlled envelope) is the per-attacker per-publication-discipline residual the per-publisher per-selector signing- discipline best-practice rule-set THIS page documents structurally counters via the per-message x=-tag expiration ceiling, the per-message l=-tag length-restriction suppression, and the per-receiver verifier-side replay-detection heuristic; (ii) STRIDE / kill-chain / MITRE ATT&CK threat-modelling-framework vocabulary as per-publisher threat- model the DKIM best-practice rule-set participates in — the STRIDE (Spoofing, Tampering, Repudiation, Information disclosure, Denial of service, Elevation of privilege) / cyber-kill-chain / MITRE ATT&CK Initial-Access threat-modelling-framework vocabulary the security glossary catalogues is the per-publisher application-layer threat-model the DKIM- signing-discipline best-practice rule-set THIS page documents structurally participates in at the Spoofing-defense and Tampering-defense boundaries; (iii) defense-in-depth layer vocabulary as per-publisher per-protocol- pillar control-stack catalogue — the secure-email-gateway (SEG) / EDR / XDR / MDR / zero-trust / phishing- resistant-MFA / DLP defense-stack vocabulary the security glossary catalogues is the per-publisher cross- protocol-pillar control-stack catalogue whose per-layer DKIM-signing-discipline best-practice rule-set THIS page documents is one of the per-application- layer authentication-publication primitives; (iv) OSINT and reconnaissance vocabulary as per-attacker per-publisher per-selector reconnaissance-residual catalogue — the Certificate Transparency / DNS-passive-reconnaissance / Shodan / Censys OSINT vocabulary the security glossary catalogues is the per- attacker per-publisher per-selector reconnaissance-residual catalogue the per-publisher per-selector key-publication- discipline best-practice rule-set THIS page documents structurally exposes to (every published selector._domain key.<domain> TXT-RR is an attacker-side DNS-passive-reconnaissance enumeration target). Read THIS page when AUTHORING the per-publisher per-selector DKIM-signing-discipline best-practice rule-set; read the email-security- glossary spoke when CO-AUTHORING the per-publisher threat-and-defense vocabulary catalogue whose per-attack- class defender-side mitigation discipline the per-publisher per-selector DKIM-signing-discipline best-practice THIS page documents structurally counters.
• DMARC deployment checklist — the 4-PHASE-ROLLOUT-DISCIPLINE companion to this DKIM-best-practices 13-rule operator-discipline synthesis. Where THIS page documents the 13 production-deployment rules (Rule 1 sign-every-message, Rule 2 RSA-2048+ or Ed25519 algorithm choice, Rule 3 dual-selector zero-downtime rotation, Rule 4 per-purpose selector isolation, Rule 5 relaxed canonicalisation default, Rule 6 oversigning stable headers, Rule 7 annual rotation overlap, Rule 8 l= tag avoidance, Rule 9 t=y burn-in, Rule 10 t=s strict-domain-binding, Rule 11 multi- signature dual-algorithm hedging, Rule 12 selector-revocation-via-empty- p= discipline, Rule 13 post-rotation aggregate-report-validation), the DMARC-deployment-checklist spoke is the PHASE-2-TRIAGE-ALIGNMENT-FIXING- DISCIPLINE-CONSUMER companion documenting how the 13 DKIM-best- practice rules THIS page synthesises are CONSUMED at Phase 2 (Triage) of the 4-phase p=none → p=quarantine → p=reject rollout progression: Phase 1 (Discovery) publishes p=none with rua= and reads aggregate reports to inventory every legitimate sender; Phase 2 (Triage) drives each discovered sender to DMARC-aligned posture by applying THIS page's 13-rule DKIM discipline (turning on DKIM in the ESP control panel per Rule 1, choosing RSA-2048+/Ed25519 keys per Rule 2, configuring the per-purpose selector naming per Rule 4, ensuring c=relaxed/relaxed canonicalisation per Rule 5, oversigning stable headers per Rule 6 — every Phase-2 action item is a per-domain application of THIS page's 13-rule discipline). Phase 3 (Quarantine) advances to p=quarantine only after Phase 2's DKIM-discipline rollout has produced aggregate-report- confirmed DKIM-pass rates above the rollout exit threshold; Phase 4 (Enforcement) advances to p=reject only after Phase 3 confirms no false-positive quarantine of operator-controlled mail. The 4-phase progression is the operational sequencing discipline the 13-rule DKIM operator-discipline THIS page documents PLUGS INTO as the Phase-2 per-sender alignment- fixing primitive. Read THIS page when EXECUTING Phase 2's per-sender DKIM- alignment-fixing action items; read the DMARC-deployment-checklist spoke when AUTHORING the overall 4-phase rollout plan that sequences each Phase-2 application of THIS page's 13-rule DKIM discipline against the Phase-3 quarantine-promotion and Phase-4 enforcement-promotion exit criteria.
• SPF 10-DNS-lookup limit — the SPF-10-DNS-LOOKUP-CEILING-AS-LOAD- BEARING-DEPENDENCY-COMPLEMENT-WHOSE-VIOLATION- ELEVATES-DKIM-LEG-TO-SOLE-DMARC-PASS-PRECONDITION companion to this DKIM-best-practices 13-rule operator-discipline synthesis. Where THIS page documents the per-publisher per-domain DKIM cryptographic publication and operational discipline (RSA-2048-minimum key-size baseline per Feb 2024 bulk-sender requirements, dual- selector rotation-overlap-window discipline, per-publisher per-selector private-key custody- vs-ESP-delegation policy, rsa-sha256 vs ed25519- sha256 algorithm-choice decision matrix, organisational-domain-aligned d=-tag publication discipline, oversigning stable headers, c=relaxed/relaxed canonicalisation), the SPF-lookup-limit spoke is the SPF-SIDE- DEPENDENCY-COMPLEMENT companion documenting the RFC 7208 §4.6.4 10-DNS-lookup ceiling whose violation produces spf=permerror and STRUCTURALLY ELEVATES the DKIM-aligned-pass leg to the SOLE load-bearing DMARC-composite-pass precondition. The DKIM-best-practices-vs-SPF- lookup-limit relationship is parallel-leg- independence-as-resilience-substrate: RFC 7489 §4 alignment evaluation requires AT LEAST ONE of SPF-aligned-pass OR DKIM-aligned-pass for DMARC-composite-pass; when the publisher's SPF include-cascade exceeds the 10-lookup ceiling and produces spf=permerror, the DKIM-aligned-pass leg becomes SINGLE-POINT-OF- FAILURE load-bearing for the entire DMARC posture. Four DKIM-best-practices-vs-SPF-lookup-limit coupling dimensions matter at the per-publisher per-domain authentication-publication-discipline layer: (i) per-publisher per-selector DKIM- aligned-pass-rate floor as DMARC-composite-pass sole-load-bearing leg when SPF collapses — Rule 1 (RSA-2048 baseline) / Rule 5 (canonicalisation discipline) / Rule 6 (oversigning stable headers) / Rule 7 (dual-selector rotation overlap) directly determine whether the DKIM-aligned-pass leg survives forwarder hops, subject rewrites, and mailing-list expansions when SPF cannot recover from include-cascade-induced spf=permerror; (ii) per-publisher per-selector DKIM-aligned-pass- rate measurement against per-day per-receiver aggregate-report observability — when SPF collapses into spf=permerror, the per-publisher per-domain DKIM-aligned-pass-rate floor THIS page's 13-rule discipline architectures becomes the operationally-binding KPI for DMARC- composite-pass-rate continuity; (iii) per-publisher per-domain SPF-include-cascade flattening discipline as DKIM-discipline-resilience-amplifier — RFC 7208 §11.1.1 permerror treatment, SPF flattening to ip4: / ip6: literals, per-ESP include: consolidation, and per-zone v=spf1 TXT-record splitting across _spf.<domain> sub-zones all restore the SPF-aligned-pass leg so the DKIM- aligned-pass leg's 13-rule discipline is not single-point-of-failure load-bearing; (iv) per- publisher cumulative SPF include-cascade lookup- budget drift coordination with DKIM key-rotation cadence — supplier-ESP changes can silently push the publisher's SPF cumulative lookup count through the 10-budget ceiling between DKIM rotation windows, cascading into a per-receiver per-message DMARC-composite-fail that no amount of DKIM rotation-overlap discipline can rescue without parallel SPF include-cascade flattening. Read THIS page when AUTHORING the per-publisher per-domain DKIM cryptographic publication and operational discipline; read the SPF-lookup- limit spoke when AUDITING the per-publisher SPF include-cascade against the RFC 7208 §4.6.4 10-DNS-lookup budget so the SPF-aligned-pass leg is preserved as the parallel-leg-independent complement to the DKIM-aligned-pass leg THIS page's 13-rule discipline produces.
• TLS-RPT (SMTP TLS Reporting RFC 8460) explained — the PER-PUBLISHER-PER-DOMAIN- TRANSPORT-LAYER-OBSERVABILITY-PUBLICATION companion to THIS 13-rule DKIM operational- discipline reference. Where THIS page documents the per-publisher per-selector DKIM 13-rule operational hygiene catalogue (Rule 2 RSA ≥ 2048 / Ed25519, Rule 4 annual rotation with dual-selector overlap, Rule 5 c=relaxed/relaxed canonicalization, Rule 6 header-list signing discipline, Rule 8 NEVER use l=, Rule 9 24-72h t=y burn-in, Rule 11 multi-signature double-signing, Rule 13 DNS publication discipline) whose per- publisher per-selector observance preserves per-publisher per-domain DKIM-aligned-pass- rate floor, the TLS-RPT spoke is the PER- PUBLISHER-PER-DOMAIN-TRANSPORT-LAYER- OBSERVABILITY-PUBLICATION companion at FOUR per-DKIM-rule-vs-TLS-RPT-observability coupling dimensions: (i) per- publisher per-domain TLS-RPT transport- layer-observability stream AS structurally- complementary observability stream to per- publisher per-selector DKIM-aligned-pass- rate-floor application-layer observability stream — the per-publisher per-domain TLS-RPT JSON-aggregate-report per-MX-host per-day evidence-row stream the TLS-RPT spoke documents (per-publisher per- domain per-MX-host per-day per-failure- type-bucket evidence-row ingestion, per- publisher per-domain MTA-STS-policy- enforcement-failure-rate-floor observability, per-publisher per-domain DANE-TLSA-binding- validation-failure-rate-floor observability, per-publisher per-domain TLS-cipher-suite- negotiation-failure-rate-floor observability) IS the structurally-complementary transport- layer observability stream to the per- publisher per-domain DMARC RUA aggregate- report per-publisher per-selector DKIM- aligned-pass-rate-floor application-layer- observability stream the 13-rule DKIM operational discipline THIS page documents preserves; per-publisher per-domain operators monitor BOTH per-publisher per- domain observability streams at the per- publisher per-domain composite envelope- and-application-and-transport-layer observability-floor monitoring boundary; (ii) per-publisher per-selector Rule 4 annual rotation cadence IS verifiable via per-publisher per-domain TLS-RPT per- MX-host transport-layer-no-degradation observability stream — per- publisher per-selector Rule 4 annual rotation cadence with dual-selector overlap THIS page documents is verifiable per- publisher per-domain operationally via the per-publisher per-domain TLS-RPT per-MX- host per-day transport-layer-no-degradation observability stream the TLS-RPT spoke documents (per-publisher per-domain TLS- cipher-negotiation-baseline preservation during per-publisher per-selector DKIM key- rotation propagation windows, per-publisher per-domain MTA-STS-no-mode-flip stability during per-publisher per-selector DKIM-key- propagation window); per-publisher per- domain operators verify per-publisher per- selector DKIM key-rotation does NOT degrade per-publisher per-domain transport-layer cryptographic posture via baseline per-MX- host TLS-RPT evidence-row continuity at the per-publisher per-domain cross-protocol- layer publication-discipline coordination boundary; (iii) per-publisher per- domain TLS-RPT _smtp._tls.<d-domain> publication AS structurally-parallel transport-layer-publication-discipline counterpart to per-publisher per-selector DKIM <selector>._domainkey. <d-domain> publication discipline — the per- publisher per-domain TLS-RPT _smtp._tls.<d-domain> TXT-RR publication discipline the TLS-RPT spoke documents (per-publisher per-domain v=TLSRPTv1; rua=mailto:tls-rpt@ <d-domain> publication commitment, per-publisher per-domain per- organisation TLS-RPT-mailbox-ingest pipeline operational reliability discipline) IS the structurally-parallel per-publisher per- domain transport-layer-publication- discipline counterpart to the per-publisher per-selector DKIM <selector>._domainkey.<d- domain> TXT-RR publication discipline Rule 13 THIS page documents; per-publisher per-domain operators publish BOTH per-publisher per-domain transport- layer TLS-RPT publication and per-publisher per-selector application-layer DKIM publication coordinated at the per- publisher per-domain unified-DNS- publication-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 TLS-RPT transport- layer-observability publication discipline the TLS-RPT spoke documents IS the load- bearing transport-layer-observability leg of the per-publisher per-domain composite SPF + DKIM + DMARC + MTA-STS + TLS-RPT publication-floor coordination posture the per-publisher per-selector 13-rule DKIM operational discipline THIS page documents the application-layer-publication-and- cryptographic-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 13-rule DKIM operational- hygiene discipline; read the TLS-RPT spoke when AUDITING the per-publisher per-domain per-MX-host per-day transport-layer- observability stream whose per-publisher per-domain RFC 8460 JSON-aggregate-report ingestion discipline IS the load-bearing sibling per-publisher per-domain transport- layer-observability-publication discipline coordinated with the per-publisher per- selector DKIM application-layer-publication- and-operational-hygiene discipline THIS page documents.
• Email spoofing techniques and defenses — the seven-technique email-spoofing attack catalogue companion at four DKIM- operational-hygiene-rule vs spoofing- attack-class coupling dimensions.
• DMARC for Office 365 hybrid — the M365-hybrid deployment spoke covering the per-hybrid-tenant per-customer-domain topology where TWO independent DKIM-signing configurations must each independently satisfy the 13-rule DKIM operational-hygiene catalogue THIS page documents: (i) the on-prem Exchange- Edge-Transport operator-managed DKIM-signing key (operator-rotated, operator-published as a DNS-TXT-RR at the operator's authoritative server) and (ii) the EOP cloud-mailbox CNAME- delegated Microsoft-managed DKIM-signing key (Microsoft-rotated on six-month automatic cadence via selector1 / selector2 alternation). Read the hybrid-deployment spoke when applying the per- publisher per-selector DKIM operational- hygiene rules THIS page documents to a hybrid topology that demands per-tenant per-customer- domain rotation-cadence coordination across both independent signing paths to prevent cross-path stale-key-window exposure surfacing as per-receiver per-day DMARC-aligned-pass- rate dips on whichever path is currently mid-rotation.
• DMARC for Google Workspace
• BIMI SVG asset requirements — the BIMI SVG asset publication-discipline companion documenting the per-publisher per-domain BIMI SVG Tiny-PS 1.2 asset byte- grammar requirements (root baseProfile= "tiny-ps" attribute / square 1:1 aspect ratio / 32 KB compressed-size ceiling / no scripting or animation / no external resources / centered solid background) whose per-receiver-side per-mailbox-provider BIMI indicator-rendering eligibility cascade IS the load-bearing downstream consumer of the per-publisher per-selector DKIM operational- hygiene discipline THIS page documents at four DKIM-operational-hygiene-rule vs BIMI-indicator-rendering-eligibility coupling dimensions (per-publisher per-selector RSA-2048-bit key-strength floor + annual key-rotation cadence-floor drive per-publisher per-domain DKIM-aligned-pass-rate floor which IS the load-bearing precondition for the per-publisher per-domain DMARC-aligned- pass-rate floor that downstream-consuming BIMI indicator-rendering eligibility requires / per-publisher per-domain DMARC p= quarantine or p=reject enforcement-mode publication readiness depends on per-publisher per-selector DKIM operational-hygiene THIS page documents as the application-layer authentication-leg load-bearing precondition for the BIMI indicator-rendering-eligibility threshold the BIMI SVG asset publication-discipline targets / per-publisher per-stream selector- segmentation hygiene compresses per-receiver per-mailbox-provider per-stream DKIM-aligned- pass-rate floor variability driving per- receiver-side per-publisher BIMI indicator- rendering consistency across per-mailbox- provider rendering decision-cycles / per- publisher per-receiver `dkim=fail` verdict- cascade discipline preserves per-publisher per-domain composite DMARC-aligned-pass-rate floor against per-stream DKIM-operational- hygiene drift that would otherwise erode the BIMI indicator-rendering eligibility surface the BIMI SVG asset publication-discipline depends on at the per-publisher per-domain application-layer-and-brand-indicator- publication composite-discipline coordination boundary) — together the per-publisher per- selector DKIM 13-rule operational-hygiene discipline THIS page documents AND the per- publisher per-domain BIMI SVG asset publication-discipline compose the per- publisher per-domain composite application- layer-authentication-and-brand-indicator- publication coordination floor.
• DMARC for shared-hosting providers — the per-hosting-provider per-customer- domain DKIM-publication-at-scale-vs-DMARC-ramp coordination companion to this DKIM best- practices pillar. Where THIS page documents the per-publisher per-selector DKIM publication-discipline (the a=rsa-sha256 per RFC 8301 / a=ed25519-sha256 per RFC 8463 signature-algorithm choice, the c=relaxed/relaxed body- canonicalization, the dual-selector overlap- rollover key-rotation cadence, the retirement- pass cleanup discipline), the shared-hosting spoke documents the per-hosting-provider per- customer-domain at-scale publication-discipline the per-customer-domain DMARC ramp consumes. Four coupling axes connect them: (i) per- hosting-provider per-customer-domain DKIM- key-pair generation + DNS publication infrastructure (e.g. cPanel WHM / Plesk auto- provisioning a per-customer-domain default._domainkey.<customer-domain> TXT-RR + outbound-MTA per-customer DKIM- signer registration) MUST scale across thousands of per-customer-domain publications without contaminating the per-hosting-provider per-customer-domain DKIM-aligned-pass-rate floor; (ii) per-hosting-provider per-customer- domain dual-selector overlap-rollover key- rotation cadence MUST coordinate against the per-hosting-provider shared outbound-MTA infrastructure such that per-customer-domain DKIM-aligned-pass-rate floor is preserved through hosting-provider-initiated infrastructure rotations (e.g. outbound-MTA migration, IP-pool rebalancing) without per-customer-domain operator intervention; (iii) per-hosting-provider per-customer- domain DKIM-key-strength floor RSA-2048 minimum per RFC 8301 + Ed25519 dual-algorithm per RFC 8463 §5 IS pre-condition for per- customer-domain BIMI eligibility + 2024 Bulk-Sender-Requirements composite floor satisfaction at hosting-provider scale; (iv) per-hosting-provider per-customer-domain per-stream subdomain isolation (mail.<customer-domain> for hosting-provider-relayed outbound vs apex- domain for customer-direct outbound) under adkim=s strict-mode identifier- alignment prevents per-stream verdict contamination of the per-customer-domain DMARC composite-verdict at the hosting- provider multi-tenant egress boundary. Read the shared-hosting spoke alongside this DKIM best-practices pillar when AUTHORING per- hosting-provider per-customer-domain DKIM- publication infrastructure, when AUDITING per-customer-domain DKIM-aligned-pass-rate floor across the hosting-provider tenant portfolio, or when PLANNING per-customer- domain DMARC enforcement-mode ramp p=none → p=quarantine → p=reject progression where the per-customer-domain DKIM-aligned-pass-rate floor IS gated by per-hosting-provider per-customer-domain DKIM-publication infrastructure hygiene.
• DMARC reporting pipeline — the PER-PUBLISHER-PER-DOMAIN-DMARC-RUA- AGGREGATE-REPORT-PIPELINE-AS-PER-PUBLISHER- PER-DOMAIN-RECEIVER-EMITTED-EVIDENCE-STREAM- SURFACING-PER-PUBLISHER-PER-SELECTOR-DKIM- BEST-PRACTICES-DRIFT-CLOSURE-VISIBILITY companion at four DKIM-best-practices-vs- DMARC-RUA-aggregate-report-pipeline coupling dimensions: (1) per-publisher per-selector DKIM-aligned-pass attribution surfaces per- receiver per-day per-source-IP per-row <auth_results><dkim> + <policy_evaluated><dkim> attribution per RFC 7489 §6.6.2 in the DMARC RUA XML-aggregate-report pipeline — without per-publisher per-selector DKIM best-practices discipline (selector segregation, zero-downtime rotation, key-size floor per RFC 8301 §3.1) the per-row DKIM-aligned-pass attribution stream collapses below the per-publisher per-domain DKIM-aligned-pass-rate floor; (2) per-publisher per-selector DKIM key-rotation operational discipline drives per-publisher per-domain DKIM-aligned-pass- rate floor stability whose preservation across rotation events IS the per-publisher per-domain DMARC composite-aligned-pass- rate floor stability precondition the per- publisher per-domain DMARC enforcement-mode ramp p=none → p=quarantine → p=reject progression decision THIS DKIM-best- practices page documents the per-publisher per-selector key-rotation cadence-discipline of structurally depends on consuming the DMARC RUA aggregate-report-pipeline per-day per-receiver evidence stream the reporting- pipeline spoke documents; (3) per-publisher per-selector DKIM best-practices discipline gate per-publisher per-domain DKIM-aligned- pass-rate floor surfaced via per-receiver per-day DMARC RUA aggregate-report <policy_evaluated><dkim>pass|fail</dkim> attribution per RFC 7489 §6.6.1 — the DMARC RUA aggregate-report-pipeline IS the per-publisher per-domain operator- actionable evidence-channel through which DKIM best-practices drift surfaces; (4) per-publisher per-selector DKIM-aligned- pass attribution per-receiver per-day per- source-IP per-row evidence surfaces per- message DKIM-Signature verification outcome stream feeding per-publisher per- domain DKIM-aligned-pass-rate floor preservation against per-stream forwarder- rewrite-cascade collapse the per-publisher per-selector DKIM best-practices discipline THIS page documents the per-publisher per- selector operational-discipline of structurally cascades into through the DMARC RUA aggregate-report-pipeline.
• DMARC alignment — the per-publisher per-domain application-layer composite-verdict alignment-evaluation reference per RFC 7489 §3.1.1 covering relaxed-vs-strict alignment-mode publication-decision for both per-message DKIM-Signature d=-domain alignment with the RFC 5322 From organisational-domain AND envelope-MAIL-FROM SPF-authenticated-domain alignment with the RFC 5322 From organisational-domain. Rule 8 (single DKIM-Signature with d= aligned to RFC 5322 From) and Rule 11 (per-source- IP dkim=pass-rate monitoring via aggregate- report ingestion) THIS DKIM-best-practices synthesis documents the per-publisher per- selector operational-discipline of operationally consume the per-publisher per-domain DMARC alignment-evaluation engine — without the alignment-engine evaluating whether the per-message DKIM- Signature d=-domain aligns with the RFC 5322 From organisational- domain per RFC 7489 §3.1.1 alignment- mode publication-decision, the per-publisher per-selector DKIM-aligned-pass-rate floor that Rule 11 monitors cannot be computed at the per-receiver per-message verdict- attribution boundary, and the per-publisher per-selector DKIM operator-discipline THIS page documents collapses into a cryptographic-signature-only floor that no longer feeds the per-publisher per-domain composite-verdict aligned-pass disjunction every per-publisher per-domain DMARC enforcement-mode ramp gates on. Read the DMARC alignment spoke when AUTHORING per- publisher per-selector DKIM d=- domain publication discipline at deployment, when AUDITING per-publisher per-selector DKIM-aligned-pass-rate floor regression against per-receiver per-day aggregate- report attribution, or when PLANNING per- publisher per-domain DMARC enforcement-mode ramp sequencing against per-publisher per- selector DKIM-aligned-pass-rate floor- readiness preservation discipline.
• include vs ip4 vs a vs mx — the SPF-mechanism-selection companion to this DKIM best-practices guide. Just as the DKIM hygiene this page documents (key length, selector rotation, canonicalization choice) keeps the application-layer signing posture sound, SPF lookup-budget hygiene keeps the envelope-layer authorization posture sound: chained include: references silently consume the RFC 7208 §4.6.4 ten-DNS-lookup budget and tip a domain into spf=permerror, so flattening include: / a / mx into explicit ip4: ranges is the SPF-side analogue of the DNS-record discipline this page teaches. Read the mechanism-selection spoke when budgeting the SPF lookup count alongside the DKIM record hygiene.
• DMARC policy modes (p=none / p=quarantine / p=reject) — the enforcement-ramp companion to this DKIM best-practices guide. The key-length, selector-rotation, and canonicalization discipline this page teaches exists to keep the DKIM-aligned-pass leg solid enough that you can advance the DMARC policy from p=none through p=quarantine to p=reject without quarantining legitimate mail. Read the policy-modes spoke for the evidence-driven ramp the DKIM hygiene here ultimately serves.
• DMARC for Microsoft 365 — the provider-specific deployment companion. The key-length, selector-rotation, and canonicalization discipline this page teaches maps onto a Microsoft 365 / Exchange Online tenant through the built-in selector1/selector2 CNAME signing and custom-domain DKIM the M365 guide walks through. Read it to apply this best-practices hygiene on an Exchange Online domain on the way to p=reject.
• Email authentication explained — the umbrella overview that places the DKIM key-length, selector-rotation, and canonicalization hygiene this page teaches inside the full SPF + DKIM + DMARC stack. DKIM is one of the three pillars; the email-authentication primer shows how a healthy DKIM signature combines with SPF and DMARC alignment to earn the aligned pass that policy enforcement acts on. Read it for the big picture this best-practices guide drills into a single pillar of.
• DANE explained (DNSSEC-anchored transport-layer authentication) — the best practices THIS page catalogues harden the message-layer DKIM signature whose public key is published as a DNS TXT record; DANE (RFC 7672 SMTP-over-TLSA + RFC 6698) publishes a complementary transport-layer cryptographic binding — a DNSSEC-signed TLSA record that pins the receiving MX's TLS certificate so STARTTLS to your domain cannot be silently downgraded or MITM'd. The two are parallel DNS-published cryptographic controls operating at different layers: message authentication vs. channel authentication. Read it to round out the cryptographic posture beyond the signing-key hygiene this guide drills into.
• 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.

Audit your DKIM deployment now

DMARC Analyzer ingests every aggregate report and surfaces the per-selector verdict distribution in the dashboard — the most efficient surface for executing Rule 11 (monitoring) and Rule 15 (quarterly audit) of this best-practices checklist.

Sign up — Free plan Audit my DKIM selectors