Inboxpass All guides

Guides

How to set up DKIM for your domain

24 October 2026

To set up DKIM, you turn on signing in each service that sends mail for you, then publish the DNS record that service gives you, usually a TXT or CNAME at a name like selector._domainkey.example.com. Receivers use that record to check the signature on every message. You need one setup per sending service, and the signature has to be on your own domain for DMARC to count it.

What DKIM does

RFC 6376 defines DKIM. The sending service signs part of each message with a private key and adds a DKIM-Signature header. The receiver reads two values from that header:

It then looks up the public key in DNS at s._domainkey.d. Section 3.6.2.1 of the RFC says all DKIM keys live under the _domainkey subdomain. For d=example.com and s=google, the receiver queries google._domainkey.example.com. If the key verifies the signature, the signed headers and body were not changed after signing.

Selectors exist so one domain can have many keys at once. Section 3.1 says that is how you run several services side by side and how you rotate keys: publish the new one, switch, then retire the old one.

Why the signing domain matters

The RFC does not require d= to match the From address. Many services sign with their own domain by default, and that signature passes DKIM. It does not help your DMARC result, because DMARC needs the signing domain to align with the domain in the From header. The fix is the same for every provider: set up DKIM so the service signs with d= set to your domain.

That is also why the Gmail and Yahoo bulk sender rules keep coming back to alignment. An aligned DKIM pass is the sturdiest way to pass DMARC, because unlike SPF it usually survives forwarding.

Key length

RFC 8301, which updated DKIM in 2018, says signers must use RSA keys of at least 1024 bits and should use at least 2048. It also retired rsa-sha1: it must not be used for signing or verifying. Google requires at least 1024 bits for mail to personal Gmail accounts and recommends 2048 where your DNS host supports it.

Pick 2048 when the service offers a choice. The only common reason not to is a DNS host that cannot store a long TXT value.

Google Workspace

From Google’s Set up DKIM page:

  1. Sign in to the Admin console as a super administrator. Go to Menu, then Apps, Google Workspace, Gmail, and click Authenticate email.
  2. Choose your domain and click Generate New Record. Pick 2048 bits if your DNS host supports it, otherwise 1024.
  3. Leave the selector prefix as google unless the domain already has a key with that prefix.
  4. Copy the two values: the host name (google._domainkey) and the TXT value, which starts v=DKIM1; k=rsa; p=.
  5. At your DNS host, add a TXT record with that host name and value. Do not click Start authentication yet.
  6. Wait for DNS. Google says it can take up to 48 hours. The console may keep warning you to update DNS during that time.
  7. Back in Authenticate email, click Start authentication. The status should change to Authenticating email with DKIM.

Google adds two cautions. After turning on Gmail for a new domain, wait 24 to 72 hours before generating the key, or it may fail. And if you route outgoing mail through a gateway, make sure the gateway does not change messages in a way that breaks the signature.

Microsoft 365

Microsoft uses two CNAME records instead of a TXT, so it can rotate keys for you. From Microsoft’s DKIM article:

  1. In the Microsoft Defender portal, go to Email & collaboration, Policies & rules, Threat policies, Email authentication settings, and the DKIM tab.
  2. Select your domain and turn the toggle to Enabled. A Client error dialog is expected. Click OK, and the status changes to CnameMissing.
  3. Open the domain’s details and copy the two CNAME values under Publish CNAMEs.
  4. At your DNS host, create selector1._domainkey and selector2._domainkey as CNAME records pointing to those values.
  5. Return to the details and turn on Sign messages for this domain with DKIM signatures.

Microsoft’s notes that save time: copy the values exactly, because part of the target is assigned by Microsoft and you cannot build it by hand. Do not publish them as TXT records. On Cloudflare, set both records to DNS only. Microsoft says custom domains get no DKIM signing until you do this. Only the onmicrosoft.com domain is signed automatically, and that does not align with your own. The article also covers PowerShell (New-DkimSigningConfig and Set-DkimSigningConfig) and moving to 2048-bit keys during a rotation.

Every other sender

Newsletter tools, store platforms, help desks, and CRMs follow the same pattern. Look for a page called domain authentication, sender authentication, or DKIM in the service’s settings. It will give you one to three records:

Add exactly what the service shows, at exactly the names it shows. Then go back to the service and click its verify button. Many will not start signing with your domain until they see the records.

Each service gets its own selector, so records never collide. You can have google._domainkey, selector1._domainkey, and three others on the same domain. There is no limit like SPF’s ten lookups, because a receiver only fetches the one key named in each signature.

DNS host quirks

Check that it works

First confirm the record is visible:

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

Then send a message from that service to a Gmail address. Google’s DKIM page says not to test by emailing yourself. Open the message, choose More, then Show original, and find the Authentication-Results header. You want dkim=pass with header.d= set to your domain. If it shows the provider’s domain, the service is still signing as itself. Microsoft adds that messages between users in the same Microsoft 365 organization may not carry a signature, so test to an outside address.

If you have DMARC reports coming in, the auth_results section will show your selector and domain with a pass for that service’s IPs within a day or two. Our guide to reading DMARC reports shows where.

Rotating and retiring keys

To replace a TXT key, publish a new selector, switch the service to it, wait for mail signed with the old one to finish arriving, then remove the old record. RFC 6376 section 3.6.1 says a key record with an empty p= means the key has been revoked. That is how you shut off a selector you believe was exposed.

When you stop using a service, remove its DKIM records too. Microsoft also says not to publish DKIM records on parked domains that send no mail. Those should get v=spf1 -all and a DMARC reject policy instead.

Sources