How to set up DKIM for your domain

Google Workspace

1. In the Google Admin console (admin.google.com), go to Apps → Google Workspace → Gmail → Authenticate email and select your domain.
2. Choose Generate New Record. Select a 2048-bit key if your DNS host supports it (1024 only if it does not), leave the prefix selector as google, and choose Generate. On a brand-new Workspace account, the key may not be available for 24 to 72 hours after Gmail is turned on.
3. At your DNS host, add a TXT record. Host: google._domainkey. Value: the long string beginning v=DKIM1; that Google shows.
4. Wait for the record to publish (Google allows up to 48 hours), then return to the same screen and choose Start authentication.

Microsoft 365

1. In the Microsoft Defender portal (security.microsoft.com), go to Email & collaboration → Policies & rules → Threat policies → Email authentication settings and open the DKIM tab.
2. Select your domain. If it says no DKIM keys are saved, choose Create DKIM keys first. The panel then lists two CNAME records under Publish CNAMEs, for selector1._domainkey and selector2._domainkey.
3. At your DNS host, add both as CNAME records (not TXT), copying the values exactly. Their format depends on when the domain was added to Microsoft 365 (newer domains point to dkim.mail.microsoft, older ones to onmicrosoft.com), so do not build them by hand.
4. Once they publish, return to the panel and turn on Sign messages for this domain with DKIM signatures.

Newsletters, CRMs and other senders

Mailchimp, HubSpot, Klaviyo, SendGrid, Mailgun, Postmark and similar services each have a domain authentication or sending domain screen. It lists the DNS records to add at your DNS host, often three or four, then a button to verify them. Most use CNAMEs for DKIM, but some (Postmark, and Mailgun unless you turn on Automatic Sender Security) use a TXT record, so copy each record type exactly as shown. Until you do, most of these services sign with their own domain, which does not count toward your DMARC, and some, like HubSpot, will not put your domain in the From address at all.

Find the selector you are using

Open an email you sent from each service. In Gmail, choose ⋮ → Show original; in Outlook, view the message source or headers. Find the DKIM-Signature lines (there may be more than one, because many services also sign with their own domain): s= is the selector and d= is the domain that signed. The key lives at <s>._domainkey.<d>, so for s=selector1; d=example.com:

dig +short TXT selector1._domainkey.example.com
dig +short CNAME selector1._domainkey.example.com

If none of the signatures shows your domain in d=, that service is not yet authenticated for your domain.

Common problems

• The host name is doubled. Many DNS hosts add your domain automatically, so entering google._domainkey.example.com publishes google._domainkey.example.com.example.com. Enter just google._domainkey.
• CNAME and TXT mixed up. Microsoft 365 and many marketing platforms use CNAMEs; Google, Postmark and Mailgun's standard setup use a TXT record. A TXT where a CNAME belongs (or the reverse) will not verify.
• The key is cut off. A single DNS text string holds at most 255 characters, and a 2048-bit key is longer. Some DNS hosts, such as Cloudflare, split it for you; others, such as Amazon Route 53, need the value entered as several quoted strings of up to 255 characters each, one after another. If the provider says the record is invalid, look up what your DNS host returns and compare it with the original.
• Published but never switched on. Google and Microsoft both need you to go back and start signing after the records publish.
• 1024-bit keys. They still pass, but the DKIM standard says signers should use 2048-bit keys, so rotate where the provider supports it. Microsoft 365's PowerShell default is 1024-bit: run Rotate-DkimSigningConfig -KeySize 2048 in Exchange Online PowerShell, then run it again once the first rotation finishes (about four days later) to upgrade the second selector.
• A revoked key still published. A DKIM record with an empty p= means the key has been withdrawn. If a service still signs with that selector, its mail fails DKIM. Publish a new key, or remove the record once nothing uses it.

Check it worked

Run WEBCHKR again. There is no way to list every DKIM key a domain has, so the DKIM Records check looks for keys under 73 selectors that common providers use, plus HubSpot selectors it can work out from your SPF record, and names the service each one probably belongs to. If your provider uses a custom selector, the check may not find it even though DKIM works. In that case, confirm it from the DKIM-Signature header of a message you sent, as above.