What is DKIM? The tamper-proof seal on your email

If SPF is the guest list for your domain's email, DomainKeys Identified Mail (DKIM) is the wax seal on the letter itself: a mark that proves who sent it and shows whether anyone tampered with it on the way.

Of the three main email authentication standards, DKIM is the one with cryptography inside - which makes it sound intimidating. It is not. The concept fits in three sentences, and you never have to touch the mathematics. Here is how it works, where it goes wrong, and why it matters even though it is invisible to everyone involved.

The idea in plain English

DKIM uses a matched pair of keys - one private, one public.

• The private key lives on your sending system (your mail provider's servers, or a service that sends on your behalf). When an email goes out, that system uses the private key to generate a unique signature based on the message's content and headers, and attaches the signature to the email.
• The public key is published openly in your domain's DNS - the internet's directory - where anyone can read it.

When the email arrives, the receiving server fetches your public key and checks the signature. The mathematics guarantees two things at once: the signature could only have been produced by the holder of the private key (so the message genuinely came from your domain's authorised sender), and the signed content has not changed by a single character since signing (so nobody altered the message - or, say, the bank details in it - in transit).

If both hold: DKIM pass. If the signature is missing, does not verify, or the content was modified: no pass.

Recipients never see any of this. There is no padlock icon, no banner. DKIM works entirely between servers - but receivers such as Google and Microsoft weigh it heavily when deciding whether your email is genuine and whether it deserves the inbox.

Selectors: how one domain runs many signatures

A detail worth understanding because it appears in every setup guide: the selector. Your domain can publish multiple public keys, each filed under a name - the selector - and each signature says which selector to check it against.

This is what lets several systems send signed mail for one domain without sharing keys: Microsoft 365 signs with its selector, your newsletter platform with another, your invoicing software with a third. Each service's setup instructions ("add these CNAME records") are simply publishing that service's public key under its own selector. When a guide asks you to add records named something like selector1._domainkey, this is all that is happening.

Key rotation: why "set and forget" eventually breaks

Cryptographic keys age. The longer one key pair stays in use, the longer an attacker has to steal or crack it - so good practice is to rotate keys periodically: generate a new pair, publish the new public key, retire the old.

Reputable providers rotate keys for you automatically, which is convenient right up until the moment it is not. The classic failure: a service rotates its keys, but the DNS records in your domain were added by hand years ago as fixed values rather than the pointer records the provider asked for. The provider's new key does not match your published old one - and every email from that service silently starts failing DKIM. Nothing alerts you. Mail drifts towards spam folders, and the cause is invisible without monitoring.

What a DKIM failure means

Unlike a failed password attempt, a DKIM failure is ambiguous on its own. It can mean:

• Spoofing - the message never came from your systems and carries no valid signature;
• Misconfiguration - a legitimate sender whose key has rotated, whose DNS record is wrong, or which was never set up to sign at all;
• Modification in transit - something (often a mailing list or an overzealous gateway adding a footer) changed the message after signing, breaking the signature on genuine mail.

This ambiguity is precisely why DKIM does not act alone. It establishes evidence; it does not make the decision.

Why DKIM alone is not enough

DKIM has a mirror-image weakness to SPF's. SPF breaks when mail is forwarded; DKIM survives forwarding (the signature travels inside the message) - but DKIM says nothing about mail that simply omits a signature. A fraudster does not need to forge your signature; they can send unsigned mail displaying your domain, and DKIM alone gives the receiver no instruction to object. There is also no requirement that the signing domain match the From address the recipient sees.

DMARC (Domain-based Message Authentication, Reporting and Conformance) supplies both missing pieces: it requires the authenticated identity to align with the visible From address, tells receivers what to do when no aligned pass exists, and - through its daily aggregate reports - finally gives you visibility of every signature failure happening in your name. The full picture is in What is DMARC?, and the companion guest-list standard is covered in What is SPF?.

In practice the three work as a set: SPF lists your senders, DKIM seals your messages, DMARC enforces and reports. A domain with any one of the three missing or broken is a domain with a gap.

Find out whether yours is signing - and verifying

DKIM problems are the quietest of all email faults: everything appears to work, while authentication quietly fails on some or all of your mail. SealedMail's Free Domain Health Check examines your DKIM setup where discoverable, alongside SPF, DMARC, MTA-STS, TLS-RPT, BIMI and blacklist status, and emails you a clear, scored certificate in plain English. Free, no sign-up, no sales call - and if you would like every signature failure watched and explained weekly thereafter, that is what SealedMail's monitoring service does.