How to Generate a DKIM Record
You don't hand-write DKIM keys - your mail provider generates the public/private key pair when you enable DKIM. You publish the public key it gives you as a TXT record at the provider's chosen selector, then verify it resolves.
This guide is part of our complete guide to DKIM. Related: the DKIM record and the DKIM selector.
You don’t hand-write DKIM keys — your mail provider generates the public/private key pair for you. You then publish the public key in DNS as a TXT record at the selector host your provider chooses, and the provider keeps the private key to sign your outgoing mail. That single publish-and-verify loop is all “generating a DKIM record” really means.
Why you generate DKIM in your provider, not by hand
DKIM works with a matched pair of cryptographic keys. The private key stays inside your sending platform and signs every outbound message; the public key goes into DNS so receiving servers can verify that signature. Because the private key must live securely inside the system that actually sends your mail, your provider is the only place that can generate the pair correctly. It creates both keys, stores the private half where its signing engine can reach it, and hands you the public half to publish.
That’s why there’s no real “DKIM generator” step you do yourself. Enabling DKIM in your console does the generation; you just publish the result. Advanced users running their own mail server can generate a key pair manually with openssl (for example openssl genrsa plus a matching public-key export), but unless you operate your own MTA, stick to the provider path — it’s faster, less error-prone, and keeps the private key where it belongs.
Step-by-step: generate and publish DKIM
- Enable DKIM (email authentication) in your provider console. Look for a “DKIM,” “email authentication,” or “domain authentication” setting for your sending domain. Turning it on triggers key generation.
- Read the output: a public key plus a selector host. The provider gives you a public key and the exact hostname (the selector, like
s1._domainkey.yourdomain.com) where it must be published. - Publish the TXT record in your DNS. Add a TXT (or sometimes CNAME) record at that selector host with the value your provider supplied. See the DKIM record for the exact format, tags, and how the value is structured.
- Verify with the free DKIM lookup tool. Enter your domain and selector to confirm the public key is live and readable in DNS. DNS changes can take a little time to propagate, so re-check if it isn’t found immediately.
- Confirm mail is being signed. Send a test message and inspect the headers (or your provider’s dashboard) for a
DKIM-Signatureheader and adkim=passresult. That confirms the private key is signing and the public key verifies.
Where to generate DKIM in common providers
| Provider | Where to generate DKIM |
|---|---|
| Google Workspace | Admin console > Apps > Google Workspace > Gmail > Authenticate email |
| Microsoft 365 | Microsoft Defender portal > Email & collaboration > Policies > Email authentication settings > DKIM |
| ESPs (SendGrid, Mailchimp, etc.) | Auto-provided during “domain authentication” — the platform generates keys and gives you the records to publish |
For Google Workspace and Microsoft 365 you generate the key, then publish the record they show you. For most ESPs, domain authentication bundles DKIM (often alongside SPF and a tracking domain), so you simply add the records they list.
Key length: 1024 vs 2048
When your provider offers a choice, pick 2048-bit keys. They’re meaningfully stronger than 1024-bit and are now the recommended default across the industry. The one caveat is that a 2048-bit public key is longer than a 1024-bit one, and some older DNS interfaces struggle with TXT records over 255 characters — they may need the value split into multiple quoted strings. Most modern DNS hosts handle this automatically. If your provider only offers 1024-bit, that still works, but move to 2048-bit when you can.
Keep it healthy
DKIM isn’t set-and-forget. Rotate your keys periodically — many providers now rotate automatically — so a single compromised key can’t be abused indefinitely. And remember that DKIM is one leg of a three-part stack: a valid SPF record, DKIM, and DMARC work together to prove your mail is legitimate. If any leg is broken, deliverability suffers.
On the SPF side, watch the 10-lookup limit that causes SPF to fail silently once your record references too many services. AutoSPF flattens and maintains your SPF record so it stays under that limit automatically, letting you keep DKIM and DMARC focused on the signing and policy side without SPF quietly breaking underneath them.
Frequently Asked Questions
How do I generate a DKIM record?
You generate a DKIM record by enabling DKIM or email authentication inside your mail provider’s console. The provider creates the key pair and gives you a public key plus a selector host. You then publish that public key as a TXT record in your DNS and verify it, which completes the setup.
Do I need a DKIM generator tool?
Usually no. Your mail provider generates the key pair for you when you enable DKIM, so a standalone generator is redundant and can even be risky if it exposes the private key. Only self-hosted mail servers need manual generation, typically with openssl. For everyone else, the provider console is the correct and safest path.
What key length should I use for DKIM?
Use 2048-bit keys whenever your provider offers the choice, as they are stronger than 1024-bit and are the current industry recommendation. The only downside is a longer DNS value that some legacy DNS interfaces may need split across multiple strings. Most modern DNS hosts handle 2048-bit records without any extra steps.
Where do I put the DKIM record after generating it?
You publish it in your domain’s DNS as a TXT record at the exact selector host your provider specifies, such as selector._domainkey.yourdomain.com. The record value is the public key your provider supplied. After adding it, verify with a DKIM lookup tool to confirm it is live and readable before relying on it.