How to Set Up DKIM on Microsoft 365 and Google Workspace

DKIM setup is one of the most skipped steps in business email. Both Microsoft 365 and Google Workspace can sign your outgoing mail with DKIM, but for your own custom domain neither does it fully on its own. You have to generate or enable the keys in the admin portal, publish DNS records, and switch signing on. Until you do, your mail either goes out unsigned or is signed for the provider's default domain rather than yours, which does not help with DMARC.

That matters more than it used to. Gmail and Yahoo require SPF, DKIM and DMARC for bulk senders, and Microsoft enforces similar rules for high-volume senders to Outlook.com addresses. Even below those volumes, aligned DKIM is one of the clearest signals that your mail is legitimate.

This guide walks through both platforms. If you need the background on how DKIM fits with SPF and DMARC, start with SPF, DKIM and DMARC Explained.

Before you start

You need three things:

• Admin access to the email platform. In Microsoft 365, a role that can manage email authentication settings in the Defender portal (such as Security Administrator or Global Administrator). In Google Workspace, a super administrator.
• Access to the DNS for your domain, wherever it is hosted: your registrar, Cloudflare, or another DNS provider.
• About 30 minutes of hands-on time, plus waiting time for DNS and the provider to pick up the records.

Do one domain at a time and test before moving to the next. If you have several domains, list them all first, including any that only receive mail or are used as aliases.

DKIM setup on Microsoft 365

Microsoft 365 uses two CNAME records per domain, named selector1 and selector2. They point to keys Microsoft hosts, which lets Microsoft rotate keys without you touching DNS again.

Step 1: open the DKIM settings

Sign in to the Microsoft Defender portal at security.microsoft.com and go to Email & collaboration, then Policies & rules, then Threat policies, then Email authentication settings, and open the DKIM tab. The direct address is https://security.microsoft.com/authentication.

You will see each domain in your tenant. Your onmicrosoft.com domain is already signed by default. Your custom domains will typically show as not signing.

Step 2: get the CNAME values

Select your custom domain. If it has no keys yet, turning on the toggle will create them and show you the two CNAME records to publish (the status will read CnameMissing until DNS is in place). Open the domain's details to see the values under the publish CNAMEs section.

The records follow this shape:

Host: selector1._domainkey
Type: CNAME
Points to: selector1-example-com._domainkey.<tenant>.<x>-v1.dkim.mail.microsoft

Host: selector2._domainkey
Type: CNAME
Points to: selector2-example-com._domainkey.<tenant>.<x>-v1.dkim.mail.microsoft

The hostnames are the same for every organization. The targets are specific to your tenant. Domains added before mid-2025 may show an older format ending in onmicrosoft.com. Do not build the values by hand. Copy them exactly from the portal.

Step 3: publish both CNAMEs

Add both records at your DNS provider. Publish both even though only one is active at a time, since Microsoft switches between them when it rotates keys.

Two common mistakes:

• Some DNS providers automatically add your domain to the host name. Entering selector1._domainkey.example.com in those interfaces creates selector1._domainkey.example.com.example.com. Enter just selector1._domainkey if that is how your provider works.
• If you use Cloudflare, set these records to DNS only, not proxied. (Cloudflare does not proxy records that do not point to a web server, but check the toggle anyway.)

Step 4: turn on signing

Wait for DNS to update. This is often a few minutes but can take longer. Return to the DKIM tab, open the domain, and turn on the option to sign messages for the domain with DKIM signatures. When it works, the status changes to show the domain is signing.

If you prefer PowerShell, Exchange Online PowerShell has Get-DkimSigningConfig to check status and the CNAME values, and Set-DkimSigningConfig -Identity example.com -Enabled $true to turn signing on once the records resolve.

Step 5: consider key length and rotation

Microsoft supports 1024-bit and 2048-bit keys. You can move to 2048-bit by rotating the keys with Rotate-DkimSigningConfig -Identity example.com -KeySize 2048, or rotate from the portal. A rotation takes about four days to complete, and the old key keeps signing in the meantime. The full reference is Microsoft's guide to setting up DKIM for a Microsoft 365 domain.

DKIM setup on Google Workspace

Google Workspace uses a single TXT record that contains the public key. The default selector is google.

Step 1: generate the key

In the Google Admin console, go to Apps, then Google Workspace, then Gmail, and open Authenticate email. Choose your domain from the selected domain menu and click Generate New Record.

Choose a key length. Use 2048 if your DNS provider supports it, which most do. Use 1024 only if your provider cannot store a key that long. Leave the prefix selector as google unless your domain already uses that selector for something else. Click Generate.

If you just turned on Gmail for the domain, Google notes you may need to wait 24 to 72 hours before the key can be generated.

Step 2: publish the TXT record

Google shows a DNS host name and a TXT value. Do not click Start authentication yet. Add the record at your DNS provider:

Host: google._domainkey
Type: TXT
Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqh...(long key)...

A 2048-bit key is longer than the 255-character limit for a single TXT string. Most modern DNS providers split it automatically. Some older ones require you to break it into quoted chunks yourself. If DKIM later fails, a truncated or mangled key is the first thing to check.

Step 3: start authentication

Return to Authenticate email, select the domain and click Start authentication. When it works, the status reads "Authenticating email with DKIM." Google says DKIM can take up to 48 hours to start working after you add the record, and the console may show a DNS warning during that window. Google's own walkthrough is Set up DKIM.

Each domain needs its own key. If you have secondary domains in the same Workspace account, repeat the steps for each one.

Test that DKIM is working

Send a message from the domain to a mailbox on the other platform (for example, from Microsoft 365 to a Gmail address) and open the full headers. In Gmail, use Show original. Look for two things:

• A DKIM-Signature header with d=example.com, your domain, and the expected selector in s=.
• An Authentication-Results line showing dkim=pass for your domain.

If DKIM passes but for onmicrosoft.com or another provider domain instead of yours, signing is still on the default domain. Go back and make sure signing is enabled for the custom domain.

You can also look up the DNS record directly with any DNS lookup tool: query the CNAME at selector1._domainkey.example.com for Microsoft, or the TXT at google._domainkey.example.com for Google.

Common problems and fixes

That last row is the one most businesses hit. Your mailboxes are only one sender. Marketing platforms, CRMs, helpdesks and website forms all need their own DKIM records. We cover those in the SPF, DKIM and DMARC guide.

After DKIM: finish the job

DKIM on its own does not tell receivers what to do with failures. Once DKIM is passing for every sender, publish or tighten your DMARC record, read the reports for a few weeks, and move toward an enforced policy. Our guide to reading DMARC reports explains what to look for.

We set up SPF, DKIM and DMARC across mixed environments, with some domains on Microsoft 365, some on Google Workspace, and marketing and form senders on top. If you would rather hand it off, our email and domain security service covers the DNS changes, the platform settings and testing for every domain you own.

Frequently asked questions

Do I need DKIM if I already have SPF?

Yes. SPF often breaks when mail is forwarded, and it is checked against the bounce address rather than the visible From address. DKIM survives forwarding better and aligns directly with your domain. Gmail, Yahoo and Microsoft require both for higher-volume senders.

Why does Microsoft use CNAME records and Google uses TXT?

Microsoft hosts the keys itself and points your CNAMEs at them, so it can rotate keys without DNS changes on your side. Google gives you the public key to publish directly as a TXT record, and you generate a new one when you want to rotate.

Should I use a 1024-bit or 2048-bit key?

Use 2048-bit where your DNS provider supports it. It is the stronger option and is widely supported. In Microsoft 365, you can move to 2048-bit through a key rotation.

How long does DKIM take to start working?

DNS changes often show up within minutes but can take longer. Microsoft enables signing once it detects the CNAMEs. Google says to allow up to 48 hours after adding the record.

Can I use DKIM on Microsoft 365 and Google Workspace for the same domain?

Yes, if both send mail for the domain. Microsoft uses the selector1 and selector2 names and Google uses google, so the records do not conflict. Each platform signs its own mail.