How to Create DKIM Record Keys for Any Email Provider
Every guide on how to create DKIM record entries has to start by correcting the search itself: you do not write a DKIM record the way you write an SPF record. A DKIM record is the public half of a cryptographic key pair, and the private half must live inside whatever system actually sends your mail - so the sender generates the pair, and your job is to take the public half it hands you and publish it in DNS. Trying to author one by hand in a DNS panel, without a sender holding the matching private key, produces a record that authenticates nothing.
That correction turns the task into a simple, repeatable flow that looks the same at every provider: generate in the sender's console → copy the DNS records it produces → publish them at your DNS host → return to the console and activate. Here is that flow at each of the places you are likely to run it.
Google Workspace
Google generates a key you paste as a TXT record:
- In the Admin console, go to Apps → Google Workspace → Gmail → Authenticate email.
- Select the domain and click Generate new record. Choose 2048-bit key length (the default and the right answer; only drop to 1024 if your DNS host genuinely cannot store long TXT values - most can).
- Google shows a hostname -
google._domainkey- and a TXT value beginningv=DKIM1; k=rsa; p=.... Create exactly that record at your DNS host. - Wait for DNS to propagate - Google says up to 48 hours, though most hosts resolve in minutes - then return to the same screen and click Start authentication.
The classic Google-specific stumble is clicking Start authentication immediately and getting an error because the record hasn't propagated; the button is not a save, it is a live DNS check. The second stumble is skipping the whole errand because mail "already works" - without your own key, Gmail signs with a generic domain, which fails DMARC alignment for yours.
Microsoft 365
Microsoft never shows you a key at all - you publish two CNAME records that point into Microsoft's zone, and they rotate the real keys behind them:
- In the Microsoft Defender portal, open Email authentication settings → DKIM.
- Select your custom domain. The panel displays two CNAMEs:
selector1._domainkeyandselector2._domainkey, each targeting a hostname ending inonmicrosoft.com. - Create both CNAMEs at your DNS host, exactly as shown.
- Back in the panel, flip Sign messages for this domain with DKIM signatures to enabled. If you get a "CNAME record does not exist" error, the records haven't propagated yet - wait and retry rather than re-creating anything.
Two selectors are not redundancy theater: one carries the live key while the other stages the next rotation, which is why both must exist before the toggle will engage.
Sending platforms: newsletters, transactional, CRMs
Every serious sending platform runs the same ceremony under a heading like Verify your domain or Authenticate your domain. The dashboard generates the keys the moment you add the domain and presents DNS records to publish - most commonly two or three CNAMEs (the Microsoft-style delegation, so the platform can rotate keys without you), occasionally a raw TXT key. Publish them, click the platform's Verify button, and the dashboard confirms each record with a green check.
The one decision point worth attention here is which domain signs. Platforms can deliver your mail signed with their own shared domain - it works, but DMARC alignment then belongs to them, not you. Completing the platform's domain authentication so signatures carry d=yourdomain.com is precisely what this whole errand is for; treat "we sign on your behalf with our domain" as an onboarding shortcut to graduate from, not a destination.
Self-hosted mail servers
Running your own Postfix or Exim means running the generator yourself. With OpenDKIM installed:
opendkim-genkey -b 2048 -d yourdomain.com -s 2026a
That emits two files: 2026a.private (the private key, which goes into your OpenDKIM key table and must never leave the server) and 2026a.txt - a ready-to-paste DNS TXT record at 2026a._domainkey. Wire the selector and key path into OpenDKIM's configuration, hook OpenDKIM into your MTA as a milter, publish the TXT, and send a test. Dated selector names (2026a) pay off the day you rotate: generate 2027a, publish it, switch signing, and retire the old record after in-flight mail clears.
Where the record lands, whoever generated it
At your DNS host the mechanics are the same as any record: type TXT (or CNAME when that's what you were given), Host set to the selector plus ._domainkey - watching for panels that auto-append your domain - and the value pasted whole. Long 2048-bit keys exceed the 255-character TXT string limit and get split into concatenated quoted chunks; good DNS hosts do the splitting silently, and a key that arrives mangled shows up as a copy-paste-shaped verification failure.
| Provider | Where you generate | What you publish |
|---|---|---|
| Google Workspace | Admin console → Gmail → Authenticate email | 1 TXT at google._domainkey |
| Microsoft 365 | Defender portal → DKIM settings | 2 CNAMEs, selector1/2._domainkey |
| Sending platforms | Dashboard → domain verification | usually 2-3 CNAMEs |
| Self-hosted | opendkim-genkey on the server |
1 TXT at <selector>._domainkey |
Verify, and the two habits that prevent regressions
Confirm the record resolves - dig TXT <selector>._domainkey.yourdomain.com - then send a real message from the real service to a Gmail address and read Show original: you want DKIM: PASS with yourdomain.com named as the signing domain, not the platform's.
Habit one: selectors coexist - never clean up another service's records. Google's key, Microsoft's CNAMEs, and two platforms' selectors can all live under _domainkey simultaneously; each service finds its own by name. Deleting a selector you don't recognize is how a working integration silently stops authenticating - identify before you tidy.
Habit two: treat DKIM as one leg of three. A passing signature plus an SPF record plus a DMARC policy is the stack Gmail and Yahoo's sender requirements now assume; DKIM is the leg that survives forwarding and the one DMARC alignment most often rides on. Once each sender you use signs with your domain and Show original comes back green across all of them, this errand is done - and with CNAME-based providers, done means done for years.
Frequently asked questions
Can I create a DKIM record without my email provider?
No - the record is the public half of a key pair, and the private half must live in the system that sends your mail. Generate the pair in the sender's console (or with opendkim-genkey on your own server) and publish the DNS half it gives you.
How long until a new DKIM record works?
DNS usually propagates in minutes, though Google quotes up to 48 hours. Activation buttons like Google's Start authentication and Microsoft's DKIM toggle perform a live DNS check, so a too-early click just needs a later retry.
Should I choose a 1024-bit or 2048-bit DKIM key?
2048-bit. It has been the recommended strength for years; choose 1024 only if your DNS host cannot store long TXT values, and treat that as a reason to consider a better DNS host.
Do I delete the old DKIM record when adding a new service?
No. DKIM records are per-selector and coexist by design - Google, Microsoft, and multiple platforms can all hold keys under _domainkey at once. Only retire a selector when the service that owns it is decommissioned.