DomainKeys Identified Mail (DKIM, RFC 6376) is the cryptographic pillar of email authentication. While SPF asks "is this IP allowed to send?", DKIM asks a stronger question: "has this message been signed by someone who controls this domain, and has the signed content survived untouched?". This article explains what DKIM is, how it works under the hood, why UK businesses cannot rely on SPF alone, and how DKIM fits into the wider authentication stack.
DKIM is an email authentication mechanism that attaches a cryptographic signature to every outgoing message. The signature covers a selected set of message headers (always including From:) and a hash of the message body. The signer is the domain that claims responsibility for the message; its private key produces the signature, and its corresponding public key is published in DNS so that receiving mail servers can verify the signature independently.
In one sentence: DKIM proves that the holder of a private key controlled by the signing domain produced this message, and that the signed content has not been modified in transit.
Unlike SPF, which validates the sending server by its IP address, DKIM validates the message itself. This single architectural difference is what makes DKIM the stronger, more forwarding-resilient authentication layer — and why every UK business that cares about deliverability and brand protection needs DKIM alongside SPF.
SPF alone has three fundamental limitations that DKIM was built to address:
DKIM also introduces a property SPF cannot provide: non-repudiation. Because only the holder of the private key can produce a valid signature, a message with a valid DKIM signature from your domain cannot later be dismissed as "not really from us" without accepting that your private key has been compromised.
Follow a message sent from a Leeds accountancy firm to a customer at Gmail:
selector._domainkey.firm.co.uk. The selector is any name the administrator chooses — commonly a date-based rotation like 2026q2.From:; typically also Date, Subject, Message-ID, Content-Type and MIME-Version).relaxed/relaxed is the modern default.DKIM-Signature header to the message containing the signing domain, selector, algorithm, canonicalisation, signed header list, body hash and actual signature.DKIM-Signature header to extract the domain (d=firm.co.uk) and selector (s=2026q2).2026q2._domainkey.firm.co.uk and retrieves the public key.dkim=pass or dkim=fail) into the Authentication-Results header.The whole verification completes within a few hundred milliseconds during the SMTP handshake. DNS caching means repeat verifications against the same selector use cached keys rather than fresh queries.
A typical modern DKIM-Signature header from a UK business mail flow:
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=firm.co.uk;
s=2026q2; t=1712448000;
h=from:to:subject:date:message-id:content-type:mime-version;
bh=2jUSOH9NhtVGCQWNr9BrIAPreKQjO6Sn7XIkfJVOzv8=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
IEhY+sHo+QDSLLzc...The key tags:
| Tag | Meaning | Example value |
|---|---|---|
v= | DKIM version. Always 1. | v=1 |
a= | Signing algorithm. | rsa-sha256 or ed25519-sha256 |
c= | Canonicalisation — header/body. | relaxed/relaxed |
d= | Signing domain. | firm.co.uk |
s= | Selector. | 2026q2 |
t= | Signing timestamp (Unix). | 1712448000 |
h= | Signed header list. | from:to:subject:date:message-id |
bh= | Body hash (base64). | 2jUSOH9NhtVGCQWNr9BrIA... |
b= | Signature value (base64). | dzdVyOfAKC... |
Additional tags you may see:
i= — the agent or user on behalf of whom the message is signed. Rarely used in modern deployments.x= — signature expiry time. Rare; most signatures are valid indefinitely.q= — query method. Always dns/txt in practice; the tag is usually omitted.z= — copied header fields (signed at time of signing). Rarely used.l= — body length limit. Do not use — it permits appending arbitrary content below the signed portion, which is an injection attack surface.The DNS side of DKIM is a single TXT record published at selector._domainkey.domain. A typical record:
2026q2._domainkey.firm.co.uk. IN TXT "v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDK+..."The tags:
v=DKIM1 — version. Must be first if present. Can be omitted but best practice is to include it.k=rsa (or k=ed25519) — key type.p= — the public key, base64-encoded.Optional tags:
t=y — testing mode. Receivers treat failures as informational rather than actionable. Useful during deployment.t=s — strict mode. Signing domain must match exactly, no subdomain substitution. Unusual.n= — human-readable notes. Rarely used.h=sha256 — permitted hash algorithms.s=email — service type. Always email.To revoke a compromised key without removing the record (which might cause a race condition with in-flight messages), publish an empty p=:
old-selector._domainkey.firm.co.uk. IN TXT "v=DKIM1; k=rsa; p="Receivers treat the empty p= as "key revoked"; signatures against that selector fail verification.
DKIM originally supported RSA only. RFC 8463 added Ed25519 in 2018, and modern best practice is to use either RSA-2048 or Ed25519 — never RSA-1024.
The traditional default. Well-supported across every mail server and every receiver. The 2048-bit key produces longer signatures and larger DNS records (roughly 400 bytes of base64 for the public key), but these fit comfortably within DNS limits with EDNS0.
An elliptic-curve algorithm specified in RFC 8032. Produces much smaller keys (about 43 bytes of base64) and shorter signatures. Verification is faster than RSA. Modern support is strong across Gmail, Microsoft 365, Yahoo and most UK mail platforms including Axigen.
The usual UK deployment pattern is to publish both — a RSA-2048 key for legacy receivers plus an Ed25519 key for modern ones. Sign messages with whichever the sending server supports; receivers with dual DKIM support prefer Ed25519.
RSA-1024 is no longer considered adequate for new signatures. Microsoft and Google continue to accept verification against RSA-1024, but UK NCSC guidance and PCI DSS 4.0 both push for at least 2048-bit keys. Any UK business still signing with RSA-1024 in 2026 should rotate to RSA-2048 or Ed25519 as an immediate priority.
Canonicalisation is the process of normalising a message before hashing. It exists because minor transformations during mail transport — whitespace changes, header re-folding, encoding conversions — would otherwise break signature verification even when the substantive content is unchanged.
Two algorithms apply independently to headers and body:
Preserves content exactly as submitted. Strict — any modification breaks verification, including harmless whitespace changes.
Tolerates:
The canonicalisation pair is specified in the c= tag as header/body. c=relaxed/relaxed is the modern default and the recommendation for UK business deployments — it is forgiving enough to survive normal mail transport while still detecting substantive modification.
c=simple/simple is rarely used because it breaks on nearly every forwarder and many receivers. Mixed modes (simple/relaxed, relaxed/simple) are permitted but offer no practical advantage.
The selector is an administrator-chosen label that identifies which key was used to sign a particular message. A domain may publish many selectors simultaneously. The signing server chooses one per message based on local policy; the receiver uses the selector named in the signature header to find the correct public key.
Typical UK patterns:
2026q1, 2026q2, 2026q3, 2026q4 — one selector per quarter. Old selectors are retained for 30-60 days after rotation, then their public keys are emptied (p=).mail, marketing, transactional — separate keys per outbound service so compromise of one does not affect others.mailchimp.firm.co.uk, sendgrid.firm.co.uk — where a third-party provider signs on your behalf using their own infrastructure.Rotation hygiene is important. A key that has been in use for two years without rotation is a genuine security risk: if the private key is ever exfiltrated, signatures can be forged indefinitely. Quarterly rotation is the modern norm.
A valid DKIM signature proves two things:
selector._domainkey.d. Since the domain owner controls DNS, this proves the message was signed by a party the domain owner authorised.It does not prove:
From: aligns with the signing domain. DKIM itself does not check alignment — that is DMARC's job. A message can be validly DKIM-signed by a domain different from the From: domain, and DKIM considers it authentic.From: is accurate. For a Microsoft 365 tenant, an attacker with a valid Microsoft 365 mailbox can send DKIM-signed mail from their own domain that claims to be from any display name — DKIM verifies the domain is authentic, not that the human identity behind the mail is.A message can carry multiple DKIM-Signature headers. Each is independently verified by receivers, and DMARC alignment passes if any one signature aligns with the From: domain.
This matters when third parties sign on your behalf. A typical UK example: marketing mail sent via Mailchimp. Mailchimp signs the message with its own infrastructure DKIM key (using a CNAME-delegated selector under firm.co.uk), and optionally you can add a second signature from your own mail server if it relays through.
The critical configuration detail: the signer's domain (d=) must align with the From: domain. For Mailchimp to produce a DMARC-aligned signature on your behalf, you set up custom sending domain authentication so that Mailchimp signs with d=firm.co.uk rather than d=mcsv.net. Every reputable UK marketing and transactional provider supports this pattern.
DKIM features in nearly every UK email security framework:
DKIM emerged in 2004 from the convergence of two separate proposals: Yahoo's DomainKeys (2004) and Cisco's Identified Internet Mail. The combined protocol became RFC 4871 in 2007, then RFC 6376 in 2011. Ed25519 support followed in RFC 8463 in 2018. DMARCbis drafts under IETF discussion in 2026 do not change DKIM itself.
DKIM's ancestor, DomainKeys, was quickly adopted by Yahoo and Google in the mid-2000s. By 2010, every major UK receiver and most large UK senders (BT, Sky, Lloyds, HSBC) were using DKIM. Today, authentication-pass rates across the UK sit at around 95 % for top-tier domains, with DKIM contributing the majority of that authentication share.
From:. DMARC alignment is what closes that gap.Q: Do I need DKIM if I already have SPF and DMARC?
A: Yes. DMARC alignment requires either SPF or DKIM to pass — but SPF breaks on forwarding, so without DKIM your DMARC policy effectively forbids forwarding. DKIM is essential for any domain whose mail is ever forwarded, which in 2026 means essentially every UK business domain.
Q: How do I tell if my mail is being DKIM-signed?
A: Send a test message to an external mailbox (Gmail is convenient) and look at the raw headers in "Show original". You should see a DKIM-Signature header and an Authentication-Results header from the receiver showing dkim=pass.
Q: What happens if my DKIM selector's DNS record is missing?
A: Verification produces dkim=none or dkim=permerror. Receivers then rely entirely on SPF for DMARC alignment. On forwarded mail, SPF is likely to fail too, leading to DMARC failure.
Q: Does DKIM slow down my email sending?
A: Marginally. Signing with RSA-2048 takes a few milliseconds per message on modern hardware; Ed25519 is faster still. For high-volume senders this adds up but is rarely a practical concern — even a busy UK e-commerce site sending millions of messages per month will not notice the signing overhead.
Q: Can I sign with multiple keys simultaneously?
A: Yes — each message gets its own DKIM-Signature header per key. Receivers verify each independently. This is how the common "RSA + Ed25519" pattern works and how third-party signers (Mailchimp, SendGrid) coexist with your main mail platform's signature.
Q: Is DKIM compatible with end-to-end encryption (S/MIME, PGP)?
A: Yes. DKIM signs the outer envelope of the message; S/MIME and PGP encrypt the body or payload. They coexist — encrypted messages can also be DKIM-signed. Verification passes on the cryptographic structure, not on the readable content.
Q: What is the difference between d= and i= in a DKIM signature?
A: d= is the signing domain — the identity that takes responsibility for the message. i= is an optional local identity (a user or agent) within that domain. Most modern DKIM deployments omit i= entirely; it is rarely relevant for DMARC alignment or receiver filtering.
Q: How long should a DKIM public key stay in DNS after I rotate?
A: At least 30 days, ideally 60. Messages signed with the old key may still be in transit or archived at receivers that verify on re-delivery. After that window, publish an empty p= to revoke rather than deleting the record entirely.
Q: Are there any UK-specific considerations for DKIM deployment?
A: Public sector and NHS-adjacent organisations should follow NCSC guidance on key sizes and rotation cadence. Regulated financial services may be under FCA or PRA supervisory guidance that references email authentication controls. Most private-sector UK businesses can follow the standard best practice without UK-specific divergence.
Q: Can DKIM be used to prove a message in court?
A: It is legal evidence of origin and integrity, interpreted alongside other evidence. UK case law has accepted DKIM as supporting evidence in fraud and contract disputes. The usual caveat applies: DKIM proves a message was signed by the holder of the key, not that the signing was authorised by the organisation that owns the domain.
Q: What happens if a forwarder breaks DKIM?
A: Verification fails, DMARC alignment via DKIM fails, and unless ARC is in place the message fails DMARC altogether. For persistent breakage patterns, see the SPF and Email Forwarding article — the same ARC-based solutions apply to DKIM.