How DKIM works
DomainKeys Identified Mail uses a pair of matching keys. The private key stays inside your sending platform and signs each outgoing message, covering the body and a chosen set of headers. The matching public key is published in your domain’s DNS, where any receiving server can fetch it and verify the signature.
If the signature verifies, two things are established: the message really was signed by someone holding your domain’s private key, and nothing in the signed parts was changed on the way. If a single character shifts in transit, the signature no longer matches and the check fails.
Each key is published under a label called a selector, which is how one domain can run several keys at once — a marketing platform, a helpdesk and your own mail host can each sign with their own key without interfering. The selector appears in the message headers, so it is also how you work out which system actually sent a given message.
Why DKIM matters
It is the check that survives the journey. SPF validates the connecting server, so it breaks whenever a recipient forwards your mail to another address. A DKIM signature travels inside the message itself and keeps verifying through most forwarding, which makes it the more reliable of the two in ordinary use.
It is also what DMARC leans on. DMARC requires that an authenticated domain matches the domain your recipient sees, and DKIM gives it a durable way to establish that link. Without DKIM, a DMARC policy set to reject will start refusing your own legitimate forwarded mail.
Common mistakes with DKIM
The most common is never switching it on. Most platforms leave DKIM signing as an optional step that requires you to add records to DNS, and because mail sends perfectly well without it, the step gets skipped and forgotten until deliverability suffers.
The second is signing with the wrong domain. Some platforms sign with their own domain by default, which authenticates them rather than you, and DMARC will not accept it as alignment. You want the signature carrying your sending domain.
The third is treating keys as permanent. Keys should be rotated periodically, and a key left in place for years after a platform was abandoned is a live credential for a service nobody controls any more. Remove the DNS record when you remove the tool.
How to act on it
Enable DKIM in every platform that sends mail using your domain, one at a time, publishing each selector record before you switch signing on. Send a test message to a mailbox you control and inspect the headers to confirm the signature passes and the signing domain is yours rather than the vendor’s.
Keep a short written record of which selector belongs to which tool, because in a year nobody will remember, and unlabelled DNS entries are the reason old keys are never cleaned up. Rotate keys on a schedule your provider supports, and re-verify after any migration. Then set the full authentication set to work together — DKIM proves the message, SPF proves the route, and DMARC decides what to do when either falls down.