What this RFC defines
RFC 6376 defines DKIM (DomainKeys Identified Mail), a cryptographic signature standard that lets receiving MTAs verify that a message was authorised by the sending domain. The sending server signs outgoing messages using a private key; the receiving server retrieves the matching public key from DNS and verifies the signature.
Where you see it in practice
The DKIM-Signature: header in every email you send is defined by this RFC. When Gmail shows “signed by yourdomain.com” in the message details panel, it is reporting a successful DKIM verification per RFC 6376. A DKIM failure (signature mismatch or missing key) causes DMARC alignment to fail and can push mail into spam folders at major mailbox providers.
How it connects to other RFCs
RFC 6376 obsoletes RFC 4871 (the original DKIM specification from 2007). It is one of three authentication pillars alongside RFC 7208 (SPF) and RFC 7489 (DMARC). RFC 8617 (ARC) extends DKIM to preserve authentication state across forwarding hops. RFC 5863 provides operational guidance for deploying DKIM in production.
Current status
RFC 6376 is the current DKIM standard, published September 2011. It has been required by Gmail and Yahoo for bulk senders since February 2024. No successor is expected; improvements to DKIM are handled through operational guidance documents rather than new core RFCs.
The current DKIM standard
RFC 6376 is the current DKIM standard, published in September 2011 and obsoleting RFC 4871. It specifies how a sending domain adds a cryptographic signature to outgoing messages (the DKIM-Signature header) and how receiving domains verify it against a public key published in DNS. The signature covers a set of headers (declared in the h= field) and the message body (with hash in bh=), signed with the private key corresponding to a specific selector under the domain.
What DKIM proves and does not prove
DKIM proves that the message was authorized by the signing domain and has not been modified in transit (within the scope of the signed headers and body). It does not prove that the RFC 5322 From header matches the signing domain; that is the alignment check performed by DMARC (RFC 7489). A message signed by mailgun.org can pass DKIM even if it claims From: alice@example.com, which is why DMARC alignment is required for effective spoofing protection.
Implementation across major providers
Every major mailbox provider verifies DKIM on inbound mail: Gmail, Outlook.com, Yahoo, iCloud, ProtonMail, Fastmail, and every enterprise Exchange or O365 deployment. On the outbound side, ESPs like SendGrid, Mailgun, Amazon SES, and Postmark sign every outbound message with the sender domain DKIM key (when configured). If DKIM signing is not configured on your sending domain, your mail is at severe deliverability disadvantage: bulk senders that skip DKIM see rejection rates several times higher than authenticated senders.
RFC 6376 (September 2011, updated by RFC 8301, RFC 8463) defines DomainKeys Identified Mail (DKIM): a cryptographic signature mechanism that lets a domain claim responsibility for an email. The sender publishes a public key in DNS; the sending MTA signs outgoing messages with the paired private key; receiving MTAs verify the signature to confirm the message was not modified in transit and originated from someone controlling the signing domain. Obsoletes RFC 4871. Combined with SPF (RFC 7208) and DMARC (RFC 7489), DKIM is one of the three pillars of modern email authentication.
RFC 6376 at a glance
| Aspect | Detail |
|---|---|
| Purpose | Cryptographic proof that an email was sent by (or through) an authorized signer |
| Signature location | DKIM-Signature header field added by signing MTA |
| Key storage | Public key in DNS TXT record at [selector]._domainkey.[domain] |
| Algorithms | RSA-SHA256 (default), Ed25519 (per RFC 8463) |
| Verification | Receiving MTA fetches public key from DNS, verifies signature against message body and selected headers |
| Result surfaced in | Authentication-Results header per RFC 8601 |
| Published | September 2011 (obsoletes RFC 4871) |
| Updates | RFC 8301 (crypto agility, deprecates SHA-1 and 512-bit keys), RFC 8463 (Ed25519 support) |
The DKIM-Signature header dissected
| Tag | Purpose | Example |
|---|---|---|
v | DKIM version (always 1) | v=1 |
a | Signing algorithm | rsa-sha256 or ed25519-sha256 |
c | Canonicalization: header/body | relaxed/relaxed (recommended); alternatives simple/simple, relaxed/simple |
d | Signing domain (the d= identity used for DMARC alignment) | d=sender.com |
s | Selector: identifies which key at [selector]._domainkey.[d] | s=mail-2026 |
t | Signature timestamp (Unix seconds) | t=1721654400 |
x | Signature expiration (optional) | x=1724246400 |
h | Colon-separated list of headers included in signature | h=From:To:Subject:Date |
bh | Body hash (base64) | bh=fUxD9K1o7... |
b | The signature itself (base64) | b=Hf3+2LzKQ... |
i | Signing identity (optional, refines d) | i=@marketing.sender.com |
l | Length of signed body content (deprecated, security risk) | Should not be used |
The DKIM DNS record
Header and body canonicalization
DKIM signs a canonical form of the message so that trivial modifications (whitespace normalization, line-ending changes) do not break the signature. The c tag selects header/body canonicalization independently.
| Canonicalization | Effect on headers | Effect on body | Recommendation |
|---|---|---|---|
simple | No modification (strict, brittle) | Only trailing empty lines removed | Legacy; avoid for headers |
relaxed | Lowercase names, unfold, reduce whitespace | Reduce whitespace, remove trailing empty lines | Recommended for both |
Common DKIM implementation mistakes
d= domain for DMARC alignment. For DKIM to align with DMARC, the d= in the DKIM signature must match (or be a parent of, in relaxed alignment) the From header domain. Signing with your ESP’s domain (like d=sendgrid.net) does not produce DMARC alignment; you must configure ESP-provided authenticated sending or CNAME-based key delegation so the signature uses your own domain.l tag. The l tag limits how much of the body is signed. Attackers can append arbitrary content past the signed length and the signature still verifies. RFC 6376 marks this as SHOULD NOT use; RFC 8301 upgrades to MUST NOT. Never enable l.Related standards and further reading
- RFC 4871: Legacy DKIM (obsoleted by RFC 6376)
- RFC 8301: DKIM crypto agility (deprecates SHA-1 and 512-bit keys)
- RFC 8463: Ed25519 signature support for DKIM
- RFC 5863: DKIM Deployment, Operations, and Considerations
- RFC 5518: Vouch By Reference (uses DKIM signing)
- RFC 8617: ARC (preserves DKIM verdicts across forwarders)
- DKIM Record Setup Guide: creating and publishing keys
- Free DKIM Record Checker: verify your public key publication
- Authentication-Results Header: reading the DKIM=pass/fail verdict
- SPF Record Guide: paired authentication mechanism
- DMARC Record Guide: policy layer over SPF and DKIM
Frequently asked questions
What is the difference between the DKIM signing domain and the From domain?
The signing domain is the value of d= in the DKIM-Signature header; it identifies the domain that owns the key used to sign. The From domain is the visible sender in the From header per RFC 5322. These can differ. For example, if you send through SendGrid without CNAME setup, the signature might have d=sendgrid.net while your From is @yourbrand.com. This produces a valid DKIM signature but does not align with DMARC. Configure your ESP for authenticated sending (CNAME delegation of the DKIM selector to your own domain) so d= matches your From domain.
Can a message have multiple DKIM signatures?
Yes. RFC 6376 explicitly allows multiple DKIM-Signature headers. Common patterns: sender signs with their domain, then an ESP or gateway adds a second signature with a different d=. Verifiers check each signature independently; DMARC alignment succeeds if any DKIM signature aligns with the From domain. Adding signatures does not invalidate existing ones (unlike modifying content).
What key size should I use in 2026?
2048-bit RSA is the current best practice. RFC 8301 recommends 2048-bit; 1024-bit still works but is considered weak (Gmail explicitly downgrades verdicts for 1024-bit signatures in high-volume commercial sending). Ed25519 (per RFC 8463) offers equivalent security with much shorter keys and signatures but is not universally supported by verifiers; deploy alongside RSA rather than replacing it. Do not publish keys shorter than 1024 bits.
Why does my DKIM verification fail after forwarding?
Mailing lists and some forwarders modify the message body (adding footers, unsubscribe links) or headers (rewriting Subject, adding List-Id) after signing. Any modification to signed content invalidates the signature. Fixes: sign with relaxed canonicalization (survives whitespace changes but not content changes), or use ARC which allows intermediaries to attest to the pre-modification authentication results. Mailing list operators should adopt ARC signing.
Does DKIM prove the sender identity?
DKIM proves that someone controlling the DKIM key signed the message. It does not prove who authored the message content. For example, if you delegate DKIM signing to an ESP, the ESP holds the private key; anyone who compromises the ESP can send authenticated mail as your domain. DKIM is a domain-level authentication, not user-level. User identity requires end-to-end signing (S/MIME, OpenPGP) which is separate from DKIM.
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.
