DKIM (DomainKeys Identified Mail)

When DKIM is turned on, your mail service signs each outgoing message with a private key only it holds. You publish the matching public key in your domain's DNS. A receiving server uses that public key to check the signature: if it matches, the message genuinely came from an authorized sender for your domain and its signed contents weren't changed in transit.

Unlike SPF, DKIM survives most forwarding, because the signature travels with the message. In Microsoft 365, enabling DKIM for your own domain means adding two CNAME records (selector1 and selector2) to your DNS and switching signing on in the Defender portal. Each other service that sends mail as your domain — marketing, billing, reminders — needs its own DKIM setup too.

Why it matters: DKIM is a key ingredient of DMARC, which is what actually tells the world to reject forged mail from your domain. It also helps your legitimate email reach inboxes rather than spam folders, which matters when you send appointment reminders and statements to patients or clients.

A common gap: many Microsoft 365 tenants are signing mail only with Microsoft's default onmicrosoft.com domain rather than the business's own domain, because nobody finished the DNS step. Everything appears to work, but DMARC alignment fails for your real domain.

Example: a CPA firm's tax-season emails to clients started landing in junk folders. A check showed SPF was correct but DKIM had never been enabled for the firm's domain. Adding the two records and enabling signing fixed delivery and let the firm move its DMARC policy toward enforcement.

Our email security checker shows whether Microsoft 365 DKIM is set up on your domain.