What is DKIM?

Email is weirdly trusting by default. It was designed in an era when “who would pretend to be me?” was not the daily reality. Today, attackers bypass mail servers, spoof brands, intercept poorly protected mail flows, and use email spoofing to nudge people into paying invoices, resetting passwords, or opening malware.

If you are reading this because you have just experienced a ransomware incident and are unsure how to deal with it, contact Zensec immediately.

DKIM (DomainKeys Identified Mail) is an email authentication method that helps fix that trust problem. A DKIM protocol allows a domain owner to attach a digital signature to email messages so the receiving email server can verify two things:

1. First, the message was sent by a mail transfer agent authorised to sign messages on behalf of that domain.
2. Second, the message contents were not meaningfully altered after the DKIM signing process.

If you want a plain-English version: DKIM is like putting a tamper-evident seal on an email, backed by maths instead of vibes.

What DKIM signatures actually prove

When DKIM authentication passes, the receiver can be confident that a mail system holding the domain’s private key signed the message, and that the signed parts arrived intact. That gives defenders something stable to trust, measure, and build policy around.

In the DKIM model, the “identity” being asserted is not a person; it’s a domain. The signature includes a domain identifier (the d= value in the DKIM-Signature header), which receivers can treat as the trusted domain taking responsibility for the message.

That “responsibility” framing matters. DKIM work isn’t claiming the sender is a good actor; it’s saying “this domain’s infrastructure is accountable for this message.”

DomainKeys Identified Mail (DKIM) works in practice

Under the hood, this email authentication system uses public-key cryptography, with DNS records serving as the directory.

At send time, your mail system:

1. Normalises parts of the email in a predictable way (this is called canonicalisation). It’s designed to ignore trivial changes, such as whitespace or harmless header folding, that can occur as mail passes through different servers.
2. Creates hashes of the DKIM headers it cares about, plus the body.
3. Uses a private key to sign those hashes.
4. Adds a new email header, DKIM-Signature, containing the signature and a pointer to the public key.

At the receiving time, the receiving system:

1. Fetches the domain’s public key from the sender’s DNS record using the DKIM selector.
2. Recomputes the hashes to confirm DKIM validation.
3. Fetches the public key published in the DNS TXT record.
4. Verifies the signature matches.

If it matches, the receiver knows the email was signed by someone holding the private key, and the signed content is intact. The outcome of that check is typically recorded in an Authentication-Results header for downstream filtering and auditing.

The selector: why DKIM keys are not “one and done”

A single domain can have multiple DKIM records, and it should. Email security best practices use a DKIM selector (the s= tag), which is basically a label used to look up the right public key in the domain’s DNS records.

This facilitates DKIM key rotation, treating DKIM keys as normal maintenance rather than an emergency.

Selectors are intentionally “opaque” to everyone else. The point is operational flexibility: you can rotate keys, delegate signing for a specific platform, or run parallel keys during migrations without breaking everything.

Good DKIM setups treat key rotation as routine maintenance, not an emergency.

What DKIM does not do (this is where teams get tripped up)

DKIM protocol is important, but it’s also narrow. On its own, a DKIM pass does not mean:

• The human sent it.
• It is safe.
• It won’t end up in spam folders.
• The visible “From” address is trustworthy in the way users interpret it.
• The message cannot be replayed somewhere else.

DKIM primarily gives you a verifiable domain signal and message integrity for the parts that were signed. What you do with that signal is a separate decision made by mail providers and your security tooling.

If you treat DKIM as “we’re secure now,” you will eventually get embarrassed by a phishing campaign that technically authenticates.

DKIM vs SPF vs DMARC (and why DKIM matters even if you “already have SPF”)

These three controls are often discussed together because they address adjacent email security problems.

• Sender Policy Framework (SPF) answers: “Is this sending server allowed to send mail for this domain (based on the envelope sender)?”
• DKIM answers: “Does this email have a valid digital signature from an authorised domain, and did the signed content arrive intact?”
• DMARC answers: “Do SPF and or DKIM align with the domain users see in the From address, and what should receivers do if they do not?”

DKIM is especially valuable because it works even when SPF often fails, such as in forwarding and some relay scenarios. That resilience is a big reason DKIM is a core building block for DMARC-based policy enforcement.

Why DKIM improves deliverability

Mailbox providers are trying to protect users while still delivering legitimate mail. Authentication is a major input into their scoring systems.

When your domain consistently signs mail correctly, you generally see fewer false positives to spam and more stable inbox placement, especially for bulk or marketing email.

That said, DKIM is not a magic deliverability button. If your content, sending behaviour, or list hygiene is poor, DKIM just ensures your bad decisions arrive with a valid signature.

Common DKIM pitfalls we see in the real world

The most common failures are not “crypto problems,” they’re operational problems.

1. Third-party senders often fail to sign outgoing emails using your domain. Marketing platforms, ticketing systems, CRMs, finance tools, and survey software often send mail on your behalf. If those streams are not correctly signed and aligned, DMARC enforcement becomes painful.
2. DNS and key management are sloppy. When a DKIM record stores old data, keys linger for years, selectors are reused without rotation, and nobody remembers which keys sign what. That is how small issues turn into deliverability incidents.
3. Mail is being modified downstream. Mailing lists and intermediaries sometimes rewrite headers or email messages in ways that break signatures. DKIM can be configured to tolerate some changes, but you should design for the real world, not the ideal world.

A sensible approach to implementing DKIM

Treat this as an email authentication program, not a one-off task. Ensure every system that sends mail on your behalf has its public key published correctly. Monitor your DNS TXT record entries and rotate DKIM keys on a schedule.

This is also one of those areas where a broader review pays off, because DKIM touches identity, DNS hygiene, third-party risk, and incident readiness. If you want a structured way to surface weaknesses across those dependencies, consider a cyber security risk assessment that evaluates your email authentication and spoofing exposure.

The takeaway

DKIM is a foundational email security control that helps recipients verify domain responsibility and message integrity. It will not stop every email threat, but without it, you are leaving your domain’s reputation and your users’ trust up for grabs.

If your organisation sends any meaningful volume of email, DKIM is not optional. It’s basic hygiene.