# DomainKeys vs DKIM: What's the difference? > DomainKeys is a Historic email-signing protocol; DKIM is the current Internet Standard used by DMARC. Compare their headers, DNS keys, and migration path. DomainKeys and DKIM are related but not interchangeable. DomainKeys is the Historic protocol in RFC 4870 and became obsolete through early DKIM work. It uses `DomainKey-Signature`. DKIM is the current Internet Standard in RFC 6376, with later updates, and uses `DKIM-Signature`. Both retrieve selector-based public keys below `_domainkey`, but their signature fields and verification rules differ. DMARC evaluates aligned DKIM, not a legacy DomainKeys result. For a new or modernized sender, implement DKIM and retire DomainKeys only after production evidence shows nothing still uses it. ## Quick takeaways - DomainKeys is a Historic and obsolete protocol; DKIM is Internet Standard STD 76. - DomainKeys uses `DomainKey-Signature`, while DKIM uses `DKIM-Signature`. - Both use selectors and `_domainkey`, but their record and verification rules are not interchangeable. - Current DKIM algorithm requirements include updates published after RFC 6376. - DMARC uses an aligned DKIM pass, not a legacy DomainKeys result. ## Who is affected? DomainKeys now appears mainly in old documentation, inherited mail appliances, dormant DNS records, archived messages, or a legacy application that has not moved to DKIM. Administrators building a new sender should configure DKIM. The cleanup risk is straightforward: deleting a public key while an old system is still creating `DomainKey-Signature` headers leaves those messages without the key needed for DomainKeys verification. The right migration proves current use before removing old signing code or DNS records. Use the message evidence to keep the layers separate. [SPF](/learning/what-is-spf) authorizes an SMTP identity, [DKIM](/learning/what-is-dkim) verifies a signing domain, and [DMARC](/learning/what-is-dmarc) checks alignment with the visible From domain. ## What are the requirements? [RFC 4870](https://www.rfc-editor.org/info/rfc4870/) documents DomainKeys and is marked Historic and obsolete by the RFC Editor. The protocol adds a `DomainKey-Signature` header, identifies a selector, and retrieves a public key from DNS below `_domainkey`. [RFC 6376](https://www.rfc-editor.org/info/rfc6376/) defines DKIM as Internet Standard STD 76. A `DKIM-Signature` identifies a signing domain in `d=`, a selector in `s=`, signed headers in `h=`, a body hash in `bh=`, signature data in `b=`, and canonicalization in `c=` when that optional tag is present. DKIM also separates the signing domain from the message's purported author. A valid signature establishes responsibility by the signing domain for the signed content. It does not, on its own, say that the signing domain aligns with the visible From domain or that the receiver trusts the message. The original RFC 6376 algorithm text has later updates. [RFC 8301](https://www.rfc-editor.org/info/rfc8301/) makes `rsa-sha1` Historic and requires `rsa-sha256` for RSA DKIM signing and verification. [RFC 8463](https://www.rfc-editor.org/info/rfc8463/) adds `ed25519-sha256`. Follow the current specification and the sending provider's supported setup rather than copying algorithm advice from an old DomainKeys guide. Similar DNS names can suggest interchangeability because both protocols use a selector below `_domainkey`, but the records are protocol-specific. The signature header tells the verifier which protocol to process, and the verifier applies that protocol's key-record and signature rules. A `DomainKey-Signature` header is not an alias for `DKIM-Signature`. Under [RFC 9989](https://www.rfc-editor.org/info/rfc9989/), the signing path to DMARC pass requires a valid DKIM result whose authenticated signing domain aligns with the visible From domain. A DomainKeys-only result does not provide that DKIM path. ## When does the requirement take effect? RFC 4870 was published as Historic in May 2007 and is now listed as obsolete. RFC 6376 is the current DKIM Internet Standard, with the RFC Editor listing later updates. For a new deployment, use DKIM now. A legacy sender has no universal retirement date, but keeping DomainKeys indefinitely is not a migration plan. Set a transition window that covers low-frequency senders, verify the complete route inventory, and remove the old protocol only when the evidence is clean. ## How do I implement the requirement? ### 1. Identify the signature that is actually present Collect full headers from every sending route. Search separately for `DomainKey-Signature` and `DKIM-Signature`, then record the application, signing domain, selector, and message class behind each sample. ### 2. Map selectors to systems and owners Query each selector below `_domainkey` and compare the result with mail-server or provider configuration. Record who owns the private key, where signing occurs, and which DNS record is still required. ### 3. Enable current DKIM on every route Use the provider's current DKIM setup or a controlled signing service. Keep private keys on the signer, publish only the public key material, and follow current algorithm and key requirements supported by the route. ### 4. Confirm DMARC alignment Verify that at least one passing `d=` domain aligns with the visible From domain under the intended alignment mode. If SPF provides the temporary aligned path during migration, keep it monitored until DKIM is working consistently. ### 5. Retire DomainKeys after observation Search a complete sending cycle, including infrequent jobs, for `DomainKey-Signature`. Disable legacy signing first, watch for failures, and then remove obsolete DNS records through a documented change with rollback ownership. ## How do I validate compliance? Send a message through every production route. Confirm that `DKIM-Signature` is present, the selector resolves to the intended public key, the signature verifies, and a trusted receiver records `dkim=pass` in `Authentication-Results`. Validate DMARC separately. Compare the DKIM `d=` domain with the visible From domain and confirm the expected alignment mode. A cryptographically valid but unaligned DKIM signature does not satisfy the DKIM path for DMARC. Search recent production samples for `DomainKey-Signature`, including seasonal and low-volume systems. When the inventory is clean, use Palisade's [DKIM checker](/tools/dkim) to confirm the intended public selector remains reachable after cleanup. ## Make SPF, DKIM, and DMARC easier to manage Palisade's [DMARC Agent](https://docs.palisade.email/guides/fixing-authentication-issues/) turns report data into a prioritized list of sender, SPF, DKIM, and DMARC issues. Your team can see what to fix next and follow a guided path toward stronger authentication and DMARC enforcement. Stronger authentication helps protect your domains and supports better email deliverability. [start a Palisade account](https://app.palisade.email/signup?utm_source=palisade_learning&utm_medium=article&utm_campaign=domainkeys_vs_dkim&utm_content=domainkeys_vs_dkim). ## Frequently asked questions ### Is DomainKeys the same as a DKIM domain key? No. DomainKeys is a Historic protocol. A DKIM public key belongs to the current DKIM protocol even though the names are similar. ### Did DKIM simply rename the signature header? No. DKIM has its own signature fields, canonicalization, hashing, key-record rules, and verification model. The two headers are not interchangeable. ### Should I keep old DomainKeys selectors in DNS? Only during a documented legacy transition. Remove them after the complete sender inventory shows that no authorized production route still depends on DomainKeys. ### Can DomainKeys make DMARC pass? No. DMARC's signing path requires a passing and aligned DKIM result. ### Why do both protocols use `_domainkey`? The shared label reflects their historical relationship and selector-based DNS key publication. Current verification still follows the protocol named by the signature header.