What this RFC defines
RFC 5863 is an operational guide for deploying DKIM in production environments. It covers key management, selector naming conventions, DNS record publication, key rotation schedules, monitoring for signature failures, and troubleshooting common DKIM deployment issues.
Where you see it in practice
When you set up DKIM for a new sending domain and choose a selector name like mail._domainkey.yourdomain.com, the selector naming conventions come from guidance in RFC 5863. Key rotation best practices (rotating keys every 6-12 months, keeping old selectors active during the transition period) are the kind of operational guidance this RFC provides. It is the practitioner’s companion to the technical specification in RFC 6376.
How it connects to other RFCs
RFC 5863 is an informational companion to RFC 6376 (DKIM core specification). It references RFC 6376 throughout and provides the operational context that the specification document does not cover. It works alongside RFC 7489 (DMARC) and RFC 5321 (SMTP) as part of the broader authentication deployment picture.
Current status
RFC 5863 is a current informational RFC, published April 2010. Key rotation, selector management, and monitoring practices documented here have become industry standard for any organisation deploying DKIM.
Operational guidance for DKIM
RFC 5863 is an informational document published in May 2010 that describes deployment and operational best practices for DKIM. Unlike the protocol standards (RFC 4871, later RFC 6376), it is not a specification of the wire format; it is guidance on how to run DKIM in production. Topics include key management (rotation, size, algorithm choice), selector naming conventions, canonicalization choices (relaxed versus simple), and handling of forwarded or mailing-list-modified messages.
Key rotation guidance
RFC 5863 recommends that DKIM keys be rotated periodically to limit the damage from key compromise. The typical rotation cycle is 6-12 months for high-volume senders, with a graceful transition period during which both old and new selectors are published. The old selector should be kept live long enough for in-flight messages signed with the old key to be verified after delivery delays; typically 30-90 days. This is why domains often have multiple _domainkey TXT records visible simultaneously.
Practical takeaways still relevant
Two RFC 5863 recommendations remain critical in 2026. First, use relaxed body canonicalization by default; simple canonicalization breaks on nearly any mailing list or forwarding. Second, use RSA-SHA256 for signatures; SHA1 is deprecated and the ed25519 algorithm added by RFC 8463 is a modern alternative worth considering. Key sizes should be 2048 bits minimum; 1024-bit keys are still accepted by most verifiers but should be rotated to 2048 or higher. Sites using 512-bit keys are trivially compromised and should upgrade immediately.
RFC 5863 (May 2010) provides DKIM Deployment, Operations, and Considerations guidance: not a protocol specification but operational best practices for deploying DKIM effectively. Covers key selection and rotation, selector strategy, canonicalization choice, forwarding and mailing list challenges, monitoring, and troubleshooting. Complements the DKIM specification with real-world deployment wisdom accumulated in the years after DKIM was standardized. Informational document; the authoritative wire spec remains RFC 6376 (updated by RFC 8301 and RFC 8463).
RFC 5863 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Operational guidance for DKIM deployment |
| Type | Informational (not a wire spec) |
| Companion | RFC 6376 DKIM specification (updated by RFC 8301, RFC 8463) |
| Topics covered | Key rotation, selector strategy, canonicalization, forwarding, mailing list issues, monitoring |
| Published | May 2010 |
Key management guidance
| Aspect | Recommendation |
|---|---|
| Minimum key size | 2048 bits (RFC 8301 makes this the standard) |
| Rotation frequency | Every 6-12 months for signing keys; verifier caches persist for TTL |
| Selector naming | Include date or version (s2026a, marketing-202607) for tracking |
| Multiple selectors | Standard practice: current selector + previous selector active for grace period |
| Third-party signing | ESP-specific selectors on ESP-controlled subdomain via CNAME delegation |
| Key retirement | Keep old key TXT record for at least the last-sent-with-it plus DKIM verifier cache (typically 30 days) |
Canonicalization choice
| Mode | Behavior | Trade-off |
|---|---|---|
simple/simple | Header and body: no normalization | Strictest; breaks on any whitespace change; rarely used |
relaxed/simple | Header: normalize whitespace and case; body: strict | Common; tolerates header rewrapping but not body changes |
simple/relaxed | Header: strict; body: normalize trailing whitespace | Rare choice |
relaxed/relaxed | Both: normalize whitespace and case | Most tolerant; survives common transit modifications; recommended |
Forwarding and mailing list handling
Common DKIM operational mistakes
d= for DMARC alignment. DKIM’s d= (signing domain) must align with From header domain for DMARC pass. Signing with ESP’s domain does not align; the From header shows sender.com but DKIM d=esp.com. Solution: CNAME delegation so ESP signs with a selector on sender.com’s DNS, giving d=sender.com signature aligned with From.Related standards and further reading
- DKIM Record Setup Guide: DNS configuration
- Free DKIM Record Checker: validate public key
Frequently asked questions
Should I use 2048 or 4096 bit RSA keys for DKIM?
2048 is standard per RFC 8301. 4096 provides marginal additional security at cost of larger DNS TXT records (which some DNS providers or verifiers occasionally handle poorly at very large sizes). Ed25519 (RFC 8463) is a modern alternative with much smaller keys and signatures; adoption is uneven but growing. 2048-bit RSA is the safe universal choice; consider Ed25519 as it gains support.
How often should I rotate DKIM keys?
Every 6-12 months for signing keys. Rotation limits the window in which a compromised key can be misused. Rotation is not disruptive: publish new selector, wait for DNS propagation (typically minutes), switch signing to new selector, keep old selector’s DNS record for 30 days for verifier caches, then retire. Automated key rotation is available in modern deployments.
What canonicalization should I use?
relaxed/relaxed for most cases. Tolerates whitespace normalization by intermediaries (rewrapping headers, trailing whitespace changes on body) while still detecting substantive modifications. Simple modes break on legitimate transit changes and are rarely worth the strictness.
How do I handle third-party ESPs signing with my domain?
CNAME delegation. Publish a CNAME at selector._domainkey.yourdomain.com pointing to the ESP’s key domain (selector.dkim.esp.com). The ESP controls the private key; verifiers see d=yourdomain.com in the signature because they look up the public key via your DNS. Result: DKIM aligns with From header domain, satisfying DMARC. Every major ESP supports this pattern.
How do I monitor whether my DKIM is working?
DMARC aggregate reports (rua= address in your DMARC record). Reports include DKIM pass/fail statistics per sending IP. Set up DMARC with rua=mailto:dmarc-reports@yourdomain.com, monitor daily. Free tools: Google Postmaster Tools (for Gmail delivery data), dmarcian, Postmark’s DMARC digest, mailhardener. Third-party services parse aggregate reports and surface trends.
About the Author
Alaa · LinkedIn
Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.
About SMTPedia
SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.
We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.
