What is DKIM (email signing)?
DKIM is the cryptographic signature the outbound server adds to the header of every message, proving two things to the recipient: that it really came from whoever controls the domain, and that the signed portion was not altered along the way. The key that verifies the signature is published in the domain's DNS, visible to any server in the world. It is the second of the three email authentication records, and the only one that still holds when a message is forwarded unchanged.
How DKIM works
DKIM uses a key pair: one stays on the sending server and signs, the other is published in DNS so any recipient can verify. Nothing from the signing key ever leaves the server.
Generate the key pair and pick a name
The email service creates two linked keys and a short name to identify that pair, the selector. A company can run several selectors, one for each system that sends.
Publish the verification key in DNS
The public key goes in as a text record on the domain, under an address derived from the selector, in the form selector._domainkey.yourdomain.com. It is public on purpose: its whole job is to let any server in the world use it.
Sign the message on the way out
At send time the server computes a cryptographic digest of the chosen headers and the body, seals that digest with the key only it holds, and writes the result into a header of the message itself.
The recipient verifies and decides
The receiving side reads the selector and domain from the header, fetches the key from DNS, recomputes the digest and compares. If they match, the signature is valid and that domain has taken responsibility for the message.
Source: RFC 6376, the official DKIM specification published by the IETF, which defines the signature as a domain's assertion of responsibility and the publication of the public key in DNS, RFC 8301, which updates it on algorithms and key size, and N-able University's email DNS configuration material.
The limits of DKIM
- A valid signature does not mean a trustworthy message. DKIM asserts that a domain took responsibility for the message, and nothing beyond that. A criminal can register a domain, configure flawless DKIM and successfully sign their own scam. And the specification itself states that it defines no mechanism against replay: a legitimate message captured and blasted out again arrives with the signature still valid.
- The signing domain need not be the one you read. The specification separates responsibility for sending from apparent authorship. That gap is exactly what DMARC closes by requiring the two to match.
- Legitimate modification breaks the signature. Mailing lists and systems that append a footer or change the subject alter the signed portion, and verification fails with no ill intent involved.
- A forgotten key is a weakened key. A pair generated once and left for years, or a key that is too short, turns the signature into a formality. Periodic rotation and removal of selectors for retired services are worth the effort.
The parts of a DKIM signature
- The selector The short name identifying which key pair was used. It is what allows several signatures to be active at once, one per sending system, and lets you replace one without taking down the others.
- The signing domain The domain taking responsibility for the message. It is the value DMARC compares against the visible sender, and therefore the point that decides whether authentication truly counts.
- The cryptographic digest A computation over the chosen headers and the message body. Any content change within the signed portion, however small, makes the arithmetic fail. What falls outside the signed portion is not protected, though: the specification itself warns that content can be appended past the signed point without breaking the signature.
- The key published in DNS The public half of the pair, available for any server to check. Its exposure is intentional: with it you can verify a signature, never produce one. The caveat is size: a key that is too short can be broken, and at that point the published half stops being harmless.
Why DKIM is what keeps authentication standing
DKIM's practical value shows up exactly where SPF fails. When someone forwards a message, the forwarding server becomes the origin and is no longer on the original domain's authorized list, so SPF breaks with nobody at fault. The DKIM signature travels inside the message's own header and remains valid after forwarding, as long as nobody alters the content along the way, which makes it the sturdier leg of authentication and the reason publishing SPF alone takes legitimate email down. There is, however, a false comfort specific to this record: signing with a domain that is not the one shown to the reader. The DKIM check passes, the report shows a valid signature, and the message still fails DMARC, because what the person reads on screen remains unproven. Translated into what the business feels: the proposal your contact forwards to the decision-maker, the invoice a client passes to their finance team and the notice that circulates internally are exactly the messages that depend on DKIM to arrive authenticated at the end of the chain. Without a signature, it is precisely the email that already cleared the first stage of the sale that vanishes into another company's spam filter. Signing is necessary; signing with the right domain is what makes the signature count.
How to apply DKIM properly
DKIM delivers the most when it covers every outbound path and signs with the domain the recipient actually sees:
- Sign everything that leaves, not just corporate mailEvery system sending on the company's behalf needs its own signature: the campaign platform, the ERP, the invoicing system, the support tool. Whatever does not sign is left leaning on SPF alone, and SPF breaks on forwarding.
- Use one selector per serviceSeparate selectors let you rotate one system's key, or switch it off, without touching the others. They also make it obvious, from reading a header, which platform sent a given message.
- Prefer the 2048-bit keyIt is the size the standard says to prefer. Below 1024 bits a signature can no longer be considered valid: a key that is too short can be broken and used to forge the domain's signature, which is the one scenario where publishing the key becomes a risk.
- Check alignment with the visible senderA valid signature is worth nothing if the signing domain is not the one shown to the reader. That match is what DMARC requires, and it is what makes authentication count.
- Rotate keys and clean up what you no longer useReplace the pairs periodically and remove from DNS the selector of every discontinued service. A published key for an abandoned system is exposed surface with no upside.
In practice
DKIM is the message's seal: it does not say the contents are good, it says the package left whoever controls that domain and nobody tampered with it on the way. That is why a scam can arrive with a perfectly valid signature, from the scammer's own domain. The question that matters is never merely whether a signature exists, but whose signature it is, and whether it matches the name shown on screen.
How Zamak handles DKIM
Zamak Technologies signs every outbound path, keeps one selector per system so keys can be rotated without interrupting anything, and checks the alignment between the signing domain and the sender the recipient sees, alongside the team that already administers the environment. The email spoofing check shows in seconds whether your domain publishes a signature today. Maintaining those keys is part of Managed Email Security and of Managed Cybersecurity in the Zamak Method.