DKIM: signing messages to prove origin and integrity

DKIM (DomainKeys Identified Mail) lets a domain sign the messages it sends. The sending server computes a signature over a subset of the headers and over the body, then inserts it in a DKIM-Signature: header. The receiving server fetches the matching public key from DNS and checks that the message was not altered in transit and was indeed signed by the domain it claims. DKIM is specified in RFC 6376.

How a signature works#

The DKIM-Signature: header carries several tags, including:

• d=: the signing domain, the one putting its reputation on the line;
• s=: the selector, a name that allows several keys to be published for the same domain;
• h=: the list of headers covered by the signature (From, Subject, Date, To, Message-ID and so on);
• bh=: the hash of the message body;
• b=: the signature itself;
• a=: the algorithm, in practice rsa-sha256 or ed25519-sha256;
• c=: the canonicalisation (simple or relaxed) applied to headers and body, which does or does not tolerate minor whitespace and case changes.

The verifier queries the name <selector>._domainkey.<domain>, recomputes the hash and compares. If everything matches, the result is dkim=pass and the d= identity is considered authenticated. Unlike SPF, DKIM survives forwarding and relaying as long as the message is not modified.

The DNS record#

The public key is published as a TXT record under the _domainkey label:

s2026a._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA...IDAQAB"

Useful tags:

• v=DKIM1: version, optional but recommended as the first tag;
• k=rsa or k=ed25519: key type;
• p=: the base64 public key; an empty value means the key is revoked;
• t=y: test mode, not to be left in production;
• t=s: forbids use of the key for subdomains of d=.

A 2048-bit RSA key produces a string longer than 255 characters: it must be split into several strings within the same record, which most DNS interfaces do automatically but not all. Ed25519 keys (RFC 8463) are much shorter, but not every verifier accepts them yet; common practice is to sign twice, with RSA and Ed25519.

Deploying DKIM#

1. Generate a 2048-bit RSA key pair (1024 bits is now treated as insufficient by most mailbox providers).
2. Pick an explicit selector, for instance a dated one (s2026a), to make rotation easier.
3. Publish the public key in DNS, wait for propagation, then enable signing on the server or sending platform.
4. For an external provider, the usual pattern is to publish a CNAME from <selector>._domainkey.your-domain to a name hosted by the provider, which then manages the key and its rotation. In that case d= remains your domain, which is essential for DMARC alignment.
5. Sign at least From, To, Subject, Date, Message-ID, MIME-Version and Content-Type. Also oversign, by listing them once more in h=, the headers that must not be added afterwards, in particular From and Subject.
6. Rotate keys regularly, ideally every six to twelve months: publish the new key under a new selector, switch signing over, keep the old key published for a few days for messages still in transit, then remove it.

Common mistakes#

• 1024-bit keys or shorter: the signature is accepted but discounted, sometimes ignored.
• d= on the provider's domain: the signature is valid but does not align with your From:, so it does not count for DMARC.
• Signing too few headers: a message can be replayed with a modified Subject or To while keeping a valid signature.
• The l= tag (signed body length): allows content to be appended after the signed part. Avoid it.
• Modification after signing: a footer added by a gateway, link rewriting, encoding conversion. The signature breaks and only ARC can preserve a trace of the original result.
• DKIM replay: a legitimately signed message, for example sent from a trial account on a shared platform, is re-sent in bulk to other recipients with its signature intact. Signing Date and Message-ID, bounding validity with x=, and monitoring sending accounts reduce the risk. The DKIM2 work aims to address this problem at the root.
• Keys never withdrawn: an abandoned selector that is still published remains usable if the private key ever leaked.

What SenderRadar shows#

SenderRadar lists the DKIM selectors observed for a domain, the type and size of each key, any test mode flag, CNAME delegations to providers, and flags weak or revoked keys. SenderRadar relies on its own analysis base to show, progressively, how selectors evolve over time.

References#

• RFC 6376 – DomainKeys Identified Mail (DKIM) Signatures
• RFC 8463 – A New Cryptographic Signature Method for DKIM (Ed25519)
• RFC 8301 – Cryptographic Algorithm and Key Usage Update to DKIM
• IETF DKIM working group