What Is DKIM? Email Authentication for Business Explained

Email was built for a trusted academic network, and the protocol that carries it (SMTP) has no native way to verify who actually sent a message. Attackers have exploited that gap for decades: forging sender addresses, tampering with content in transit, and slipping fraudulent messages into real conversations. DKIM closes two of those gaps, and it is one of the highest-impact controls in any email security programme. Phishing remains the most common cyber threat facing UK businesses, according to the DCMS Cyber Security Breaches Survey 2025 — and most phishing relies on impersonating a trusted domain.

What is DKIM and how does it actually work?

DKIM uses public-key cryptography to prove a message is genuine. The domain owner generates a key pair: a private key held securely on the mail server, and a public key published in DNS. The sending server signs each message; the receiving server checks that signature against the published public key.

When a message is sent, the mail server uses the private key to sign specific components — typically the From header, the Subject, and the message body — and adds the result as a `DKIM-Signature` header. The receiving server retrieves the public key from a DNS TXT record and verifies the signature. A pass confirms two things at once: the message came from a server with access to the private key (an authorised sender), and the signed parts have not changed since signing.

That second property — tamper evidence — is what separates DKIM from SPF. SPF authorises *which servers* may send for your domain. DKIM proves the *content* arrived intact. You need both, plus a policy layer, which is where DMARC comes in.

What does DKIM sign — and what does it not protect?

DKIM signs only the message parts named in the `h=` tag of the `DKIM-Signature` header, usually the From header and the body. It does not sign every header by default, and it does not sign the SMTP envelope or delivery routing. So DKIM verifies content integrity, not the full delivery path.

This matters for your threat model. DKIM cannot stop an attacker modifying unsigned headers, adding new headers, or delivering from an unauthorised server — that last one is SPF's job. The three protocols are complementary, each covering a different failure mode:

• SPF — authorises legitimate sending sources by IP.
• DKIM — cryptographically signs the message so tampering is detectable.
• DMARC — tells receivers what to do when SPF and DKIM checks fail, and gives you reporting.

Treating any one of these as "email security done" is the most common mistake we see. They only deliver protection as a stack. The NCSC sets out the same layered approach in its email security and anti-spoofing guidance.

What are DKIM selectors and why do they matter?

A DKIM selector is a label that tells the receiving server which key to use for a given domain. Selectors let a single domain hold multiple DKIM keys — one for your primary mail server, another for a marketing platform — so you can rotate or revoke one key without disrupting the others.

The selector appears both in the `DKIM-Signature` header and in the DNS record name. A key with selector `selector1` on `amvia.co.uk` is published at `selector1._domainkey.amvia.co.uk`. Knowing your selector is essential when you audit or troubleshoot DKIM, because you cannot look up a record you cannot name.

Most businesses send from more than one platform — their tenant, a CRM, an invoicing tool, a newsletter service. Every one of those sending sources needs its own correctly published selector, or its mail fails authentication. Mapping all sending sources is the first step AMVIA takes on any email authentication build.

How do you set up DKIM in Microsoft 365?

Microsoft 365 signs all outbound mail with DKIM by default, but it uses Microsoft's own signing domain (`*.onmicrosoft.com`) — which does not align with your custom domain. To get DKIM working properly for your brand, you must enable custom-domain DKIM signing in the Microsoft Defender portal.

The process is short and well-documented:

1. In the Defender portal, go to Email & collaboration → Policies & rules → Threat policies → DKIM. 2. Select your custom domain and create the two CNAME records Microsoft provides in your DNS. 3. Enable DKIM signing for that domain once the records have propagated.

It typically takes under 30 minutes per domain, and you should enable it for *every* custom domain that sends mail through your tenant — including parked domains, which attackers love to spoof precisely because nobody checks them. Microsoft's DKIM configuration guide on Microsoft Learn walks through the exact steps. For broader hardening of the tenant around this, see AMVIA's Microsoft 365 security work and Microsoft Defender for Business.

Why does DKIM break with email forwarding?

Forwarding is DKIM's best-known limitation. When a server forwards a message, it may add a footer, rewrite headers, or alter the body — any of which invalidates the original signature. The DKIM check then fails at the final destination, even though the email is entirely legitimate.

This is exactly why DMARC evaluates *both* SPF and DKIM alignment rather than relying on one. If DKIM fails because of forwarding but SPF still passes (and aligns), DMARC can still return a pass and the message is delivered. Mailing-list software and DKIM-aware forwarding services mitigate the problem by preserving or re-signing the message.

When you read DMARC aggregate reports, forwarding is the single biggest source of "scary but harmless" DKIM failures. Knowing how to separate forwarding noise from genuine abuse is what lets you advance a DMARC policy safely instead of blocking your own invoices.

How does DKIM fit with SPF and DMARC?

DKIM delivers its full value only as part of a complete authentication stack. The correct order is: get SPF and DKIM configured and passing first, then deploy DMARC in monitoring mode (`p=none`) to observe results, identify failing legitimate sources, and only then progress to enforcement.

Enforcement matters: a published `v=DMARC1; p=reject` policy is what actually stops spoofed mail reaching inboxes. AMVIA configures complete email authentication stacks — Microsoft 365 DKIM, SPF record management, and staged DMARC advancement — as part of a broader phishing protection and managed cybersecurity programme. If you want a deeper look at the policy layer, read our explainer on what DMARC is and how to deploy it.