What is DKIM and how does it work?

11 May 2026 · 12 min read

When a message arrives at Gmail, Outlook, or any serious mail provider, the receiving server wants to answer two questions before it decides where to put it. First, did this message really come from the domain it claims to come from? Second, has anyone tampered with it on the way? DKIM is the mechanism that lets a receiver answer both questions with cryptography rather than guesswork.

DKIM stands for DomainKeys Identified Mail. It works by attaching a digital signature to every message you send. The signature is generated with a private key that only your sending system holds, and it can be verified by anyone using a matching public key that you publish in DNS. If the signature checks out, the receiver knows two things at once: the message was authorised by whoever controls the signing domain, and the parts of the message that were signed have not been altered since they were sent.

This article explains what DKIM actually is, how a signature is created and verified step by step, how to read the headers and the DNS record, and the property that makes DKIM so valuable: because it signs the message itself rather than the connecting server, a DKIM signature can survive forwarding scenarios that break SPF outright. We will also cover where DKIM falls short on its own, and why it only becomes a real anti-spoofing control when DMARC ties it back to the address your recipient actually sees.

The problem DKIM was built to solve

Plain SMTP, the protocol that moves email between servers, carries no proof of origin and no proof of integrity. A server can connect, claim to be sending on behalf of payments@yourbank.example, and hand over a message. Nothing in the basic protocol stops it, and nothing guarantees that the body and headers a recipient reads are the ones the genuine sender wrote.

SPF addresses part of this by letting you publish a list of servers allowed to send for your domain, and a receiver checks the connecting IP against that list. That is a useful signal, but it has a structural weakness: SPF validates the server that happens to be connecting, not the content of the message, and it authenticates the envelope sender rather than the visible From: address. The moment a message is forwarded, the connecting server changes, and the SPF check is being run against the forwarder rather than the original sender.

DKIM takes a different angle. Instead of asking "is this the right server?", it asks "is this message cryptographically vouched for by a domain, and is it unchanged?" That shift, from authenticating the transport to authenticating the message, is the whole point of DKIM, and it is why the two mechanisms complement each other rather than duplicate each other.

Public-key cryptography in one paragraph

DKIM rests on asymmetric cryptography, so it is worth being precise about what that means. You generate a key pair: a private key and a public key. The private key can produce a signature over some data, and that signature can only have been produced by someone holding that private key. The public key cannot produce signatures, but it can verify them: given the data, the signature, and the public key, anyone can confirm that the signature was made by the matching private key and that the data has not changed.

The asymmetry is what makes the whole scheme safe to operate in the open. You keep the private key secret on your sending infrastructure, and you publish the public key in DNS for the entire internet to read. Publishing the public key gives nothing away, because it cannot be used to forge a signature. A receiver who fetches your public key can verify your mail but can never impersonate you.

How a DKIM signature is created when you send

Signing happens on your outbound mail server, or on the platform of whatever service sends on your behalf (Google Workspace, Microsoft 365, an email service provider, your help desk tool, and so on). Here is the sequence, step by step.

1. The signing system chooses which headers to sign and computes a hash of the body of the message. The body hash is recorded so that any later change to the body becomes detectable.
2. It assembles a DKIM-Signature header containing the signing domain (d=), a selector that names which key to use (s=), the list of signed headers (h=), the body hash (bh=), and the algorithms in use.
3. It then computes a hash over the chosen headers plus the DKIM-Signature header itself (with the signature field left empty), and signs that hash with the private key.
4. The resulting signature is written into the b= field of the DKIM-Signature header, and the message is sent.

A real signature header looks roughly like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=yourcompany.com; s=mail2024;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
  b=AbCdEf123...signature bytes...XyZ==

Two fields deserve special attention. The d= tag is the signing domain, the identity that is taking responsibility for this message. The s= tag is the selector, a label you choose that tells the receiver which specific public key to look up. Selectors let you run several keys at once (for example one per sending service, or an old and a new key during a rotation) without collisions.

How a receiver verifies the signature

When the message arrives, the receiving server runs the process in reverse. It does not need to contact you, ask permission, or trust the connecting server. Everything it needs is in the message plus your public DNS.

1. The receiver reads the DKIM-Signature header and extracts d= (the domain) and s= (the selector).
2. It constructs a DNS query for the public key at <selector>._domainkey.<domain>. For the example above that is mail2024._domainkey.yourcompany.com.
3. It fetches the TXT record there, which contains your public key.
4. It recomputes the body hash and compares it with the bh= value. If they differ, the body has been altered and verification fails immediately.
5. It recomputes the header hash over exactly the headers listed in h=, then uses the public key to check that the b= signature matches. If it does, DKIM passes.

A pass tells the receiver, with cryptographic confidence, that the message was signed by the holder of the private key for that selector under that domain, and that the signed headers and the body have not changed in transit. A fail means either the signature was forged, the key is wrong, or something downstream modified the signed content.

You can run exactly this lookup against any selector and domain with the free DKIM checker, which fetches the published key, parses it, and flags common faults such as a revoked key, a weak key length, or a record split incorrectly across DNS strings.

Reading the DKIM DNS record

The public key lives in a TXT record at the selector hostname. A typical published key record looks like this:

mail2024._domainkey.yourcompany.com.  IN  TXT
  "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ..."

The tags you will meet are:

• v=DKIM1 declares the record version. It is optional but conventional, and when present it must come first.
• k=rsa names the key type. RSA is overwhelmingly the most common; Ed25519 is defined and supported by some providers but far less widely deployed.
• p= holds the public key itself, base64 encoded. This is the load-bearing part of the record. An empty p= means the key has been revoked, which is the correct way to retire an old selector.
• t= and s= are occasional flags. t=y marks the domain as still testing DKIM, and s=email restricts the key to email use. These are rarely set in practice.

Two operational facts trip people up. RSA keys at 1024 bits are increasingly treated as weak, and 2048 bits is the modern recommendation, so a 2048-bit key is the safe default when you generate one. And because a 2048-bit key is longer than the 255-character limit for a single DNS string, the record is split into several quoted strings that the DNS server concatenates; getting that split wrong is a frequent cause of a key that looks present but will not validate.

Why DKIM survives forwarding that breaks SPF

This is the property that makes DKIM indispensable, and it follows directly from what DKIM signs.

Consider what happens when someone sets up forwarding. A subscriber on a mailing list receives your message and the list re-sends it to every member. Or an employee forwards their work mail to a personal account. In both cases a new server, the list or the forwarder, now connects to the final recipient and delivers the message.

For SPF this is fatal. SPF checks the connecting IP against the original domain's authorised senders, but the connecting server is now the forwarder, which is almost certainly not on your SPF list. The SPF check fails, not because anything is wrong, but because SPF is bound to the transport and the transport changed. This is the classic reason legitimate forwarded mail fails SPF.

DKIM is bound to the message, not the connection. The signature travels inside the message itself, in the DKIM-Signature header. As long as a forwarder relays the message without modifying the signed headers or the body, the recipient can still fetch your public key, recompute the hashes, and confirm the signature. The fact that a different server delivered it is irrelevant to the maths. So a forwarded message that fails SPF can still pass DKIM, and DMARC only needs one of the two to pass and align for the message to be accepted.

There is an honest limit here, and it is worth stating plainly. DKIM only survives forwarding if the signed content is preserved. A mailing list that rewrites the subject line to add [list-name], appends a footer to the body, or strips and re-adds headers will change content that was signed, and the body hash or header hash will no longer match. DKIM then breaks too. This specific failure is exactly what ARC, Authenticated Received Chain, was designed to paper over, by letting trusted intermediaries vouch for the authentication results they saw before they made their changes.

DKIM alone does not stop spoofing

It is tempting to assume that a valid DKIM signature proves a message is legitimate. It does not, and understanding why is essential to using DKIM correctly.

DKIM proves that the signing domain in the d= tag vouches for the message. It says nothing, by itself, about the From: address your recipient actually reads. A spammer can register totally-legit-mail.example, set up valid DKIM for it, and send mail that passes DKIM perfectly while displaying From: support@yourbank.example in the header. The signature is genuine; it just belongs to the attacker's own domain, not to the one being impersonated.

The missing link is alignment. DMARC requires that a passing authentication result be tied back to the domain in the visible From: header. For DKIM, alignment means the d= signing domain matches (in strict mode) or shares the organisational domain of (in relaxed mode) the From: domain. A DKIM pass on totally-legit-mail.example does not align with a From: of yourbank.example, so under DMARC it provides no protection to the impersonated brand. We cover the precise rules in DMARC alignment explained.

So the accurate way to state it is: DKIM provides authentication and integrity, but only DKIM plus DMARC alignment provides anti-spoofing for the address people see. DKIM is a necessary ingredient, not a complete defence on its own. The same is true of SPF, which is why a robust setup publishes both and lets DMARC make the final decision.

DKIM, SPF, and DMARC working together

The three mechanisms are not competitors; they are layers, and they cover for one another's weaknesses.

• SPF authorises sending servers by IP. Fast and simple, but it breaks on forwarding and only checks the envelope sender.
• DKIM signs the message cryptographically. It survives many forwarding cases and proves integrity, but on its own it does not constrain the visible From:.
• DMARC sits on top and requires that at least one of SPF or DKIM both passes and aligns with the From: domain. It also tells receivers what to do when nothing aligns, and asks them to send you reports.

The practical consequence is that you want DKIM passing and aligned on as much of your mail as possible, because DKIM is the more resilient of the two underlying checks. When you read your aggregate reports, the healthiest senders are usually the ones showing DKIM aligned even where SPF has failed due to forwarding. If you are not yet receiving those reports, our report analyzer turns the raw XML into a readable picture of which sources are passing DKIM and which are not.

Setting up DKIM correctly: a practical checklist

Getting DKIM right is mostly about discipline rather than difficulty. The common steps are these.

1. Enable DKIM signing in each sending platform. Every service that sends as your domain (your mailbox provider, your marketing tool, your transactional provider, your CRM, your support desk) needs its own DKIM key. Each typically gives you a selector and a public key, or a CNAME to point at theirs.
2. Publish each public key at its selector. Add the TXT or CNAME record exactly as provided, taking care with the long-key string split. Verify it with the DKIM checker before relying on it.
3. Use 2048-bit RSA keys. They are the modern baseline. Avoid 1024-bit keys for anything new.
4. Inventory every sender. The most common cause of broken DMARC is a legitimate service nobody remembered to set up DKIM for. Aggregate reports are how you find those, which is the whole purpose of monitoring.
5. Rotate keys periodically. Generate a new selector, publish it, switch signing over, confirm the new selector is verifying, then revoke the old key by emptying its p= value. Selectors make this a clean, zero-downtime operation.
6. Confirm alignment, not just passing. A green DKIM result is only useful for anti-spoofing if the d= domain aligns with your From:. Check that explicitly.

If running keys for a dozen services, rotating them on schedule, and watching every report for the day a provider quietly breaks your signing sounds like a standing job rather than a one-off task, that is because it is. Our DKIM service and the wider done-for-you platform handle key management, alignment, and continuous monitoring across all your senders, with change alerts the moment a record moves.

The practical takeaway

DKIM is a digital signature on every message, made with a private key you keep secret and verified with a public key you publish in DNS. It proves that a domain vouched for the message and that the signed content was not altered, and because it is bound to the message rather than the connection, it survives many forwarding situations that cause SPF to fail. That resilience is exactly why DKIM matters.

What DKIM does not do on its own is stop someone spoofing your visible From: address, because the signature can belong to any domain. Only when DMARC insists that a DKIM pass aligns with the From: you actually show does it become a real anti-spoofing control. Set DKIM up on every sender, use strong keys, keep them aligned, and watch your reports.

A good next step is to point the free DKIM checker at your domain and selector to confirm your key is published, strong, and parseable, then read what DMARC is to see how the alignment that turns a signature into protection actually works. If you would rather not run it yourself, the DKIM product does the lot for you.