Stackvora.tech

Configure DKIM for Outbound Mail

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. It allows the receiver to check that an email…

DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect email spoofing. It allows the receiver to check that an email claiming to come from a specific domain was indeed authorized by the owner of that domain. This is achieved by cryptographically signing outbound emails with a private key owned by the sending domain and publishing the corresponding public key in the domain's DNS records. Properly configured DKIM, alongside SPF and DMARC, significantly enhances email deliverability and reduces the risk of phishing and spam originating from your domains.

Understanding DKIM in Microsoft 365

Microsoft 365 automatically enables DKIM for its onmicrosoft.com domains. However, for custom domains (e.g., yourcompany.com), you must explicitly enable and configure DKIM. Microsoft 365 manages the private key for your domain, and you are responsible for publishing the public key selectors as CNAME records in your domain's DNS. Microsoft uses two DKIM selectors, typically selector1._domainkey and selector2._domainkey, to allow for key rotation without service interruption.

Prerequisites for DKIM Configuration

  • Global Administrator or Exchange Administrator roles in Microsoft 365.
  • Access to your domain's DNS management console (e.g., GoDaddy, Cloudflare, Azure DNS).
  • All custom domains fully configured and verified in Microsoft 365.
  • Sufficient time for DNS propagation (can take several hours).

Step-by-Step DKIM Configuration in Microsoft 365

1. Access the DKIM Policy in Microsoft 365 Defender

Navigate to the Microsoft 365 Defender portal. The exact path may vary slightly with UI updates, but typically it is:

https://security.microsoft.com/ > Email & collaboration > Policies & rules > Threat policies > Anti-spam > DKIM.

Alternatively, you can often find a direct link by searching for "DKIM" in the Microsoft 365 admin center search bar.

2. Enable DKIM for Each Custom Domain

In the DKIM policies list, you will see your onmicrosoft.com domain(s) already enabled. For each custom domain you wish to protect:

  1. Select the custom domain from the list.
  2. In the flyout pane that appears, you will likely see a status indicating DKIM is not enabled or that CNAME records are not published.
  3. Click on the Create DKIM keys button or a similar prompt.
  4. Microsoft 365 will generate two CNAME records. These records will follow a specific format: 
    
Host name: selector1._domainkey.<yourdomain.com>
Points to: selector1-<GUID>._domainkey.<yourtenantid>.onmicrosoft.com

Host name: selector2._domainkey.<yourdomain.com>
Points to: selector2-<GUID>._domainkey.<yourtenantid>.onmicrosoft.com

    Make sure to copy these exact values, as the <GUID> and <yourtenantid> parts are unique to your tenant.

  5. Do NOT close this flyout pane yet.

3. Add CNAME Records to Your Domain's DNS

Log in to your domain registrar's or DNS hosting provider's management console (e.g., GoDaddy, Cloudflare, Namecheap, Azure DNS). Create two new CNAME records using the values obtained in the previous step.

  • For selector1:
    • Type: CNAME
    • Host/Name: selector1._domainkey
    • Value/Points to: selector1-<GUID>._domainkey.<yourtenantid>.onmicrosoft.com
    • TTL (Time To Live): Typically 3600 seconds (1 hour) or 14400 seconds (4 hours). For initial setup, a lower TTL can speed up propagation checks, but remember to revert to a higher value for production stability.
  • For selector2:
    • Type: CNAME
    • Host/Name: selector2._domainkey
    • Value/Points to: selector2-<GUID>._domainkey.<yourtenantid>.onmicrosoft.com
    • TTL: Same as above.

Important Note: Some DNS providers automatically append the domain name. If your DNS provider asks for "Host" or "Name", you should only enter selector1._domainkey and selector2._domainkey, not the full selector1._domainkey.yourdomain.com.

4. Enable DKIM in Microsoft 365 Defender

After adding the CNAME records to your DNS, return to the Microsoft 365 Defender portal to the flyout pane for your domain. DNS changes can take some time to propagate globally (up to 24-48 hours, though often faster). Periodically click the Rotate DKIM keys or Enable button (the exact wording may vary). Once Microsoft 365 detects the published CNAME records, the status will change, and you'll be able to toggle the Enable switch to Yes (or "Enabled").

If you encounter an error like "CNAME records not found," wait a bit longer and try again. Use external tools to verify DNS propagation first.

Verifying DKIM Configuration

1. Using PowerShell

Connect to Exchange Online PowerShell and run the following command:


Get-DkimSigningConfig -Identity <yourdomain.com> | Format-List Selector1CNAME,Selector2CNAME,Enabled

Output should show Enabled : True and the correct CNAME values. If Enabled is still False after DNS propagation, it means Microsoft 365 hasn't detected the records yet, or there's a misconfiguration in DNS.

2. Using External DKIM Checkers

Several online tools can verify DKIM records. Examples include mxtoolbox.com/dkim.aspx or dmarcian.com/dkim-inspector/. You'll typically need to enter your domain name and the selector (e.g., selector1 or selector2). These tools will query your DNS and display the public key, confirming that your CNAME records are correctly resolving.

3. Sending a Test Email

Send an email from your configured domain to an external email service (e.g., Gmail, Outlook.com, Yahoo Mail). Then, inspect the message headers of the received email. Look for a line similar to:


Authentication-Results: spf=pass (sender IP is 20.x.x.x) smtp.mailfrom=yourdomain.com; dkim=pass (signature was verified) header.d=yourdomain.com; dmarc=pass action=none header.from=yourdomain.com;

The crucial part is dkim=pass. If it shows dkim=fail or is missing, troubleshoot your configuration.

DKIM Key Rotation

Microsoft 365 automatically rotates DKIM keys for domains where it manages the signing. This means you generally don't need to manually rotate keys. The use of two selectors (selector1 and selector2) facilitates this process by allowing one key to be updated while the other remains active, ensuring uninterrupted mail flow. Microsoft rotates keys approximately every 6 months.

Pairing DKIM with SPF and DMARC

DKIM is most effective when combined with SPF (Sender Policy Framework) and DMARC (Domain-based Message Authentication, Reporting, and Conformance).

  • SPF: Specifies which mail servers are authorized to send email on behalf of your domain. A common SPF record for Microsoft 365 is v=spf1 include:spf.protection.outlook.com -all. The -all mechanism indicates that all other senders should be rejected.
  • DMARC: Builds on SPF and DKIM by allowing a sender to indicate that their emails are protected by SPF and/or DKIM, and tells a receiver what to do if neither of those authentication methods passes (e.g., quarantine, reject, or none). Start with a DMARC policy of p=none for monitoring, then transition to p=quarantine, and finally p=reject once you are confident all legitimate mail is authenticating correctly.

A full DMARC record might look like: v=DMARC1; p=quarantine; fo=1; rua=mailto:dmarc_reports@yourdomain.com; ruf=mailto:dmarc_forensics@yourdomain.com; pct=100;

Common Pitfalls and Troubleshooting

  • Incorrect CNAME Values: Double-check for typos, extra spaces, or missing parts of the CNAME target value. The GUID and tenantid are critical.
  • DNS Provider Appending Domain: Some DNS registrars automatically append your domain to the "Host" field. If your domain is yourdomain.com and you enter selector1._domainkey.yourdomain.com as the host, it might become selector1._domainkey.yourdomain.com.yourdomain.com, causing resolution failure. Only enter selector1._domainkey.
  • DNS Propagation Delay: DNS changes take time. If verification fails immediately, wait a few hours and try again. Use tools like nslookup or dig (e.g., dig CNAME selector1._domainkey.yourdomain.com) to check resolution directly from your command line.
  • Multiple DKIM Records: Only one set of CNAME records (for selectors 1 and 2) should exist for your domain in your DNS for Microsoft 365. Do not create TXT records for DKIM unless explicitly required by a different mail service and understand the implications.
  • Domain Not Verified in M365: Ensure your custom domain is fully added and verified in the Microsoft 365 admin center before attempting DKIM configuration.
  • Cached DNS: If you are verifying from your local machine, ensure your local DNS cache is cleared (ipconfig /flushdns on Windows, sudo killall -HUP mDNSResponder on macOS).
  • Hybrid Exchange Deployments: In hybrid environments, ensure that emails routed through on-premises Exchange servers before reaching Exchange Online are also handled correctly. DKIM signing happens when the message leaves Exchange Online. If mail is routed through other services or appliances *after* Exchange Online, DKIM signing may be invalidated or re-signed.

Back to the knowledge base · Ask the AI assistant