A signed message can still be spam. Its signing domain can also differ from the address displayed to the recipient.
What does a DKIM signature cover?
A DKIM signature protects selected header fields and a hash of the body.
The h= tag lists the signed header fields. The bh= tag holds the body hash. The sending server produces the signature with its private key. Receivers verify it with the corresponding public key.
A receiver recalculates the body hash. It also verifies the signature over the selected headers and the signature header, which contains that hash.
RFC 6376 requires signing the From header. Other header fields can remain unsigned. Adding an unsigned Reply-To can therefore leave DKIM valid.
Repeated headers need separate treatment. The signer can list a header name more times than it occurs to prevent another occurrence being added undetected.
Where does the receiver find the public key?
The receiver locates the public key using the signing domain and selector, the name identifying that key. The d= tag gives the domain. The s= tag gives the selector.
For d=example.com and s=foo.bar, the lookup name is foo.bar._domainkey.example.com. The selector permits different keys under the same signing domain.
During rotation, publish the replacement key before signing with it. Keep the old verification key available while messages signed with it remain in transit. Removing it prematurely prevents receivers from verifying those messages.
Why can formatting changes break a signature?
Canonicalization, the normalization applied before signing and verification, determines which formatting changes DKIM tolerates.
The c= tag chooses separate header and body algorithms. In relaxed/relaxed, both use relaxed normalization.
| Algorithm | Header behavior | Body behavior |
|---|---|---|
simple | Preserves header formatting | Ignores empty lines at the end |
relaxed | Normalizes header-name case, folding and whitespace | Normalizes whitespace and trailing empty lines |
A folded header continues onto another line. Relaxed header processing tolerates that folding. Simple processing can fail after a server refolds the same header.
Compare the signed content before and after the failing relay, because an invisible formatting change can explain the result.
Which signing algorithms does DKIM support?
DKIM supports the RSA and Ed25519 signing algorithms, both combined with SHA-256.
RSA has a minimum key size of 1024 bits under RFC 8301. Shorter keys provide insufficient resistance to key compromise.
The recommended RSA size is at least 2048 bits, providing more resistance to key compromise. Choose that size when your signing system supports it. The specification prohibits rsa-sha1 for signing and verification.
RFC 8463 adds ed25519-sha256. A message can carry both RSA and Ed25519 signatures for compatibility with receivers supporting different algorithms.
Yahoo's guidance also requires a minimum 1024-bit DKIM key.
What happens when a mailing list edits the message?
An edit can invalidate DKIM when it changes content covered by the signature.
Forwarding does not itself change the signed content. An intact signature can survive it. An appended footer can change the body hash. A rewritten signed Subject can invalidate the header signature.
The optional l= tag limits body coverage to a specified number of bytes. With l=100, content after the first 100 normalized bytes is unprotected. Appending misleading text can therefore leave the signature valid.
Avoid that limit when you need the whole body protected. ARC lets intermediaries preserve signed evidence of authentication before their edits.
How do you configure DKIM with Bird?
You publish the DKIM record returned when you register your sending domain.
The API's dkim.mode field defaults to txt. With that mode, publish the public key in a TXT record. The schema also lists delegated. That value returns HTTP 422 when you register a sending domain, so use txt.
Bird creates a separate key and selector for each organization using a sending domain. Organizations using the same domain do not need to share a signing key.
The authentication guide explains the returned record.
Does a passing signature prove that the message is safe?
A passing signature establishes responsibility for the signed content. It does not establish whether the message is wanted or trustworthy.
It also does not require the signing domain to match the visible From domain. DMARC supplies that matching rule through alignment. Sender reputation, the receiver's assessment of a sender's traffic, remains a separate consideration.
In short
Only selected content is protected.
DKIM covers the listed header fields and a body hash. Unprotected content can change without invalidating the signature.
Selectors locate verification keys.
The selector and signing domain identify the DNS record containing the public key.
Normalization affects verification.
The simple and relaxed algorithms treat formatting changes differently.
Forwarding does not guarantee a pass.
An intact signature can survive forwarding, but changes to signed content can break it.