What Is DKIM? Email Authentication for Business Explained

The problem DKIM solves

Email was designed in an era when the internet was a relatively trusted academic network. The protocol that transmits email (SMTP) has no built-in mechanism to verify that a message was actually sent by who it claims, or that it was not modified in transit. These omissions have been exploited by attackers for decades: spoofing sender addresses, modifying email content during relay, and inserting fraudulent messages into legitimate email conversations.

DKIM — DomainKeys Identified Mail — addresses two of these problems: it provides evidence that an email was authorised by the domain owner, and it detects whether the message was modified after it was signed. Together with SPF and DMARC, it forms the foundation of modern email authentication.

How DKIM works

DKIM uses public-key cryptography. The domain owner generates a key pair:

• A private key is stored securely on the mail server (or with the email service provider)
• A public key is published as a TXT record in the domain's DNS

When a message is sent, the mail server uses the private key to create a digital signature of specific message components — typically the From header, Subject, and message body. This signature is added to the email as a DKIM-Signature header.

When the receiving server processes the message, it retrieves the sender's public key from DNS and uses it to verify the signature. If the verification passes, it confirms two things: the message was sent by a server with access to the private key (an authorised sender), and the signed components of the message have not been modified since signing.

What DKIM signs and what it does not

DKIM signs specific parts of the message defined in the h= tag of the DKIM-Signature header. Typically this includes the From header and the message body. It does not, by default, sign all headers or the delivery routing information (the SMTP envelope).

This means DKIM does not prevent all forms of email manipulation — for example, it cannot stop an attacker modifying unsigned headers or adding new headers. It also does not prevent an email being delivered from an unauthorised server (that is SPF's role). The three protocols work together, each addressing different aspects of email integrity and authenticity.

DKIM selectors

A DKIM selector is a label that identifies which DKIM key to use for a given domain. This allows a domain to have multiple DKIM keys — for example, one for the primary mail server and one for a marketing email platform — and to rotate or revoke individual keys without affecting others.

The selector is included in the DKIM-Signature header and in the DNS record name. For example, a key with selector selector1 on domain amvia.co.uk would be published at selector1._domainkey.amvia.co.uk.

DKIM in Microsoft 365

Microsoft 365 signs all outbound email with DKIM by default, using Microsoft's own signing domain (e.g., *.onmicrosoft.com). For proper DKIM authentication that aligns with your custom domain, you need to enable custom domain DKIM signing in the Microsoft 365 admin centre (Defender portal → Email & collaboration → Policies → DKIM).

Enabling custom domain DKIM in Microsoft 365 involves creating two CNAME records in your domain's DNS that point to Microsoft's key infrastructure, then enabling DKIM in the admin portal. The process typically takes less than 30 minutes and is straightforward to follow with Microsoft's documentation. DKIM signing should be enabled for every custom domain that sends email through Microsoft 365.

DKIM and email forwarding

A common DKIM consideration is email forwarding. When an email is forwarded by a mail server, the forwarding server may modify the message (adding a footer, changing headers), which breaks the DKIM signature. This is a known limitation and is why DMARC uses both SPF and DKIM alignment checks — if DKIM fails due to forwarding but SPF passes, DMARC can still pass.

Mailing list software and some email forwarding services are designed to be DKIM-aware and either preserve the original signature or re-sign the forwarded message. This is an important consideration when diagnosing DMARC authentication failures in DMARC aggregate reports.

Implementing DKIM alongside SPF and DMARC

DKIM is most valuable as part of a complete email authentication implementation. The correct order is: configure SPF and DKIM correctly first, then deploy DMARC in monitoring mode to review authentication results, identify any failing legitimate sources, and advance to a DMARC enforcement policy. AMVIA configures complete email authentication stacks for UK businesses, including Microsoft 365 DKIM setup, SPF record management and DMARC policy advancement.