In this module

AD2.6 DKIM: Signing Your Outbound Email

5-6 hours · Module 2 · Free

Operational Objective

SPF verifies that the sending server is authorized, but it doesn't verify that the email content hasn't been modified in transit. An email forwarded through a mailing list or a third-party relay passes through a different server than the original — SPF may fail because the forwarding server isn't in your SPF record, even though the email is legitimate. DKIM (DomainKeys Identified Mail) solves this by adding a cryptographic signature to every outbound email. The signature is generated using a private key held by your email system and verified using a public key published in your DNS. If the email content is modified in transit, the signature breaks. If the email is forwarded through a different server, the signature still validates because it's attached to the message, not the server. This subsection walks you through enabling DKIM for M365 and publishing the DNS records that make it work.

Deliverable: DKIM enabled for your domain in M365 with DNS records published, verified, and tested — ensuring every outbound email carries a cryptographic signature that proves authenticity.

Estimated completion: 20 minutes

Figure AD2.6 — DKIM signing and verification. M365 signs every outbound email with a private key. The receiving server retrieves the public key from your DNS and verifies the signature. A valid signature proves the email is authentic (from your domain) and unmodified (not tampered with in transit). Unlike SPF, DKIM survives email forwarding.

Enabling DKIM in M365

Navigate to security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM.

Select your domain from the list. You'll see the status — if DKIM is not enabled, the status shows "Not signing outbound messages with DKIM." Click "Enable" to start the process.

M365 needs two CNAME records in your DNS to publish the DKIM public keys. The portal shows you the exact records to create. They look like:

Record 1: Type: CNAME Name: selector1._domainkey Value: selector1-northgateeng-com._domainkey.northgateeng.onmicrosoft.com

Record 2: Type: CNAME Name: selector2._domainkey Value: selector2-northgateeng-com._domainkey.northgateeng.onmicrosoft.com

The CNAME approach is smart — instead of putting the actual DKIM public key in your DNS (which would need updating when Microsoft rotates keys), the CNAME points to Microsoft's infrastructure where they manage the key rotation automatically. You set it once and Microsoft handles key management going forward.

Log into your DNS provider and create both CNAME records. DNS propagation typically takes 15-60 minutes. After propagation, return to the DKIM page in the Defender portal and click "Enable" again. The portal verifies the CNAME records exist and activates DKIM signing for your domain.

Verifying DKIM is working

After enabling DKIM, verify it with these three checks.

Check 1 — DNS lookup. Verify the CNAME records resolve:

nslookup -type=cname selector1._domainkey.northgateeng.com

You should see the CNAME pointing to Microsoft's DKIM infrastructure. If you get "Non-existent domain," the DNS record hasn't propagated yet or was created incorrectly.

Check 2 — Outbound email headers. Send a test email from your M365 account to a personal Gmail address. In Gmail, open the email and view the original headers (three dots → Show original). Search for "dkim=pass" in the Authentication-Results header. If you see dkim=pass, DKIM is signing your outbound email correctly. You should also see a DKIM-Signature header in the email — this is the actual cryptographic signature that M365 added.

Check 3 — MXToolbox validation. Navigate to mxtoolbox.com/dkim.aspx. Enter your domain and selector (selector1). The tool checks whether the DKIM public key is published and valid. A green checkmark means DKIM is configured correctly.

Expand for Deeper Context

DKIM uses asymmetric cryptography — a private key (held securely by Microsoft's Exchange Online infrastructure) and a public key (published in your DNS). When M365 sends an email from your domain, it takes a hash of specific email headers (From, Subject, Date) and the body, encrypts the hash with the private key, and attaches the encrypted hash as the DKIM-Signature header. The receiving server retrieves the public key from your DNS, decrypts the hash, and compares it against its own hash of the received message. If they match, the message is authentic and unmodified.

Two selectors (selector1 and selector2) exist to support key rotation. Microsoft periodically rotates DKIM keys — when they rotate, they switch from selector1 to selector2 (or vice versa), publish the new key in the inactive selector, and then switch signing to the new key. Both selectors need to exist in your DNS for rotation to work seamlessly. If you only publish one selector, key rotation will fail and DKIM will break until you add the second.

Microsoft handles key rotation automatically through the CNAME approach — your CNAME records point to Microsoft's DNS, where they update the actual public key records. You don't need to touch your DNS when keys rotate. This is the advantage of CNAME-based DKIM over direct TXT-based DKIM: zero maintenance after initial setup.

DKIM and email forwarding

One of DKIM's key advantages over SPF is that it survives email forwarding. When an email is forwarded by a mailing list, the forwarding server changes the envelope sender (which breaks SPF) but typically doesn't modify the email body or original headers (which preserves DKIM). This means that forwarded emails from your domain still pass DKIM validation at the final recipient — even though they fail SPF because the forwarding server isn't in your SPF record.

This is particularly important for organizations that use mailing lists, distribution lists hosted by third parties, or email forwarding rules. Without DKIM, forwarded emails from your domain would fail both SPF and DMARC (once you deploy it). With DKIM, the signature validates and DMARC passes on the DKIM alignment — even when SPF fails due to forwarding.

Troubleshooting DKIM failures

If DKIM stops working after initial setup, there are three common causes.

CNAME records deleted or modified. Someone cleaning up DNS records may delete the selector1 and selector2 CNAMEs without realizing they serve DKIM. Verify both records exist:

Resolve-DnsName -Name "selector1._domainkey.northgateeng.com" -Type CNAME
Resolve-DnsName -Name "selector2._domainkey.northgateeng.com" -Type CNAME

If either returns an error, recreate the CNAME from the values in the Defender portal (security.microsoft.com → Policies & rules → Threat policies → Email authentication settings → DKIM → select your domain).

DKIM disabled in the portal. Someone may have toggled DKIM off while troubleshooting another issue. Check the status:

Connect-ExchangeOnline
Get-DkimSigningConfig -Identity northgateeng.com | Select-Object Domain, Enabled, Status

If Enabled is False, re-enable it:

Set-DkimSigningConfig -Identity northgateeng.com -Enabled $true

Key rotation failed. Microsoft rotates DKIM keys automatically via the CNAME delegation, but if there's a DNS issue during rotation, the active selector may point to an expired key. Check which selector is active:

Get-DkimSigningConfig -Identity northgateeng.com | Select-Object Selector1CNAME, Selector2CNAME, SelectorBeforeRotateOnDate, SelectorAfterRotateOnDate

If the dates indicate a recent rotation and DKIM is failing, the rotation may have failed silently. Toggle DKIM off and back on to force a re-sync with the current key.

Configuring DKIM for third-party sending services

M365 DKIM only signs emails sent through Exchange Online. If you use third-party services that send as your domain (Mailchimp, HubSpot, Zendesk, Salesforce), those emails are signed with the third-party's DKIM key — not yours. This creates a DMARC alignment problem: the email's FROM address is your domain, but the DKIM signature uses the third-party's domain. DKIM passes for the third-party but fails DMARC alignment because the domains don't match.

Most major email sending platforms support custom DKIM — signing emails with YOUR domain's key instead of theirs. The process varies by service, but the pattern is the same: the service generates a DKIM key pair, you publish the public key as a DNS record on your domain, and the service signs outbound email with the private key. This gives the email both SPF alignment (if the service is in your SPF record) and DKIM alignment (because the signature uses your domain).

Check each third-party service you identified during the SPF audit (AD2.5). Navigate to their email authentication or domain verification settings. Look for "DKIM," "Email authentication," or "Domain signing." Each service provides a DNS record (usually a CNAME or TXT) that you add to your domain. After adding the record, verify it in the service's dashboard — most show a green checkmark when DKIM is correctly configured.

This is the step that makes DMARC enforcement possible. Without custom DKIM on third-party services, those emails fail DMARC alignment when SPF also fails (which happens with forwarding). With custom DKIM, the emails pass DMARC on DKIM alignment regardless of the sending server — giving you the confidence to progress from p=none to p=reject without blocking legitimate third-party email.

Monitoring DKIM health

Add a quarterly DKIM check to your maintenance calendar. Send a test email to a personal Gmail account, view the original headers, and confirm dkim=pass appears. This 2-minute check catches DKIM failures before they affect your DMARC posture. A failed DKIM doesn't immediately break email delivery (SPF may still pass, satisfying DMARC), but it removes the redundancy that DKIM provides — and you won't know it's broken until a forwarded email fails both SPF and DKIM and gets rejected by the recipient.

Compliance Myth: "DKIM is optional if we already have SPF"

SPF and DKIM serve different purposes and neither replaces the other. SPF validates the sending server. DKIM validates the message content. SPF breaks when email is forwarded. DKIM survives forwarding. DMARC requires at least one of SPF or DKIM to pass with alignment — having both gives you redundancy. If SPF fails (forwarding, misconfiguration, lookup limit exceeded), DKIM keeps your email authenticated. If DKIM fails (rare, but possible with certain message modifications), SPF provides the backup. Both are needed for robust email authentication, and both are required for DMARC enforcement in AD2.7.

Decision point

You've created the DKIM CNAME records in DNS. When you return to the Defender portal and click "Enable," you get an error: "CNAME record not found." You've waited 2 hours for DNS propagation. What do you check?

Option A: Wait another 24 hours — DNS propagation can take up to 48 hours.

Option B: Verify the CNAME records in DNS using nslookup, checking for typos in the record name and value.

Option C: Delete and recreate the CNAME records.

The correct answer is Option B. The most common cause of DKIM enablement failure is a typo in the CNAME record — either in the name (selector1._domainkey vs selector1._domainkeys) or the value (the long CNAME target includes your domain with hyphens instead of dots, which is easy to get wrong). Run nslookup -type=cname selector1._domainkey.yourdomain.com and compare the output against the exact value shown in the Defender portal. If the lookup returns "Non-existent domain," the record doesn't exist in DNS — check your DNS provider for the record. If it returns a value that doesn't match the portal, there's a typo. Fix the typo and retry. Waiting another 24 hours wastes time if the record is wrong.

nslookup -type=cname selector1._domainkey.yourdomain.com
nslookup -type=cname selector2._domainkey.yourdomain.com

Try it: Enable DKIM for your domain

Navigate to security.microsoft.com → Policies & rules → Threat policies → Email authentication settings → DKIM. Select your domain. If DKIM is not enabled, note the two CNAME records the portal displays.

Create both CNAME records in your DNS provider. Wait 30-60 minutes for propagation. Return to the portal and click "Enable."

Verify with nslookup:

Both should resolve to Microsoft's DKIM infrastructure. Send a test email to Gmail and check the headers for dkim=pass. If both lookups resolve and the test email shows dkim=pass, DKIM is fully operational.

An email from your domain is forwarded by a mailing list server to a recipient outside your organization. The forwarding server changes the envelope sender to its own address. Which email authentication checks pass at the final recipient?

Both SPF and DKIM pass — Unlikely. SPF checks the envelope sender's domain, which the forwarding server changed. SPF will likely fail because the forwarding server isn't in your SPF record.

SPF passes, DKIM fails — Backwards. SPF fails because the envelope sender changed. DKIM is more likely to pass because the signature is attached to the message, not the server.

Neither passes — the email will be rejected — Not necessarily. If DKIM passes and DMARC is configured to accept DKIM alignment, the email is authenticated.

SPF fails (envelope sender changed), DKIM passes (signature is still valid because the message content wasn't modified) — Correct. This is the classic email forwarding scenario. DKIM survives forwarding because the signature is part of the message, not the server identity. DMARC will pass if it's configured to accept either SPF or DKIM alignment — which is the default. This is why you need both SPF and DKIM: they provide redundancy for different email routing scenarios.

Operational Artifact — DKIM Configuration Checklist

DKIM setup: create two CNAME records (selector1._domainkey and selector2._domainkey) pointing to Microsoft's DKIM infrastructure, enable DKIM in the Defender portal, verify with nslookup and outbound email headers. Both selectors must exist for key rotation to work. After initial setup, DKIM is maintenance-free — Microsoft handles key rotation through the CNAME delegation. Verify DKIM is still passing every quarter by checking outbound email headers (search for `dkim=pass`).

You're reading the free modules of M365 Security: From Admin to Defender

The full course continues with advanced topics, production detection rules, worked investigation scenarios, and deployable artifacts.

View Pricing See Full Syllabus

← Previous Next →