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
- In the Admin console go to Apps → Google Workspace → Gmail → Authenticate email.
- Pick the domain and Generate new record, with a 2048-bit key. The
default selector is
google. - Add the TXT record it shows at your DNS host, as
google._domainkey. - 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
- RFC 6376: DKIM signatures
- RFC 8301: DKIM cryptographic algorithm and key usage update
- Google Workspace: set up DKIM
- Microsoft: configure DKIM
- Google: email sender guidelines
- Yahoo: sender best practices
- Microsoft: Outlook's requirements for high-volume senders
- M3AAWG: DKIM key rotation best practices