DKIM, or DomainKeys Identified Mail, lets a domain take responsibility for an email by attaching a cryptographic signature that a receiver can verify with a public key published in DNS.
DKIM- What is DKIM? How the signature, DNS key, and DMARC alignment fit together
- The mental model
- What exactly gets signed?
- Anatomy of a DKIM-Signature
- Selectors are what make key rotation practical
- Canonicalization: why harmless-looking changes sometimes survive
- Modern DKIM cryptography
- DKIM vs SPF vs DMARC
- A DKIM pass can still fail DMARC alignment
- Why DKIM often survives forwarding better than SPF
- 2. Confirm the public key exists at that exact name
- 3. Check the algorithm and key policy
- 4. Check whether the message changed after signing
- 5. Check canonicalization before blaming normal whitespace changes
- 6. Separate DKIM validity from DMARC alignment
- Worked example
- What passes and what does not
- Common mistakes
- Troubleshooting a DKIM failure
- Questions we get asked
- OnVoard's take
What is DKIM? How the signature, DNS key, and DMARC alignment fit together
A successful DKIM check answers a narrow but useful question: > Did this message validate against a public key controlled through the domain named in the DKIM signature? It does not prove the identity of the human who wrote the message, it does not encrypt the message, and it does not guarantee inbox placement.
The mental model: DKIM is a signed claim by a domain
DKIM has 2 sides. On the sending side, a mail system:
Two independent checks, joined only by DNS
DKIM has two independent sides. The sender signs, and the private key never leaves that side. The receiver verifies on its own with a public key it fetches from DNS.
- Sender1Canonicalize and hash the bodyResult placed in bh=.
- 2Sign the headers with the private keyCovers h= and bh=.
- Receiver3DNS lookup for the public keyselector._domainkey.domain, from s= and d=.
- 4Recompute the hash and verify the signatureThe public key checks what the private key signed.
- ResultDKIM pass or fail
On the receiving side, a verifier. The DNS lookup is what lets the domain owner publish the public half of the key pair without distributing it directly to every receiver.
What exactly gets signed?
DKIM does not simply "sign the whole email file." The signature states which headers are covered through the h= tag. The From header must be included in the signed header field list. A signer can include other important fields such as Subject, Date, Message-ID, and To depending on its policy.
The body is handled separately. DKIM canonicalizes the message body, calculates a hash, and places that result in the bh= tag. The cryptographic signature in b= covers the selected header data, including the DKIM-Signature header with the signature value itself omitted for the calculation.
This split is why a DKIM result can fail after a message was legitimately modified in transit. A footer added by a mailing list, a rewritten subject, or other changes to signed content can make the receiver calculate different data from what the sender signed.
Anatomy of a DKIM-Signature
An illustrative signature can look like this:
Read the signature from the inside out
RSA algorithm. RFC 8301 rules out sha1, wants 2048-bit keys.
Domain and selector. Build the DNS name below.
Canonicalization. Relaxed tolerates formatting changes.
Signed headers. From must be included.
Body hash and signature, checked via the TXT record.
The important fields are. The corresponding DNS name is built from the selector and signing domain. A simplified RSA public-key record might look like. The private key stays with the signer. The public key is what receivers retrieve.
Selectors are what make key rotation practical
The selector is not just a random label. It creates separate key namespaces under the same signing domain. For example:
2026q3._domainkey.example.com2027q1._domainkey.example.com
can both exist at the same time. That enables a safer rotation pattern:
- publish a new public key under a new selector
- begin signing new mail with the new selector
- keep the old public key available long enough for older signed messages still in transit or being rechecked
- retire the old key after it is no longer needed
RFC 6376 specifically warns that reusing a selector with a newly generated key is ill-advized and recommends choosing a new selector when rotating.
Canonicalization: why harmless-looking changes sometimes survive
Email often changes slightly while moving between systems. DKIM therefore defines canonicalization algorithms for headers and bodies. The 2 common choices are:
- simple: preserves formatting more strictly
- relaxed: normalizes certain whitespace and header formatting differences before hashing
relaxed/relaxed does not mean "ignore all changes." It is designed to survive a limited class of presentation-preserving changes. If an intermediary changes signed semantic content, rewrites a protected header, or modifies the body beyond what canonicalization normalizes, the signature can still fail. This is why "the email looks the same" is not enough evidence that the signed bytes canonicalize to the same value.
Modern DKIM cryptography
The original DKIM RFC is not the only document that matters. RFC 8301 updated the cryptographic requirements for RSA DKIM:
rsa-sha1must not be used- RSA signing keys must be at least 1024 bits
- signers should use at least 2048-bit RSA keys
RFC 8463 later added ed25519-sha256 as a DKIM signing algorithm. That does not mean every sender should switch algorithms blindly. Standards support and real-world provider or library support are different questions. If you use Ed25519, confirm that the sending software, DNS publishing path, and important receivers support the deployment you intend.
DKIM vs SPF vs DMARC
These 3 technologies solve related but different problems. SPF is tied to the SMTP sending path. DKIM is tied to a cryptographic signature carried with the message. DMARC then asks whether a successful authenticated identifier belongs with the domain the recipient sees in the From header.
| Option | Mechanism | Core question | Main identifier | What a pass does not prove |
|---|---|---|---|---|
| SPF | SPF | Is this connecting host authorized to use this SMTP MAIL FROM domain? | MAIL FROM domain and sending IP | That the visible From domain is the same domain |
| DKIM | DKIM | Does this message validate against the public key for the signing domain? | d= signing domain | That the human author is who they claim to be |
| DMARC | DMARC | Does an authenticated SPF or DKIM identifier align with the visible From domain? | RFC5322.From author domain | That the content is wanted or safe |
A DKIM pass can still fail DMARC alignment
Suppose a recipient sees:
From: Example Store <[email protected]> DKIM d=mailer.vendor-example.net: pass
The DKIM result can be perfectly valid for mailer.vendor-example.net. But that signing domain is not aligned with example.com, so this particular signature does not give DMARC a DKIM-aligned pass for the visible From domain. Now compare:
DKIM d=email.example.com: passUnder relaxed DMARC alignment, email.example.com and example.com can align because they share the same organizational domain. This distinction is one of the most useful checks when "DKIM passes" but DMARC still fails.
A message can also carry multiple DKIM signatures. DMARC needs at least one valid DKIM authenticated identifier that aligns, or a qualifying aligned SPF authenticated identifier, for its validation logic.
Why DKIM often survives forwarding better than SPF
SPF checks the IP address of the system that is currently handing the message to the receiver against the domain used for SPF. Forwarding changes that SMTP path, so a straightforward SPF authorization can stop matching.
DKIM travels inside the message. If the forwarder leaves the signed content intact, the receiver can still verify the original signature against the original signing domain's DNS key. But "DKIM survives forwarding" is not a guarantee. If the forwarder changes signed headers or body content, the signature can break. This is one reason a well-aligned DKIM signature is valuable in a DMARC deployment.
2. Confirm the public key exists at that exact name
A missing record, wrong selector, wrong domain, or premature key removal can make verification impossible.
3. Check the algorithm and key policy
For RSA DKIM, do not use SHA-1 and do not deploy undersized keys. Confirm the signing software and DNS record agree on the key material being used.
4. Check whether the message changed after signing
Look for systems that append footers, rewrite subjects, transform MIME content, or otherwise touch signed material.
5. Check canonicalization before blaming normal whitespace changes
A relaxed signature can tolerate specific formatting changes that a simple signature will not. Read c= before assuming a modification is fatal.
6. Separate DKIM validity from DMARC alignment
If DKIM is pass but DMARC is fail, compare d= with the visible From domain. You may have an alignment problem rather than a cryptographic one.
Worked example
A merchant sees:
From: [email protected]DKIM-Signature: ... d=send.example.com; s=aug26; ...Authentication-Results: ... dkim=fail ...
A useful investigation is:
- 1. Query
aug26._domainkey.send.example.com - 2. If the record is missing, check whether an old selector was removed during rotation
- 3. If the record exists, compare the message received with the signing path and identify any system that modifies it after signing
- 4. If DKIM starts passing, check DMARC separately.
send.example.comcan align withexample.comunder relaxed alignment, but a valid signature for an unrelated vendor domain would not
That sequence keeps 3 different failure classes separate: key discovery, signature integrity, and policy alignment.
What passes and what does not
- DKIM does not:
- encrypt the email
- hide the message body
- prove the local part of an email address
- prove the personal identity of the author
- guarantee that the visible From domain aligns with
d= - decide whether the receiver should deliver, reject, or spam-folder the message
- guarantee that the message content is legitimate
- RFC 6376 deliberately separates the signing identity from the purported author. A signer can be an author's organization, a relay, or another agent that takes responsibility for the message
Common mistakes
- Treating
dkim=passas proof of the human sender - Treating DKIM encryption and DKIM signing as the same thing
- Looking up the public key under the visible From domain instead of using
d=ands= - Rotating a key by overwriting one selector and removing the old material too early
- Saying "DKIM passes DMARC" without checking alignment
- Assuming any forwarded message will preserve DKIM
- Reading a 1024-bit minimum as a recommendation to keep using 1024-bit keys when RFC 8301 recommends at least 2048 bits for RSA signers
Troubleshooting a DKIM failure
Work from the signature outward instead of guessing.
Questions we get asked
Does DKIM prove an email came from the From address?
Not by itself. DKIM proves a signature associated with the d= signing domain. DMARC is the layer that checks whether an authenticated DKIM domain aligns with the domain in the visible From address.
Does DKIM encrypt email?
No. DKIM signs selected message data. The message can still be readable in transit unless transport or content encryption is provided by other mechanisms.
Can one message have more than one DKIM signature?
Yes. RFC 6376 allows multiple signatures. Different systems in a delivery chain can sign the same message, and DMARC can evaluate valid aligned DKIM identifiers among the authentication results.
Should I use 1024-bit or 2048-bit RSA DKIM keys?
RFC 8301 requires at least 1024 bits and says signers should use at least 2048 bits. In a new deployment, 2048-bit RSA is the more appropriate default when the sending platform and DNS provider support it.
Why does DKIM fail after an email forwarding or mailing-list hop?
Usually because signed content changed, the public key cannot be retrieved, or the signature was otherwise invalidated. Forwarding itself does not automatically invalidate DKIM; modification of signed data is the key distinction.
Is Ed25519 DKIM supported by the standard?
Yes. RFC 8463 defines ed25519-sha256 for DKIM. Operational support still needs to be checked across the systems and receivers that matter to your deployment.
OnVoard's take
The most useful DKIM debugging habit is to stop treating "DKIM" as one checkbox.
Read the actual signature. The d= domain tells you who signed, s= tells you which key to fetch, h= tells you what was protected, c= tells you how it was normalized, and DMARC tells you whether that authenticated domain is the one the recipient-visible From identity needs.
Once those layers are separated, many "authentication mysteries" become ordinary key, mutation, or alignment problems.
Every app on every plan. Connect your store and switch on the flows in an evening.