DomainKeys vs DKIM: What's the difference?

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 authorizes an SMTP identity, DKIM verifies a signing domain, and DMARC checks alignment with the visible From domain.

What are the requirements?

RFC 4870 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 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 makes rsa-sha1 Historic and requires rsa-sha256 for RSA DKIM signing and verification. RFC 8463 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, 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 to confirm the intended public selector remains reachable after cleanup.

Make SPF, DKIM, and DMARC easier to manage

Palisade's DMARC Agent 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.