What this RFC defined
RFC 4871 defined the original DKIM specification, the cryptographic email signing standard that allows receiving servers to verify that a message was sent by an authorised mail server for the signing domain. It established the DKIM-Signature header format and the DNS key publication mechanism (_domainkey TXT records) that remain in use today.
Where you would have seen it in practice
All existing DKIM deployments, whether set up under RFC 4871 or RFC 6376, use the same DKIM-Signature header format and the same DNS key record syntax. The two RFCs are functionally compatible on the wire. RFC 4871 established the standard that made DKIM the dominant email authentication mechanism, deployed by Gmail, Yahoo, and major ESPs from 2007 onwards.
How it connects to other RFCs
RFC 4871 was obsoleted by RFC 6376 in 2011. RFC 6376 clarified ambiguous sections around header canonicalisation and signature verification without changing the wire format, so existing DKIM signatures and keys work identically under both specifications. RFC 5863 provides operational guidance applicable to deployments under both RFCs.
Current status
RFC 4871 was obsoleted by RFC 6376 in September 2011. New DKIM implementations should reference RFC 6376. All existing DKIM deployments continue to function correctly since RFC 6376 is backward-compatible. The DKIM-Signature format and DNS key record structure are identical in both RFCs.
The first DKIM standard
RFC 4871 was the first published DKIM standard in May 2007, combining the earlier DomainKeys (Yahoo) and Identified Internet Mail (Cisco) proposals. It defined the DKIM-Signature header (with fields v, a, c, d, s, b, bh, h, and others), the DNS TXT record format for publishing public keys (selector._domainkey.example.com), and the canonicalization algorithms (simple, relaxed) that determine how headers and body are normalized before signing. Every DKIM implementation since 2007 traces its behavior to this document.
Superseded by RFC 6376
RFC 4871 was obsoleted by RFC 6376 in September 2011. RFC 6376 integrated errata and clarifications from four years of operational experience but did not change the wire format; a signature generated by an RFC 4871 implementation is still valid under RFC 6376 and vice versa. If your DKIM library or MTA references RFC 4871, it is not broken. New implementation work should target RFC 6376 as the current authority.
Common signing errors
Two errors from RFC 4871 era still recur. First, some MTAs use relaxed body canonicalization but write signatures for the pre-canonicalization body, producing signatures that fail verification at any strict verifier. Second, some MTAs sign headers that are then modified downstream (typically by mailing lists that rewrite Subject or List-headers), producing DKIM failures at the final destination. Both problems predate the RFC 6376 update but continue to affect certain workflows. Mailing list authentication solutions like ARC (RFC 8617) were developed specifically to address the second problem.
RFC 4871 (May 2007) was the original DKIM (DomainKeys Identified Mail) specification. Defined the DKIM-Signature header, DNS key publication format, canonicalization modes, and signature verification. Obsoleted by RFC 6376 in September 2011. Reference RFC 6376 for current DKIM implementation. RFC 4871 remains historically relevant: it merged Yahoo’s DomainKeys and Cisco’s Identified Internet Mail into the unified DKIM standard, and set the technical foundation still used today.
RFC 4871 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Original DKIM specification |
| Status | Obsolete (superseded by RFC 6376) |
| Origin | Merger of Yahoo DomainKeys and Cisco Identified Internet Mail |
| Core mechanism | DNS-published public key, message signed by matching private key |
| Header | DKIM-Signature with v/a/c/d/s/t/bh/h/b tags |
| Published | May 2007 |
| Superseded by | RFC 6376 (September 2011) |
Changes from RFC 4871 to RFC 6376
| Aspect | RFC 4871 (2007) | RFC 6376 (2011) |
|---|---|---|
| DKIM-Signature syntax | Same tags | Same tags |
| Canonicalization | simple/simple, simple/relaxed, relaxed/simple, relaxed/relaxed | Identical |
| Body hash format | Base64 | Base64 |
| Verifier behavior | Some ambiguities around header handling | Clarified for edge cases |
| Errata | Reported separately | Integrated into main text |
l tag security guidance | SHOULD NOT use | Same (later hardened by RFC 8301) |
| Update by RFC 8301 | N/A | Crypto agility: deprecates SHA-1 and short keys |
| Update by RFC 8463 | N/A | Ed25519 algorithm support |
Common mistakes when DKIM configuration references RFC 4871
a=rsa-sha1) but deprecated by RFC 8301 (2018). Modern receivers ignore or downgrade SHA-1 signatures. Fix: sign with a=rsa-sha256. Legacy DKIM configurations from the RFC 4871 era occasionally still use SHA-1; audit and rotate to SHA-256.l tag. Both RFC 4871 and RFC 6376 mark l as SHOULD NOT use because it enables body-append attacks (attacker can add content past the signed length). RFC 8301 elevates to MUST NOT. Never enable l; sign the entire body.d= for DMARC alignment. The d= in DKIM-Signature must match (or be a parent of, in relaxed alignment) the From header domain for DMARC to consider the DKIM verdict aligned. Signing with your ESP’s domain does not produce alignment; use CNAME-based key delegation so the signature uses your own domain.Related standards and further reading
- DKIM Record Setup Guide: current syntax and patterns
- Free DKIM Record Checker: validate your public key
- Authentication-Results Header: reading DKIM verdicts
Frequently asked questions
Is RFC 4871 still relevant in 2026?
Only for historical context. RFC 4871 was superseded by RFC 6376 in September 2011, with further updates via RFC 8301 (2018) and RFC 8463 (2018). Current DKIM implementations reference RFC 6376; legacy configurations may still exist referencing 4871. Modernize by rotating keys to 2048-bit RSA with SHA-256, considering Ed25519 for future-proofing.
What is the difference between DomainKeys and DKIM?
DomainKeys was Yahoo’s original 2004 proposal for cryptographic email authentication. Identified Internet Mail (IIM) was Cisco’s contemporary alternative. RFC 4871 merged them into DKIM as the unified IETF standard. Legacy DomainKeys headers (DomainKey-Signature) can still be found in older deployments; modern DKIM (DKIM-Signature) is the replacement. New implementations should use DKIM per RFC 6376; legacy DomainKeys signing should be retired.
Was DKIM required for DMARC at the time of RFC 4871?
DMARC did not exist yet. DMARC was published as RFC 7489 in March 2015. RFC 4871 defined DKIM as a standalone authentication mechanism. The concept of policy layer requiring alignment came later. Historical context: authentication mechanisms (SPF, DKIM) came first, then DMARC unified them as inputs to a common anti-spoofing policy nearly a decade later.
Do I need to change my DNS records if my DKIM was published under RFC 4871?
The DNS record format is compatible. Audit for: (1) key length under 1024 bits (rotate to 2048), (2) SHA-1 signing (rotate to SHA-256, RFC 8301), (3) missing acceptable algorithm hint in the DNS record (add h=sha256). The public key format itself (p= tag) has not changed between RFC 4871 and RFC 6376.
Why did DKIM need to be developed if SPF existed?
Different authentication properties. SPF authenticates by IP address (which server sent this?); DKIM authenticates by cryptographic signature (was the content modified in transit?). SPF breaks when mail is forwarded (IP changes); DKIM survives forwarding as long as content is not modified. Combining them provides more robust authentication than either alone. DMARC later formalized this by requiring at least one to align with the From header.
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.
