What is DKIM? DomainKeys Identified Mail explained

DKIM (DomainKeys Identified Mail) is an email authentication standard that lets a domain owner cryptographically sign outgoing messages. The sending server adds a DKIM-Signature header signed with a private key; receiving servers fetch the matching public key from the sender's DNS and verify that the message genuinely came from that domain and was not altered in transit. DKIM is defined in RFC 6376.

That is the short answer. The rest of this guide explains how the signing and verification actually work, what selectors and DNS records look like in practice, why DKIM tends to survive forwarding when SPF does not, and why DKIM on its own still leaves your domain open to spoofing until you add DMARC.

How does DKIM work?

DKIM is built on public-key cryptography. The domain owner (or, more often, their email provider) generates a key pair. The private key stays on the sending mail server. The public key is published in DNS as a TXT record, where anyone can read it.

When a message leaves the sending server, the server:

1. Selects the headers to sign (typically From, To, Subject, Date and a few others) and computes a hash of the message body.
2. Builds a DKIM-Signature header containing the signing domain, the selector, the list of signed headers, the body hash and other parameters.
3. Signs that data with the private key and places the resulting signature in the header.

When the message arrives, the receiving server reads the DKIM-Signature header, sees which domain and selector it claims, and looks up the public key at a well-known location in that domain's DNS. It then recomputes the hashes and checks the signature. If everything matches, the result is dkim=pass for the signing domain. If the body or a signed header has changed, or the key does not verify, the result is a fail.

Two things are worth noticing about this design. First, the receiver never needs any prior relationship with the sender: DNS is the trust anchor. Second, a pass proves two distinct facts: the message was authorised by whoever controls the signing domain's DNS, and the signed parts of the message have not been modified since signing.

What does a DKIM signature look like?

Every DKIM-signed message carries a DKIM-Signature header. A typical example, wrapped for readability, looks like this:

DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
  d=example.co.uk; s=mail2026;
  h=from:to:subject:date:message-id;
  bh=Kx8vP2rTqL0mN9wYcD3sHbF1jA6gU4eZoQiR7tXnVsM=;
  b=dGhpcyBpcyBub3QgYSByZWFsIHNpZ25hdHVyZSBidXQgaXQgbG9va3MgbGlrZSBvbmU...

The important tags are:

Tag	Meaning
v=1	The DKIM version. Always 1.
a=rsa-sha256	The signing algorithm. RSA with SHA-256 is the common choice; Ed25519 is also defined.
d=example.co.uk	The signing domain. This is the domain that takes responsibility for the message, and the domain DMARC alignment is checked against.
s=mail2026	The selector, which tells the receiver which public key to fetch.
h=from:to:subject...	The headers included in the signature. The From header must always be signed.
bh=...	The hash of the message body at signing time.
b=...	The signature itself, computed over the signed headers and the body hash.

The c=relaxed/relaxed tag sets the canonicalisation rules: how tolerant the verifier should be of harmless changes such as whitespace re-wrapping. Relaxed canonicalisation forgives minor formatting differences; simple canonicalisation requires a byte-for-byte match. Most senders use relaxed for both headers and body, precisely because mail servers along the path sometimes re-fold headers.

What is a DKIM selector?

The selector (the s= tag) is a label that lets one domain publish several DKIM keys at once. The receiver combines the selector and the domain to build the DNS name it queries: <selector>._domainkey.<domain>. For the example above, the lookup is:

mail2026._domainkey.example.co.uk

Selectors exist because real domains rarely have just one sender. Your mailbox provider signs with one key, your marketing platform with another, your invoicing system with a third. Each gets its own selector, so each key can be added, rotated or revoked independently without touching the others. Selectors also make key rotation straightforward: publish a new key under a new selector, switch signing over, then retire the old record.

Providers tend to use recognisable selector patterns. Microsoft 365 uses selector1 and selector2, Google Workspace defaults to google, and many sending platforms issue a pair of CNAME records that delegate the selector lookup to keys they host and rotate for you. There is more detail in our guide to DKIM selectors.

What does the DKIM public key in DNS look like?

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

mail2026._domainkey.example.co.uk.  IN  TXT
  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA..."

The p= tag holds the base64-encoded public key. A 2048-bit RSA key is the sensible default today; 1024-bit keys are still seen but are considered weak. Setting p= to an empty value is the standard way to revoke a key: verifiers treat the key as withdrawn.

Because the record is public, publishing it reveals nothing sensitive. Only the private key can create signatures; the DNS record only lets others verify them. What matters operationally is that the private key stays private. If a signing key leaks, an attacker can sign mail as your domain until you revoke and rotate it.

Does DKIM survive forwarding?

Usually, yes, and this is one of DKIM's most useful properties. When a message is forwarded, it is re-sent from a new server with a new IP address. SPF, which checks the sending IP against the original domain's policy, almost always fails on forwarded mail. DKIM does not care about the sending IP at all. The signature travels inside the message, so as long as the forwarder passes the message on without modifying the signed content, the signature still verifies at the final destination.

The signature breaks only when the signed content changes. Common causes:

• Mailing lists that add a subject-line prefix such as [listname], or append an unsubscribe footer to the body. Both invalidate the signature, because Subject is normally a signed header and the footer changes the body hash.
• Security gateways that rewrite links in the body for click-time scanning, or add scanning banners.
• Aggressive header rewriting by an intermediate server, if the sender used simple canonicalisation.

A modified body produces a body hash mismatch, one of the most common verification failures a DMARC report will show you. For the mailing-list case specifically, ARC (Authenticated Received Chain, RFC 8617) exists to let intermediaries record the authentication state they saw before modifying the message, though receiver support varies.

The practical takeaway: for mail that gets forwarded, DKIM is frequently the only authentication mechanism left standing, which is why a solid DKIM setup matters so much once you move your DMARC policy towards enforcement.

Why is DKIM alone not enough?

A DKIM pass proves that the signing domain authorised the message. It does not prove that the signing domain has anything to do with the domain the recipient actually sees in their mail client. Those are two different things, and the gap between them is exactly what spoofing exploits.

Consider a phishing message with this shape:

From: accounts@yourcompany.co.uk
DKIM-Signature: v=1; a=rsa-sha256; d=attacker-infra.example; s=key1; ...

The attacker signs the message with their own domain's key. DKIM verifies perfectly: the signature is valid for attacker-infra.example. But the recipient sees yourcompany.co.uk in the From header. DKIM has done its job (identifying who signed the message) yet the recipient is still deceived, because nothing in DKIM requires the signing domain to match the visible From domain.

This is the problem DMARC solves. DMARC adds two things on top of SPF and DKIM:

• Alignment. For DKIM to count towards a DMARC pass, the d= domain in the signature must match the From header domain (exactly in strict mode, or sharing the organisational domain in relaxed mode). The attacker's valid-but-unrelated signature no longer helps them. Alignment is explained in depth in our alignment guide.
• Policy. DMARC lets the domain owner publish what receivers should do with unaligned mail (none, quarantine or reject), and requests aggregate reports showing who is sending as the domain and how authentication is going.

SPF, DKIM and DMARC are designed as a set: SPF ties the sending server to a domain, DKIM ties the message content to a domain, and DMARC ties both back to the From address the human actually reads. The full picture of how the three work together is worth understanding before you tighten any policy.

How do you set up DKIM for a domain?

In most organisations you rarely generate keys by hand. The usual process, sender by sender, is:

1. Enable DKIM signing in the sending service. Your mailbox provider, marketing platform or transactional email service generates the key pair and keeps the private key on its infrastructure.
2. Publish the DNS records the service gives you. This is either a TXT record containing the public key, or (very commonly with third-party platforms) a pair of CNAME records pointing at keys the provider hosts. Add them in your DNS provider's control panel exactly as issued.
3. Verify and confirm. The service checks DNS and confirms signing is active. Send a test message to a mailbox you control and inspect the Authentication-Results header for dkim=pass with your domain in the d= value. That last part matters: a pass signed with the platform's own domain rather than yours will not align for DMARC.

Repeat for every service that sends mail as your domain. Finding all of those services is often the hardest part, and it is where DMARC aggregate reports earn their keep: they show every source sending as your domain and whether its DKIM is passing and aligned. A monitoring service such as DMARCHub turns those raw XML reports into a readable per-source view, so you can see which senders still need DKIM configured; see /features for how that works.

Frequently asked questions

Can a message have more than one DKIM signature?

Yes. RFC 6376 explicitly allows multiple DKIM-Signature headers, and it is common in practice: a sending platform may sign with its own domain for its reputation, and with your domain for DMARC alignment. Each signature is verified independently, and a receiver only needs one valid, aligned signature for DKIM to contribute to a DMARC pass.

Does DKIM encrypt my email?

No. DKIM signs, it does not encrypt. The message body travels in whatever form it was sent, and anyone who can read the message in transit or at rest can read its content. DKIM only provides integrity (the signed content was not changed) and authentication (the signing domain vouched for it). Transport encryption is handled separately by TLS between mail servers.

What happens if my DKIM record is missing or wrong?

Verification fails, or returns a neutral result, depending on the exact problem. If the selector lookup returns nothing, receivers cannot verify the signature at all. On its own that rarely blocks delivery, because unsigned mail is still commonplace, but it removes DKIM from your DMARC evaluation. If SPF also fails to align (for example on forwarded mail), the message fails DMARC and is treated according to your published policy.

How often should DKIM keys be rotated?

There is no fixed rule in the standard, but periodic rotation limits the damage window if a private key is ever exposed. Rotating once or twice a year is a common practice, and providers that manage keys via CNAME delegation typically rotate for you automatically. The mechanics of doing it without an outage (publish the new key, switch signing, retire the old selector) are covered in our key rotation guide.