On this page
What DKIM does
DomainKeys Identified Mail (DKIM) signs outgoing messages with a private key held by the sending server. The matching public key is published in DNS under a selector, for example selector1._domainkey.yourdomain.com. The receiving server fetches the key, checks the signature, and knows the signed headers and body haven’t changed since signing.
Unlike SPF, DKIM usually survives forwarding, and it signs with a domain you choose. That makes it central to DMARC and to building a domain reputation that follows you across providers.
Because the signature is tied to a domain rather than an IP, DKIM is also how mailbox providers attach reputation to your brand. Mail signed consistently with your own domain builds a history that stays with you when you change servers or providers.
Signs DKIM needs attention
- Headers show dkim=none or dkim=fail for some of your mail.
- Messages pass DKIM but with the provider’s domain, not yours, so DMARC doesn’t align.
- Keys are 1024-bit and have never been changed.
- Nobody knows which selector belongs to which service.
- A new sending tool was added without anyone publishing its key.
Passing is not the same as aligning
Many platforms sign your mail with their own domain by default. That signature passes, but DMARC requires the signing domain (the d= value) to match your From domain, either exactly or at the organisational level under relaxed alignment. A setup that passes but doesn’t align won’t satisfy DMARC, and won’t build your own domain reputation. Configuring custom DKIM on each platform fixes this.
What’s included
- An inventory of every sending source and how each signs today.
- Custom DKIM on each platform, signing with your domain or the right subdomain.
- 2048-bit keys where the platform and DNS host support them.
- Clear selector naming so each key is traceable to its service.
- DNS publication, including splitting long keys correctly where the host requires it.
- Verification from real messages: dkim=pass with header.d matching your From domain.
- A written rotation plan for self-hosted keys.
How we deliver it
- Review DMARC reports and headers to see which sources sign, fail or don’t align.
- For hosted platforms, enable custom DKIM and publish the records they provide.
- For your own servers, generate keys with OpenDKIM or Rspamd and configure signing.
- Publish records and confirm they resolve correctly from several resolvers.
- Send test mail from each source and check the Authentication-Results header.
- Document selectors, key locations and the rotation schedule.
Key rotation without breaking mail
Rotating keys limits the impact if a private key is ever exposed. The safe method is to publish a new selector, switch signing to it, and keep the old public key in DNS for a period so messages already in transit still verify. We agree a rotation interval that suits your setup and document the steps so it doesn’t depend on memory.
DKIM works with SPF and DMARC. All three are expected by Gmail and Yahoo for bulk senders, as part of sending permission-based mail responsibly.
What affects timeline and cost
- Number of sending sources and domains.
- Whether each platform supports custom DKIM.
- DNS host limitations on record length.
- Self-hosted servers that need signing configured.
Common DKIM mistakes
Publishing a key with a typo or a truncated value. Pasting a record into the wrong host name, so the selector doesn’t resolve. Deleting an old selector the moment a new one is live. Leaving 1024-bit keys in place indefinitely. Assuming the platform’s default signature is enough for DMARC.
Another frequent issue is a gateway or signature-adding tool that modifies messages after signing, for example by appending a disclaimer. The change breaks the signature, so the message fails DKIM even though the keys are correct. We check the full path a message takes, not just the signing server.
Read the guide, browse all email infrastructure services, or contact us.
Frequently asked questions
What key length should we use?
2048-bit is the current common recommendation. Some DNS hosts need long keys split into several strings, which we handle.
Can we have multiple DKIM keys?
Yes. Each sending service uses its own selector, so many keys can coexist on one domain.
How often should keys be rotated?
There is no single rule. We agree an interval based on your setup and risk, and rotate with overlap so nothing breaks.
Why does DKIM fail on some messages?
Common causes are mailing lists or gateways that modify the message, a missing or wrong DNS record, or a server signing with the wrong key.
Do third-party platforms support custom DKIM?
Most reputable ones do, usually by asking you to publish CNAME or TXT records they provide. Where a platform doesn’t, we look at alternatives such as sending through a subdomain or a different service.
Talk to us about dkim configuration
Cryptographic signing so receivers can verify your mail wasn't altered in transit.