How to Set Up DKIM for Google Workspace and Microsoft 365

Most broken DKIM setups aren't missing. They're half-finished. Someone pasted a TXT record into DNS and never clicked "Start authentication" in the Google Admin console. Or a Microsoft 365 tenant is happily signing every message with the tenant's onmicrosoft.com domain instead of the custom domain in the From line — which looks like a pass in the headers and still fails DMARC alignment.

If you're sending cold email, this matters more than it does for normal business mail. Recipients you've never contacted before get judged almost entirely on authentication, domain reputation, and content. An unsigned or misaligned message starts the evaluation in a hole. Here's exactly how to set DKIM up on both major providers, how to verify it actually works, and the eight things that most commonly break it.

{"h2":"What DKIM actually does"}

DKIM adds a cryptographic signature to the message header. Your provider signs outbound mail with a private key; receivers look up the matching public key in DNS at `selector._domainkey.yourdomain.com` and verify the signature hasn't been tampered with in transit.

Two things to understand before you touch DNS:

{"ul":["The signature carries a `d=` value — the signing domain. That's the domain that gets credit (or blame) for the message, and it's what DMARC compares against your From address.","DKIM survives forwarding; SPF usually doesn't. When a recipient auto-forwards your email to another address, SPF breaks but a valid DKIM signature still passes. That alone makes it worth doing properly."]}

DKIM does not encrypt anything and does not prove the sender is trustworthy. It proves the message came from someone authorized to sign for that domain and arrived intact.

{"h2":"Google Workspace: step by step"}

Google generates the key for you. The whole thing takes about ten minutes plus DNS propagation.

{"ul":["In the Admin console, go to Apps → Google Workspace → Gmail → Authenticate email.","Select the domain you want to sign. If you send cold email from a separate domain, make sure you pick that one — not your primary domain. The dropdown only lists domains added to the account.","Choose a 2048-bit key length. Use 1024 only if your DNS host chokes on long TXT values (some legacy registrars cap records at 255 characters without auto-splitting).","Leave the prefix selector as `google` unless you have a reason to change it. If another service already uses that selector on the domain, pick something like `gwks1`.","Click Generate new record. Google shows you a host name (`google._domainkey`) and a long TXT value starting with `v=DKIM1; k=rsa; p=…`.","Publish that as a TXT record at your DNS host. Host/name field: `google._domainkey`. Value: the full string, no line breaks, no added quotes.","Wait for the record to resolve — usually minutes, occasionally up to an hour — then return to the Admin console and click Start authentication."]}

That last step is the one people skip. Until you click Start authentication, Google is not signing anything, no matter how perfect the DNS record looks. If you set up a new sending domain and your DMARC reports show DKIM as none, this is the first place to look.

{"h2":"Microsoft 365: step by step"}

Microsoft works differently. Instead of a TXT record, you publish two CNAMEs that point at Microsoft-hosted keys, which lets Microsoft rotate them without you touching DNS again.

{"ul":["Find your tenant's initial domain — the `yourtenant.onmicrosoft.com` one. You'll need it for the CNAME targets.","Create two CNAME records. Host: `selector1._domainkey` → target `selector1-yourdomain-com._domainkey.yourtenant.onmicrosoft.com`. Host: `selector2._domainkey` → target `selector2-yourdomain-com._domainkey.yourtenant.onmicrosoft.com`.","Note the target format: your custom domain with dots replaced by dashes. `outbound-acme.com` becomes `selector1-outbound-acme-com`.","Go to the Defender portal at security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.","Select your custom domain and toggle \"Sign messages for this domain with DKIM signatures\" to Enabled."]}

If the toggle throws a "CNAME record does not exist" error, your records haven't propagated yet or one of the targets has a typo. Wait, re-check with a DNS lookup, then try again.

Here's the Microsoft-specific trap: until you enable DKIM for the custom domain, Microsoft 365 still signs outbound mail — with the onmicrosoft.com domain. Look at the headers and you'll see `dkim=pass`, which feels fine. But `d=yourtenant.onmicrosoft.com` does not align with a From address at yourdomain.com, so DMARC gets nothing from DKIM and depends entirely on SPF. Any forwarding hop and the message fails outright. We wrote about that failure mode in more detail in why DMARC fails even when SPF and DKIM pass.

{"h2":"Verify it — don't assume"}

Two checks, both quick.

DNS check. From a terminal: `dig +short TXT google._domainkey.example.com` for Google, or `dig +short CNAME selector1._domainkey.example.com` for Microsoft. On Windows: `nslookup -type=TXT google._domainkey.example.com`. You should get the key or the Microsoft target back, not NXDOMAIN.

Live message check. Send a real email from the mailbox to a Gmail address you control. Open it, click the three dots, choose "Show original." You want to see:

{"ul":["DKIM: PASS with domain example.com — and that domain must match your From domain, not onmicrosoft.com or a tool's domain.","In the Authentication-Results header: `dkim=pass header.i=@example.com`.","SPF pass and DMARC pass on the same lines."]}

Do this for every sending domain and at least one mailbox per domain. Five minutes now beats a week of wondering why reply rates are flat.

{"h2":"Eight things that quietly break DKIM"}

{"ul":"**The registrar appends your domain automatically.** You enter `google._domainkey.example.com` as the host and end up with `google._domainkey.example.com.example.com`. Enter just `google._domainkey` unless your host explicitly requires the FQDN.","**Added quotes or line breaks.** Some control panels want the TXT value in one piece; others split long strings automatically. If you manually add quotation marks around an already-quoted chunk, the key parses as garbage.","**A trailing space in the copied key.** It happens more than you'd think. Paste into a plain text editor first if you're unsure.","**Selector collision.** If you previously used another sending platform on that domain with the `google` or `selector1` selector, overwriting or duplicating breaks one of them. Pick a unique selector per service.","**Signing never enabled.** Google's Start authentication button; Microsoft's Defender toggle. Both are separate from DNS.","**Wrong domain in a multi-domain setup.** Google Workspace secondary domains each need their own key. Microsoft 365 needs a separate CNAME pair per custom domain.","**Subdomains aren't covered by the parent.** A key at `google._domainkey.example.com` does not sign mail from `go.example.com`. If you send from a subdomain, add it as a domain in the admin console and generate its own key. For the broader subdomain-vs-separate-domain decision, see [subdomain vs. secondary domain.","Old 1024-bit keys. Gmail and Yahoo both treat weak keys as a downgrade signal for bulk senders. If your key predates 2023, regenerate at 2048."]}

{"h2":"What about non-Google, non-Microsoft mailboxes?"}

If you're sending through a generic SMTP/IMAP host, the provider has to sign the mail — you can't sign it yourself from a sending tool without handing over a private key. Ask your host for a DKIM record. Most decent business hosts (Zoho, Fastmail, Migadu, Purelymail) generate one in the control panel. If a host has no DKIM option in 2026, that's a reason to move, not a reason to shrug.

One note that trips people up: when a sending platform relays mail through your own mailbox — SMTP-authenticated as you — the message inherits your provider's DKIM signature. There's no second setup step. When a platform sends on your behalf from its own infrastructure, you usually need an extra DKIM record for that vendor, and now you're managing two signing paths.

{"h2":"Key rotation"}

Microsoft rotates keys automatically once DKIM is enabled — that's the point of the CNAME approach. Google does not. Rotating a Google key every 6 to 12 months is good hygiene, and the process is: generate a new key with a new selector, publish it, click Start authentication, then remove the old TXT record a few days later once nothing is signing with it. Don't delete the old record the same day; messages already in flight may still reference it.

{"h2":"Where this fits in your setup order"}

DKIM goes in before warm-up starts, not after. The sequence that works: buy the domain, configure MX, publish SPF, publish DKIM, publish a `p=none` DMARC record, verify all three on a live test message, then start warming mailboxes. Starting warm-up on an unauthenticated domain teaches mailbox providers the wrong thing about you from day one. Our plain-English SPF, DKIM, and DMARC guide covers the full record set if you're standing up a domain from scratch.

{"h2":"How Sendvanta handles this"}

Sendvanta sends through your own Gmail, Microsoft 365, or SMTP mailboxes, so your provider signs every message with your DKIM key — nothing is proxied through shared IPs and there's no second vendor record to publish. What Sendvanta adds is the checking: deliverability health scoring reads mailbox, domain, DKIM, and IP signals together, flags a domain whose DKIM stops validating, and can slow or pause sending automatically before a broken record turns into a reputation problem. You can connect mailboxes and run the authentication checks on the free plan — $0, no credit card, 1,000 active leads and 3,000 emails a month. More at /features.

{"faq":[{"q":"How long does DKIM take to start working?","a":"DNS propagation is usually minutes to an hour, though providers quote up to 48 hours. Signing begins the moment you enable it in the admin console after the record resolves — there's no separate delay for the first signed message."},{"q":"Do I need DKIM on every sending domain?","a":"Yes. DKIM is per-domain, and per-subdomain. If you run five cold email domains, that's five keys, five DNS entries, and five enable steps."},{"q":"Is 1024-bit DKIM still acceptable?","a":"It will validate, but major receivers treat weak keys as a negative signal for bulk senders. Use 2048-bit unless your DNS provider genuinely cannot store the longer value."},{"q":"Why does my message show dkim=pass but DMARC still fails?","a":"Almost always alignment. The signing domain in `d=` doesn't match your From domain — common on Microsoft 365 when custom-domain DKIM was never enabled and mail is signed as onmicrosoft.com."},{"q":"Should I rotate DKIM keys?","a":"Microsoft 365 does it for you automatically. On Google Workspace, rotate manually every 6–12 months by generating a new key with a new selector and removing the old record a few days after cutover."}]}

Setup notes verified against the Google Admin console and Microsoft Defender portal flows as of February 2026; admin console menu paths change occasionally, so treat the field names as guides rather than exact labels.