MailFixIt

Microsoft 365 DKIM setup

Fix a Microsoft 365 DKIM CNAME record

If Microsoft 365 says a DKIM CNAME record does not exist, compare the public CNAME with the exact values issued for that custom domain. A target copied from another tenant, an old example or a guessed onmicrosoft.com name is not safe to publish.

Compare the issued CNAME free

Required input: copy the selector1 and selector2 CNAME owners and targets from the Microsoft Defender portal or Get-DkimSigningConfig. MailFixIt does not generate targets from a tenant name.

Why the CNAME can look correct but fail

Safe comparison workflow

  1. In Microsoft 365, copy—not infer—the CNAME values for the exact custom domain or subdomain.
  2. Run the comparison with each selector1._domainkey or selector2._domainkey owner and its issued CNAME target.
  3. If the checker reports mismatch, preserve the existing record for rollback and correct only the intended CNAME owner or target.
  4. If it reports duplicate owner, the provider may have appended the zone name twice; recreate it with the DNS host's documented relative/FQDN syntax.
  5. When both records match, return to Microsoft 365, refresh status and enable DKIM signing. Send a new message to confirm the actual signature.

Do not guess the target

Microsoft 365 documents both an older format and a newer format with a dynamic partition value. The portal or PowerShell output for your tenant is the source of truth. A syntactically plausible CNAME is not necessarily the one Microsoft 365 expects.

What this check proves

The free check distinguishes a matching public CNAME, a mismatch, absence, a likely duplicated owner and a transient DNS result. It does not prove that Microsoft 365 has enabled signing, that a message has a valid DKIM signature or that every recipient will accept it.

Official reference: Microsoft: configure DKIM for custom domains.