Why DKIM fails on Microsoft 365 and Google Workspace, and how to fix it

DKIM adds a cryptographic signature to outgoing mail, and the public key is published in DNS under a selector. Receiving servers use the key to check that the message was signed by the domain and not changed in transit (RFC 6376). When DKIM shows fail, none, or passes for the wrong domain, DMARC cannot protect the domain from forged mail. Most of these problems are DNS or configuration errors, and they are quick to fix once you know where to look.

Step 1: Read the headers of a real test message

Send an email from the domain to a mailbox you control, open the full headers, and find two lines:

• Authentication-Results with dkim=pass, dkim=fail or dkim=none.
• DKIM-Signature, which names the signing domain in d= and the selector in s=.

If there is no DKIM-Signature header at all, the message was not signed. If there is one and it fails, the public key in DNS does not match the key used to sign.

Step 2: Match the cause

1. Signing is not turned on. Microsoft 365 publishes DNS records for a custom domain but does not sign with them until signing is enabled for that domain in the admin portal. Google Workspace similarly needs DKIM generated and started in the Admin console.
2. The DNS record is entered wrongly. Many DNS hosts add the domain name automatically. Typing the full name, such as selector1._domainkey.example.com, into a host that already appends example.com creates a record that does not exist. Copy the name exactly as the provider shows it, with the host's own suffix rules in mind.
3. The selector does not match. The s= value in the signature must have a published record. If the provider rotated keys and the old record was deleted, messages signed with the old key fail until DNS catches up.
4. The message changed after signing. Mailing lists, footers added by a security gateway, and some forwarding services alter the body or headers. The signature then fails even though the key is correct. Check whether the failing mail went through one of these.
5. A key was published in a broken form. Long keys in TXT records can be mangled by some DNS hosts, and copy-paste can drop characters. Use the full key the provider gives you, and a 2048-bit key where it is offered.

Step 3: Check the DNS record directly

Look up the selector from a command line, replacing the names with your own:

nslookup -type=CNAME selector1._domainkey.example.com
nslookup -type=TXT selector1._domainkey.example.com

For Microsoft 365 the selector records are CNAMEs that point to Microsoft-hosted targets. For Google Workspace the selector is a TXT record that holds the public key. Either way, a missing answer means the record is not live yet or was entered under the wrong name.

Step 4: Confirm the fix

1. Wait for DNS to update. TTLs can keep old answers in place for hours.
2. Send a fresh test message. Old messages keep their old results.
3. Confirm dkim=pass and that the d= value matches the From domain, so DMARC also aligns.

What not to do

• Do not publish several DKIM keys for the same selector. Create one record per selector and remove the ones you do not use.
• Do not weaken DMARC to hide failures. Use the failures to find the sender that is not signing.
• Do not guess at selectors. No tool can list every selector a domain uses. See how to find a DKIM selector.

For the full setup steps, see the guides for Office 365 and Exchange Online and Google Workspace.