How it works
The service that sends your email adds a header to each message: a signature made with a private key only it holds. The header names a selector. The receiver looks up that selector in your DNS, finds the public key and checks the signature against the message.
Where the key lives
v=DKIM1; k=rsa; p=MIIBIjANBgkqh…
Each sending service has its own selector, so a domain usually has several keys.
Why it matters more now
Forwarding breaks SPF, because the forwarding server is not on your list. DKIM survives forwarding, because the signature travels with the message. The 2026 DMARC standard says a domain at reject should not rely on SPF alone. A sender that passes only on SPF will have its forwarded mail refused once you reach reject.
Source: RFC Editor, RFC 9989.
What goes wrong
Never switched on
Microsoft 365 and Google Workspace both sign with their own domain until you turn DKIM on for yours.
A key deleted in a DNS tidy-up
The record looked unfamiliar, so somebody removed it.
A provider changed its selector
The old record still exists. The new one was never published.
A short key
Receivers refuse keys shorter than 1,024 bits. Use 2,048 bits or more.
Source: RFC Editor, RFC 8301.
Turning it on
Microsoft 365
Microsoft assigns two records per domain, selector1 and selector2. You publish them, then switch signing on in the Defender portal or by PowerShell.
Google Workspace
In the Admin console: Apps, Google Workspace, Gmail, Authenticate email. Generate the key, publish the record it shows at google._domainkey, then start authentication. Google offers no way to do this by software.
Source: Microsoft, How to use DKIM for email in your custom domain.
How OuterMark handles it
The free check looks for your key where it is usually published and grades its strength (checks 3 and 9). It says "could not confirm" when a service signs with a name that cannot be guessed from outside. On Managed DMARC, DKIM monitoring learns every key your senders actually use from your DMARC reports, checks each one every day and alerts you when one breaks. It needs no record, and we never hold your keys. For IT providers, OuterMark finds each client's Microsoft 365 tenant and supplies a script that creates the keys and switches signing on.
The Microsoft 365 script is proven on our own tenant: on 25 September 2026 a test message passed SPF, DKIM and DMARC at Gmail. It has not yet been run through a partner's access to a client's tenant.
Questions
Do you hold our private keys?
No. The keys stay with whoever signs your email.
How many DKIM keys should we have?
One for each service that sends as you.
Does DKIM encrypt email?
No. It proves who sent a message and that it was not altered. Encryption in transit is TLS, which MTA-STS enforces.