Skip to content

Guides · Email and DMARC

Set up DKIM for Google Workspace, Microsoft 365 and other senders

DKIM signs your email so receivers know it's really from you. How it works, how to set it up in Google Workspace and Microsoft 365, and how to check it.

Updated 30 October 2026 · 3 min read

DKIM adds a signature to every email you send. The receiving server looks up a public key in your DNS and checks the signature, which proves the message came from a server you authorised and wasn't changed on the way.

Together with SPF it's what DMARC relies on. Gmail, Yahoo and Outlook.com now require SPF, DKIM and DMARC from anyone sending more than 5,000 messages a day, and unsigned mail is treated with more suspicion everywhere.

How it works

Each sending service has a private key and signs with a selector, a name you choose or it gives you. The public key lives in a TXT record at:

<selector>._domainkey.<your domain>

For example google._domainkey.example.com. Several services can sign for the same domain at once, each with its own selector.

Use 2048-bit keys where the service offers a choice. RFC 8301 requires at least 1024 bits and recommends 2048.

Google Workspace

  1. In the Admin console go to Apps → Google Workspace → Gmail → Authenticate email.
  2. Pick the domain and Generate new record, with a 2048-bit key. The default selector is google.
  3. Add the TXT record it shows at your DNS host, as google._domainkey.
  4. Wait for DNS to update, then click Start authentication.

Until step 4, Gmail doesn't sign with your domain even though the record exists.

Microsoft 365

Microsoft 365 uses two selectors, selector1 and selector2, so a new key can be published before the old one is retired. You publish two CNAME records that point to keys Microsoft hosts:

selector1._domainkey.example.com  CNAME  selector1-example-com._domainkey.<tenant>.onmicrosoft.com
selector2._domainkey.example.com  CNAME  selector2-example-com._domainkey.<tenant>.onmicrosoft.com

Copy the exact targets from the Defender portal (Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM). They depend on your tenant, and domains added since May 2025 use a newer dkim.mail.microsoft format. Then turn on Sign messages for this domain with DKIM signatures. If it won't turn on, see Microsoft 365 DKIM won't enable.

Every other sender

Newsletters, CRMs, help desks and invoicing tools that send as your domain need DKIM too, or they fail DMARC once you enforce it. Look in each one's settings for "domain authentication" or "sender authentication": they give you one or more records, usually CNAMEs, to publish. Your DMARC reports list the services sending as you; see DMARC from none to reject.

Check it

Look up the key:

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

Then send an email to a Gmail address and choose Show original: the summary at the top shows DKIM: 'PASS' with domain example.com. If it names a different domain (such as onmicrosoft.com or the sending service's own), the message is signed but not with your domain, which doesn't count for DMARC.

Rotate keys

Replace keys every 6 to 12 months, and immediately if one may have leaked: publish a new selector, switch signing to it, then remove the old record a few days later. In Microsoft 365, run Rotate-DkimSigningConfig; it doesn't rotate on its own.

Check your domain

The DMARC checker shows whether your domain can be spoofed today, and the free scan checks SPF, DMARC and lookalike domains that could send as you.

Sources

Free scan

No signup. Only scan domains you own or manage.

More in Email and DMARC