In Microsoft 365, DKIM uses a DKIM selector to tell receiving systems which DNS location to query for the DKIM public key. The selector ensures the email receiver can retrieve the correct public key to validate the digital signature that Microsoft Exchange Online adds to outbound messages. Each message carries a DKIM-Signature header in the email headers, which includes the d= tag (the signing domain) and the s= tag (the DKIM selector). The combination of these tags points to a DNS name such as s._domainkey.d that holds the public key.
Microsoft 365 commonly uses two selectors—selector1 and selector2—for safe DKIM key rotation. Behind the scenes, Microsoft hosts the private key in its service boundary and uses it to sign messages; your DNS records, published under _domainkey, advertise the matching public key. Because DKIM is cryptographic authentication based on a key pair, the email sender’s private key never leaves Microsoft 365, while recipients fetch the DKIM public key via DNS lookup to verify the digital signature.
Anatomy of the DKIM-Signature header
The DKIM-Signature header is a compact map of how the signature was created and how to validate it. Key components include:
- d= tag: Identifies the signing domain (for example, d=example.com). The d= tag must relate to the visible from address for DMARC alignment.
- s= tag: Identifies the DKIM selector (for example, s=selector1). Receivers use this to find the DKIM public key at selector1._domainkey.example.com.
- a= tag: The algorithm, typically rsa-sha256, describing the cryptographic method used to generate the digital signature.
The d= tag and alignment
The d= tag should match or be a subdomain of the from address domain to support DMARC alignment and maintain email authenticity.
The s= tag and selector resolution
The s= tag supplies the DKIM selector that, when combined with the d= tag and the _domainkey label, yields the DNS name containing the public key.
Algorithm and headers covered
The a=rsa-sha256 algorithm signs selected headers listed in the h= field, ensuring email integrity across critical email headers such as From, Subject, and Date.
Prerequisites and Planning: DNS Access, Selector Strategy, and Rotation
Before implementation, confirm:
- DNS access: You must add DNS records at your domain host for _domainkey.
- Selector strategy: Plan to use selector1 and selector2. This dual DKIM selector approach enables DKIM key rotation without interrupting mail delivery.
- Key management and rotation: Because Microsoft 365 manages the private key, your role focuses on publishing CNAME record pointers and scheduling rotation (switch signing from one selector to the other). For third-party provider scenarios (for instance, Salesforce.com or a security gateway), understand whether they require TXT record publishing of a DKIM public key or CNAME redirection for key delegation.
- Alignment and DMARC: Ensure d= tag alignment with the from address to support DMARC. Good alignment strengthens email authentication and email security outcomes.
- Subdomains and multi-tenant needs: If you sign mail from marketing.example.com or a university subdomain used by a campus department, create separate selectors per signing domain and coordinate with the support team managing Microsoft 365.
Create and Publish DKIM CNAME Records (selector1/selector2) for Your Custom Domain
To enable DKIM in Microsoft 365 for a custom domain (e.g., example.com), create two CNAME records in DNS under _domainkey:
- selector1._domainkey.example.com CNAME points to the Microsoft 365-hosted key for your tenant and domain.
- selector2._domainkey.example.com CNAME points to the alternate Microsoft 365-hosted key for rotation.
You obtain the exact target hostnames from the Microsoft 365 admin experience for your domain. This approach delegates lookups to Microsoft 365 and ensures the public key is always current, while the private key remains securely managed in the service.
Record format and examples
The general naming pattern is:
- Name: selector1._domainkey.example.com
- Type: CNAME record
- Target: Provided in the Microsoft 365 admin center (varies per tenant and domain)
Example: selector1 CNAME (example.com)
- Name: selector1._domainkey.example.com
- Type: CNAME record
- Target: selector1-example-com._domainkey..onmicrosoft.com Always copy the target exactly as shown in the admin interface.
Example: selector2 CNAME (example.com)
- Name: selector2._domainkey.example.com
- Type: CNAME record
- Target: selector2-example-com._domainkey..onmicrosoft.com
TXT alternative with third-party sender
If a third-party provider like Salesforce.com or exampleprovider.com signs mail for your domain, they may instruct you to publish a TXT record at selectorX._domainkey.example.com that contains a p= value (the DKIM public key). This is not typical for Microsoft 365 but is common with non-Microsoft services. Follow each provider’s tool and guidance closely for key delegation.
Enable DKIM Signing in Microsoft 365 Admin Centers for Each Domain/Subdomain
After publishing the CNAME records, enable DKIM signing for the domain:
- In the Exchange admin center for Microsoft Exchange Online, open the DKIM settings for your domain or subdomain.
- Select Enable for selector1 (or whichever selector you start with).
- Repeat for each domain or subdomain you send from (e.g., example.com, marketing.example.com).
Microsoft 365 will then use the private key corresponding to the active DKIM selector to add a DKIM-Signature header to outbound messages. You can later switch to selector2 to perform DKIM key rotation with no disruption to mail delivery, as the DNS records under _domainkey continue to publish the correct public key.
Verify DKIM Records and Signatures, Rotate Keys Safely, and Troubleshoot Issues
Verification ensures your email authentication is functioning as intended and that recipients such as Gmail and Outlook can validate the digital signature.
- Header inspection: Send a test message from Microsoft 365 to external mailboxes, including Gmail and Outlook. In each email client, open the full email headers. Confirm the DKIM-Signature header is present and includes the correct d= tag (e.g., d=example.com) and s= tag (e.g., s=selector1).
- DNS verification: Use a DKIM validator or DKIM Inspector to confirm the public key is retrievable. Tools from dmarcian (DKIM Inspector), MXToolbox (SuperTool), or Google’s toolbox can query selector1._domainkey.example.com and show the DKIM public key. This email verification and email integrity check confirms your DNS records are in place.
- Alignment check: Ensure the d= tag aligns with the from address domain to satisfy DMARC alignment.
Rotate keys safely:
- Publish and validate both selector1 and selector2 CNAME records.
- In Microsoft 365, switch signing to the alternate DKIM selector (selector2).
- Confirm via header inspection that the s= tag now shows selector2 in the DKIM-Signature header.
- After adequate propagation and monitoring, retire the previous selector as directed in policy.
Common pitfalls and fixes
- No DKIM-Signature header: Ensure DKIM is enabled for the domain in the admin center and that outbound mail is actually routed by Microsoft 365.
- DNS records not found: Confirm the CNAME record names include _domainkey, and verify record propagation with a DNS lookup tool. Look for typos in selector names and the target host.
- Wrong domain in d= tag: If the d= tag shows your onmicrosoft.com domain, adjust settings to sign with your custom domain for proper DMARC alignment.
- Mixed third-party flows: For relayed email or forwarded email through a security gateway, ensure the gateway does not alter signed headers. If a third-party provider signs messages on your behalf, coordinate key delegation and avoid double-signing conflicts.
- Key mismatch: If a validator reports a bad public key, confirm the CNAME target matches what Microsoft 365 provides and that no stale TXT record is present at the same name.
Tools, Header Inspection, and Validation Workflows
A robust verification process uses multiple perspectives:
- dmarcian: Use DKIM Inspector to find DKIM selector records, check the DKIM public key, and monitor DMARC alignment. dmarcian’s Delivery Center and Delivery Center Plus offer ongoing visibility; Mailflow Monitoring can surface authentication anomalies; Bulk Lookups accelerate DNS checks; BIMI configuration tools help align brand indicators; and their API Reference and Forum provide integration and peer support.
- MXToolbox: The SuperTool can query selector1._domainkey.example.com and selector2._domainkey.example.com to validate DNS records and the retrieved public key.
- Microsoft 365 portal: Review the DKIM settings in Exchange admin center and message trace to confirm signing activity in Microsoft Exchange Online.
- Independent checks: Send to personal Gmail and Outlook accounts and perform header inspection. Look for a= rsa-sha256, the d= tag, and s= tag in the DKIM-Signature header to confirm cryptographic authentication. Verify that email headers have not been altered in transit.