How to set up DKIM in Microsoft 365 and Google Workspace

DKIM adds a cryptographic signature to the mail you send, so receivers can check it really came from your domain and wasn't changed on the way. Both Microsoft 365 and Google Workspace support it, but the setup differs: Microsoft uses two CNAME records, Google uses one TXT record. This guide covers both, step by step. For how signatures, selectors and keys work in general, see what DKIM is.

What does a DKIM record look like?

DKIM (RFC 6376) works with a key pair. Your mail platform signs outgoing mail with a private key. The matching public key sits in DNS at a name built from a selector and your domain:

<selector>._domainkey.<your-domain>

The signature header names the selector (s=) and the signing domain (d=). A receiver reads both, looks up the public key, and checks the signature. Section 3.6.2.1 of the RFC says all DKIM keys are stored under the _domainkey subdomain, and 3.6.2.2 says the record type is TXT. If you don't know which selector a service uses, how to find your DKIM selector shows how to read it from a message.

A published key looks like this (shortened):

google._domainkey.example.com.  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...IDAQAB"

An empty p= value means the key has been revoked.

CNAME vs TXT: why Microsoft and Google differ

Microsoft's two CNAMEs point at public keys it hosts. Microsoft explains that one selector is active and of the other: "It's activated and used only after any future DKIM key rotation" (Microsoft Learn). Because the key lives on Microsoft's side, you don't touch DNS when it rotates.

Google gives you the key itself. You paste it into a TXT record, so a new key means a new DNS change.

How to set up DKIM in Microsoft 365

Microsoft 365 automatically signs mail from your initial *.onmicrosoft.com domain. For a custom domain such as example.com, Microsoft says you need to configure DKIM signing yourself, and that DKIM passes DMARC only when the signing domain aligns with the From domain (Microsoft Learn).

Step by step in the Defender portal

1. Go to Email & collaboration > Policies & rules > Threat policies > Email authentication settings, or open https://security.microsoft.com/authentication, and select the DKIM tab.

2. Select your custom domain and slide the toggle to Enabled. The status changes to CnameMissing and an error shows the values you need.

3. Open the domain's details flyout and copy the two records from Publish CNAMEs.

4. At your DNS host, create both CNAME records. They follow this pattern:

   Host: selector1._domainkey
   Points to: selector1-example-com._domainkey.<initialdomain>.<x>-v1.dkim.mail.microsoft
   
   Host: selector2._domainkey
   Points to: selector2-example-com._domainkey.<initialdomain>.<x>-v1.dkim.mail.microsoft
   

   <initialdomain> is the prefix of your *.onmicrosoft.com domain, and <x> is a partition letter Microsoft assigns. Always copy the exact values from the portal. Microsoft says the examples it publishes "are for illustration only."

5. Wait for Microsoft to detect the records. Microsoft says this takes "a few minutes (or possibly longer)."

6. Return to the DKIM tab and enable signing. When it works, the status shows Valid and Rotate DKIM keys becomes available.

Custom domains added before Microsoft's May 2025 format change keep CNAME targets ending in onmicrosoft.com instead of dkim.mail.microsoft. Microsoft notes that the old and new formats can't coexist for the same selector, so use whatever your tenant shows.

Check the key size and move to 2048 bits

When you create a DKIM configuration in PowerShell with New-DkimSigningConfig, Microsoft documents the default key size as 1024 bits. RFC 8301 says signers "MUST use RSA keys of at least 1024 bits" and "SHOULD use RSA keys of at least 2048 bits." Check yours in Exchange Online PowerShell:

Get-DkimSigningConfig | Format-List Name,Enabled,Status,Selector1KeySize,Selector2KeySize,RotateOnDate

If the active selector shows 1024, rotate to 2048:

Rotate-DkimSigningConfig -Identity example.com -KeySize 2048

Each domain needs its own configuration

Every custom domain and subdomain that sends from Microsoft 365 needs its own two CNAMEs. Microsoft also advises against publishing DKIM records for parked domains that don't send email.

How to set up DKIM in Google Workspace

Google's steps are in Set up DKIM. Google says you need super administrator access and the Gmail Settings administrator privilege.

Before you start

If you've only just turned on Gmail, wait. Google says you must wait 24 to 72 hours after turning on Gmail before you can get your DKIM key.

Step by step

1. In the Google Admin console, go to Menu > Apps > Google Workspace > Gmail > Authenticate email.
2. Select your domain and click Generate New Record.
3. Choose a key length. Pick 2048 if your DNS host supports 2048-bit keys; pick 1024 only if it doesn't.
4. Leave the prefix selector as google, unless your domain already uses a DKIM key with that prefix.
5. Click Generate. Google shows a DNS host name such as google._domainkey and a TXT record value starting v=DKIM1;.
6. At your DNS host, create a TXT record with that host name and value. Don't click Start authentication yet.
7. Wait for DNS to update, then return to Authenticate email and click Start authentication. The status should change to "Authenticating email with DKIM."

Google says it can take up to 48 hours for DKIM authentication to start working after you add the key.

If your DNS host rejects a 2048-bit key

A 2048-bit public key is longer than 255 characters, the size of a single string in a TXT record. Google's troubleshooting guide says you can't enter a 2048-bit key as one string where that limit applies. Instead, split the key into several strings, each in its own quotes, in the same TXT record:

google._domainkey  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqh...first-part" "...second-part...IDAQAB"

RFC 6376 says receivers join these strings with no spaces in between. If your DNS host won't take a 2048-bit key at all, use 1024 bits for now and plan to move.

How to verify DKIM is working

1. Check DNS. Run the DKIM Checker with your selector: selector1 and selector2 for Microsoft 365, google for Google Workspace. Confirm the key resolves and the length is what you expect. If a checker can't find a selector, that selector is unknown, not necessarily broken: enter the exact selector your platform uses.
2. Send a test message to another provider. Google notes that sending a message to yourself won't verify DKIM. Send to a mailbox at a different provider.
3. Read the headers. Look for the Authentication-Results header. You want dkim=pass with header.d= (or header.i=) showing your own domain, not only a platform domain such as onmicrosoft.com. The Email Header Analyzer highlights this.
4. Confirm DMARC alignment. DKIM only helps DMARC when the signing domain matches your From domain. Check your policy with the DMARC Checker, and see SPF vs DKIM vs DMARC for how they fit together.

How to rotate DKIM keys

Keys should be changed regularly. M3AAWG recommends that "DKIM keys should be rotated at least every six months," and suggests a fixed schedule such as April and October.

Microsoft 365

1. In the DKIM tab, open the domain and select Rotate DKIM keys, or run Rotate-DkimSigningConfig.
2. Wait. Microsoft says it takes four days (96 hours) for the new key to start signing. Until then, the old one is used.
3. Check the s= value in a new message's DKIM-Signature header to see which selector is active.

You don't change DNS, because both CNAMEs already exist.

Google Workspace

Google's help doesn't describe a separate rotation feature. Generating a new record in Authenticate email creates a new key and updates the TXT value. To avoid a gap:

1. Generate the new key with a different prefix from the one in use, for example google2026b.
2. Publish the new TXT record and wait for it to resolve.
3. Start authentication with the new key.
4. Leave the old key in DNS for 7 to 30 days, as M3AAWG suggests, so messages already in transit can still be verified. Then revoke it by publishing the record with an empty p= value rather than deleting it. See DKIM key rotation for the full procedure.

Common DKIM mistakes

Next steps

1. Look up your current selectors with the DKIM Checker and note the key length.
2. If you're on Microsoft 365, run Get-DkimSigningConfig and rotate any 1024-bit key to 2048.
3. Put a six-monthly rotation reminder in the calendar.
4. For other senders that ask you to supply your own key, such as a mail server you run, create the key pair and TXT record with the DKIM Key Generator. Microsoft 365 and Google Workspace generate their own keys, so don't use it for them.
5. Once DKIM passes for every sender, plan your move to DMARC enforcement with our p=none to p=reject guide. If you send through a relay, iBlockSpam's outbound relay signs mail with DKIM too.

Browse our other SPF, DKIM and DMARC guides.