DKIM adds a digital signature to every email you send. Your email provider signs each message with a private key, and publishes the matching public key in your domain's DNS. Receiving servers check the signature against that key: if it matches, the message really came from your domain and wasn't changed on the way.

Gmail and Yahoo have expected DKIM, along with SPF and DMARC, from bulk senders since 2024, and missing it is one of the quiet reasons ordinary business email lands in spam. It's also the record people most often get half right: the DNS records get added, but signing never gets switched on.

Start by checking your domain with our free DKIM checker. It shows which keys you already have, which service each belongs to, and whether any are broken.

How DKIM works, in 30 seconds

Every DKIM key has a selector, a short name chosen by the service that signs your mail. The public key lives at selector._domainkey.yourdomain.com. Each signed email carries a DKIM-Signature header with s= (the selector) and d= (the domain), so receivers know where to look.

That means every service that sends email as your domain needs its own key: your mailbox provider, your newsletter tool, your helpdesk. Google Workspace uses the selector google; Microsoft 365 uses selector1 and selector2.

Microsoft 365 (Office 365)

Microsoft 365 signs mail for your yourcompany.onmicrosoft.com address automatically, but not for your own domain until you publish two DNS records and switch signing on.

  1. Open the Email authentication settings page in the Microsoft Defender portal (Email & collaboration → Policies & rules → Threat policies → Email authentication settings) and select the DKIM tab.
  2. Click your domain to open its details. If it says No DKIM keys saved for this domain, click Create DKIM keys. (On some tenants you instead slide the domain's toggle to Enabled; Microsoft shows an error containing the records, which is expected. Click OK and reopen the domain.)
  3. Under Publish CNAMEs, Microsoft shows two CNAME records, for the hosts selector1._domainkey and selector2._domainkey. Their targets are unique to your organisation and end in either dkim.mail.microsoft (newer setups) or onmicrosoft.com (older ones). Copy them exactly as shown; never copy targets from another guide.
  4. Add both as CNAME records at your DNS provider.
  5. Wait a few minutes to an hour for Microsoft to see them, go back to the domain's details and switch on Sign messages for this domain with DKIM signatures.

The most common mistake: the two CNAMEs are published but step 5 never happened. DNS looks fine, yet nothing is signed. Our DKIM checker spots this: it finds the CNAMEs pointing at Microsoft with no key behind them.

Key size: older Microsoft 365 setups use 1024-bit keys. They still work, but 2048 bits is the current recommendation. Once signing is on, you can move to a 2048-bit key in Exchange Online PowerShell with Rotate-DkimSigningConfig -Identity yourdomain.com -KeySize 2048. Run our checker again a few days later to confirm the new key size.

Google Workspace

You need a Google Workspace super administrator account.

  1. In the Google Admin console, go to Menu → Apps → Google Workspace → Gmail → Authenticate email.
  2. Pick your domain under Selected domain and click Generate new record.
  3. Choose a 2048-bit key (only choose 1024 if your DNS provider can't store the longer record), keep the prefix selector google, and click Generate.
  4. Copy the host name (google._domainkey) and the TXT value, which starts with v=DKIM1. Don't click Start authentication yet.
  5. At your DNS provider, add a TXT record with that host and value. Most providers add the domain to the host for you, so enter just google._domainkey.
  6. Wait for DNS to update (Google says up to 48 hours, often much less), go back to Authenticate email and click Start authentication. The status changes to Authenticating email with DKIM.

If Google says "DKIM record was not created", Gmail was switched on too recently: Google asks you to wait 24 to 72 hours after turning Gmail on before generating a key. And until you click Start authentication, Gmail signs your mail with a default Google key rather than your domain's, which DMARC can't use.

Your other senders

Anything that sends email "from" your domain needs its own DKIM key: newsletter tools, CRMs, helpdesks, invoicing and e-commerce platforms. Look for a page called domain authentication, sender authentication or verified domains in that service. It gives you DNS records to add, usually CNAMEs, for example:

  • Mailchimp: CNAMEs at selectors like k2 and k3.
  • SendGrid: CNAMEs at s1 and s2.
  • Amazon SES: three CNAMEs with random-looking selectors.

Add them exactly as the service shows, then finish the verification step in the service itself. Each tool also needs to be in your SPF record.

Check that it works

  • Run the DKIM checker again. For a service with a random selector, enter the selector in the optional box.
  • Send an email to a Gmail address, open it and choose ⋮ → Show original. You should see DKIM: PASS with your own domain after d=.
  • Then make sure you have a DMARC record, which is what tells receivers to act on SPF and DKIM. Our DMARC checker tests all three at once.

Things that often go wrong

  • Signing never switched on (Microsoft 365) or Start authentication never clicked (Google Workspace). The records exist but nothing is signed.
  • A broken copy-paste. A key cut short, an extra space or quotes pasted into the value. The checker reports the key as unreadable; copy it again.
  • A 1024-bit key that was never upgraded. Rotate to 2048 when you can.
  • Test mode left on (t=y in the record). Receivers may ignore failures; remove it once mail is signing.
  • Records lost after a DNS move. When a domain moves to a new DNS host, CNAME and TXT records are easy to leave behind. Run the checker after any DNS change. Daily Website Report keeps watching your domain's SPF and DMARC records and mail blocklists, and emails you if your score drops.