DMARC Analyzer

TL;DR

• Microsoft 365 DKIM uses two CNAME records per custom domain (selector1._domainkey and selector2._domainkey) delegating to your tenant's key infrastructure under <tenant>.onmicrosoft.com. Microsoft owns the private keys; operators only publish CNAMEs.
• Three steps: (1) publish the two CNAMEs the Defender portal displays for your custom domain, (2) wait 24-48 hours for DNS propagation, (3) flip the Defender portal "Enable" toggle or run Set-DkimSigningConfig -Identity <your-domain> -Enabled $true from Exchange Online PowerShell.
• The #1 M365 DKIM failure mode: outbound mail signed under <tenant>.onmicrosoft.com instead of your custom domain. Cause: DKIM was never enabled for the custom accepted domain after CNAME publication. Fix: verify CNAME resolution, then enable signing.
• Two selectors for zero-downtime rotation: only one of selector1 and selector2 signs at a time; a rotation, which the administrator starts, switches signing to the other with no DNS change.
• 2048-bit keys are today's baseline. Check the key size of your domain in the Get-DkimSigningConfig output; if it is 1024 bits, move to 2048 with Rotate-DkimSigningConfig -Identity <your-domain> -KeySize 2048.
• Defender portal path: security.microsoft.com > Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Equivalent PowerShell: Connect to Exchange Online, then Get-DkimSigningConfig to inspect or Set-DkimSigningConfig -Identity <your-domain> -Enabled $true to enable.
• Verification: dig selector1._domainkey.<your-domain> CNAME must return selector1-<dashed-your-domain>._domainkey.<tenant>.onmicrosoft.com; Authentication-Results in delivered mail must show dkim=pass header.d=<your-domain> (NOT header.d=<tenant>.onmicrosoft.com).
• DKIM alone does not stop spoofing; DKIM is one of two authentication signals DMARC consumes. Pair DKIM with SPF (see SPF for Microsoft 365) and DMARC (see DMARC for Microsoft 365) for end-to-end spoof-resistance.

What this guide covers

A focused operator-implementation walkthrough for DKIM on Microsoft 365 / Exchange Online tenants. Sibling pages cover the broader rollout (DMARC for Microsoft 365 walks Steps 1-5 of the full SPF + DKIM + DMARC deployment), the protocol primer (DKIM explained), the canonicalization deep dive (DKIM canonicalization), the selector deep dive (DKIM selectors), and the replay-attack analysis (DKIM replay attacks). THIS page is the Microsoft-365-specific operator reference: the dual-selector CNAME-delegated model, the Defender portal workflow, the Set-DkimSigningConfig PowerShell cmdlet, the onmicrosoft.com routing-domain failure mode, and the 2048-bit key cadence.

The page is anchored against the Feb 2024 Google/Yahoo bulk-sender requirements that demand aligned DKIM for any domain sending more than 5000 messages per day to gmail.com or yahoo.com. Without DKIM enabled for the custom accepted domain (the most common M365 misconfiguration), bulk-sender messages will be junked or rejected by Google and Yahoo.

How Microsoft 365 DKIM works

M365 DKIM is structurally different from Google Workspace, cPanel, and self-hosted DKIM. Three architectural choices define it:

1. CNAME delegation (not TXT publication)

Most DKIM deployments publish a TXT record at <selector>._domainkey.<domain> containing the public-key bytes directly (v=DKIM1; k=rsa; p=<base64 public key> per RFC 6376 §3.6.2). M365 instead publishes a CNAME pointing at the tenant key material:

selector1._domainkey.example.com.  CNAME  selector1-example-com._domainkey.tenant.onmicrosoft.com.
selector2._domainkey.example.com.  CNAME  selector2-example-com._domainkey.tenant.onmicrosoft.com.

The actual v=DKIM1; k=rsa; p=… TXT lives at the <tenant>.onmicrosoft.com target, inside Microsoft's infrastructure. Receivers follow the CNAME chain transparently and read the TXT at the resolved target.

2. Dual selectors for rotation

Every custom domain has TWO selectors: selector1 and selector2. Microsoft keeps two independent key materials inside its infrastructure; one signs at any given time, and a rotation started by the administrator switches signing to the other. Operators never see the private keys. The current active selector is whichever appears in the most recent message's DKIM-Signature s= tag.

3. The dashed-domain transformation

The CNAME target uses a dashed transformation of your custom domain: dots become dashes. So example.com becomes example-com:

selector1._domainkey.example.com         → selector1-example-com._domainkey.tenant.onmicrosoft.com
selector1._domainkey.mail.example.com    → selector1-mail-example-com._domainkey.tenant.onmicrosoft.com
selector1._domainkey.example.org         → selector1-example-org._domainkey.tenant.n-v1.dkim.mail.microsoft

The third line shows the newer format: for custom domains added since May 2025 the target ends in dkim.mail.microsoft and part of it is assigned by Microsoft, while existing domains keep the older format. The Defender portal and Get-DkimSigningConfig show the exact CNAME values your specific custom domain needs — copy them rather than constructing them by hand.

Prerequisites

• An active Microsoft 365 tenant with at least one custom accepted domain (the domain you want to DKIM-sign mail from). Verify with Get-AcceptedDomain via Exchange Online PowerShell.
• Administrative role assignment: Global Administrator or Security Administrator (the Defender portal DKIM panel requires one of these roles).
• DNS administration rights at your custom domain's authoritative nameservers (to publish the two CNAME records).
• An SPF record already published with include:spf.protection.outlook.com — see SPF for Microsoft 365. SPF + DKIM together is the prerequisite for DMARC alignment.
• Exchange Online PowerShell module installed (optional, only needed for cmdlet-based DKIM management): Install-Module ExchangeOnlineManagement, then Connect-ExchangeOnline.

Step 1: Publish the two CNAME records

Open the Microsoft 365 Defender portal at security.microsoft.com. Navigate to Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Click on your custom domain in the list. The portal displays the two CNAME records you must publish at your authoritative DNS provider:

; Replace example.com with your custom domain and
; tenant with your tenant prefix (visible in the Defender portal):

selector1._domainkey.example.com.  IN  CNAME  selector1-example-com._domainkey.tenant.onmicrosoft.com.
selector2._domainkey.example.com.  IN  CNAME  selector2-example-com._domainkey.tenant.onmicrosoft.com.

Publish both records at your DNS provider (Cloudflare, AWS Route 53, Azure DNS, GoDaddy, Namecheap, Google Cloud DNS, etc.). The exact UI varies, but each provider supports CNAME records natively. Confirm the records are published before proceeding:

$ dig +short selector1._domainkey.example.com CNAME
selector1-example-com._domainkey.tenant.onmicrosoft.com.

$ dig +short selector2._domainkey.example.com CNAME
selector2-example-com._domainkey.tenant.onmicrosoft.com.

Or on Windows PowerShell:

PS> Resolve-DnsName selector1._domainkey.example.com -Type CNAME
PS> Resolve-DnsName selector2._domainkey.example.com -Type CNAME

Allow 24-48 hours for DNS propagation. CNAME publication at the registrar / authoritative nameserver is instant at the source but receivers cache by TTL; until propagation completes for the full receiver population, the Defender portal Enable step will fail.

Step 2: Enable DKIM signing for the custom domain

Two paths — UI (Defender portal) or PowerShell. Both produce the same effect: Exchange Online begins signing outbound mail from the custom accepted domain with the published CNAME's selector1 / selector2 chain.

Defender portal UI

1. Navigate to security.microsoft.com > Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM.
2. Click your custom domain in the list.
3. Toggle Sign messages for this domain with DKIM signatures to On.
4. The portal confirms the change with a status banner; the domain row updates to Enabled: True.

Exchange Online PowerShell

PS> Install-Module ExchangeOnlineManagement
PS> Connect-ExchangeOnline -UserPrincipalName admin@example.com
PS> Set-DkimSigningConfig -Identity example.com -Enabled $true

If Microsoft has not yet detected the CNAME records, the cmdlet returns an error that contains the values to publish, and the domain stays in the CnameMissing state. Check the records for typos, wait a while and re-run.

Once enabled, Exchange Online signs every outbound message from the custom accepted domain with a DKIM-Signature header that includes d=example.com (your custom domain) and s=selector1 or s=selector2 (whichever is currently active).

Step 3: Verify DKIM signing is working

Three verification gates: DNS, configuration, and end-to-end delivery.

Gate 1: DNS resolution

$ dig +short selector1._domainkey.example.com CNAME
selector1-example-com._domainkey.tenant.onmicrosoft.com.
$ dig +short selector1-example-com._domainkey.tenant.onmicrosoft.com TXT
"v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAA..."

The first dig follows your custom-domain CNAME; the second resolves the tenant-side TXT and must return a valid v=DKIM1 record with a non-empty p= public-key field.

Gate 2: Tenant configuration

PS> Get-DkimSigningConfig -Identity example.com | Format-List Enabled,Selector1CNAME,Selector2CNAME,Status
Enabled         : True
Selector1CNAME  : selector1-example-com._domainkey.tenant.onmicrosoft.com
Selector2CNAME  : selector2-example-com._domainkey.tenant.onmicrosoft.com
Status          : Valid

Enabled=True and Status=Valid are the two must-haves; if either is False or anything other than Valid, signing is not happening for that domain.

Gate 3: End-to-end delivery

Send a message from the custom domain to an external mailbox you control (Gmail, Yahoo, your personal Outlook.com account, or DMARC Analyzer's Email Header Analyzer). Open the message headers and locate the Authentication-Results stack:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@example.com header.s=selector1 header.b=AbCdEf12;
       spf=pass (google.com: domain of admin@example.com designates ...)
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Three requirements: (1) dkim=pass, (2) header.i=@example.com (your custom domain, NOT @tenant.onmicrosoft.com), (3) header.s=selector1 or selector2. If item 2 shows the onmicrosoft.com tenant domain, return to the onmicrosoft.com section below.

DKIM key rotation on Microsoft 365

The administrator starts DKIM key rotation for a custom domain; Microsoft does not do it on its own. A rotation generates a new key pair on the standby selector (whichever of selector1 / selector2 is not currently signing) and then switches outbound signing to that selector. The transition is transparent to receivers — both selectors remain published, so messages signed under the previous selector still verify. Microsoft compares key rotation to changing passwords periodically.

How to start a rotation

In the Defender portal, select the domain on the DKIM tab and choose Rotate DKIM keys, or run in PowerShell:

PS> Rotate-DkimSigningConfig -Identity example.com -KeySize 2048

The cmdlet generates a fresh key on the inactive selector. The change is not immediate: the new key starts signing after four days (96 hours), and until then the existing key is used. The CNAME records do not need to change. Rotate regularly, and immediately after any suspected key compromise.

Key-size posture

Today's baseline is 2048-bit RSA keys. According to Microsoft's documentation, New-DkimSigningConfig without the KeySize parameter creates a 1024-bit key, so it is worth checking the key size of your domain:

PS> Get-DkimSigningConfig -Identity example.com | Format-List Selector1KeySize,Selector2KeySize
Selector1KeySize : 2048
Selector2KeySize : 2048

If Selector1KeySize or the second property shows 1024, start a rotation to 2048:

PS> Rotate-DkimSigningConfig -Identity example.com -KeySize 2048

1024-bit RSA keys are considered factorable by well-funded adversaries; RFC 8301 permits them as a minimum and recommends at least 2048 bits, which is what receivers expect today.

The onmicrosoft.com signing-domain gotcha

The number-one M365 DKIM failure mode: outbound mail from example.com arrives at receivers with header.d=tenant.onmicrosoft.com instead of header.d=example.com. DMARC fails because the DKIM-signing domain does not align with the visible From: header domain.

Why it happens

M365 always signs SOMETHING. When DKIM is not explicitly enabled for the custom accepted domain, Exchange Online falls back to signing under <tenant>.onmicrosoft.com using the default DKIM key Microsoft automatically provisions at tenant creation. The default key is real, valid, and signs successfully — but its d= tag points at the tenant routing domain, not at your custom domain.

Symptom in Authentication-Results

Authentication-Results: mx.google.com;
       dkim=pass header.i=@tenant.onmicrosoft.com header.s=selector1-tenant-onmicrosoft-com
       spf=pass (google.com: domain of admin@example.com designates ...)
       dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=example.com

Note: dkim=pass is True (signature verifies cryptographically), but header.i is @tenant.onmicrosoft.com, not @example.com. DMARC alignment fails (the SPF-passing domain may align if SPF is configured, but DKIM is mismatched). Aggregate DMARC reports surface this as dkim=pass + spf=fail + dmarc=fail rows for messages your tenant sent.

Symptom in Get-DkimSigningConfig

PS> Get-DkimSigningConfig -Identity example.com | Format-List Enabled,Status
Enabled : False
Status  : CnameMissing

Enabled=False means signing with the custom domain is not turned on; Status=CnameMissing adds that Microsoft does not (yet) see the CNAME records. Once the records are published, the fix is one cmdlet:

PS> Set-DkimSigningConfig -Identity example.com -Enabled $true

Or via the Defender portal: toggle Sign messages for this domain with DKIM signatures to On.

Seven common Microsoft 365 DKIM mistakes

1. Publishing CNAMEs but never enabling signing — the onmicrosoft.com gotcha above. CNAMEs published correctly are necessary but not sufficient; the Defender portal Enable toggle (or Set-DkimSigningConfig -Enabled $true) is the second required step.
2. Hand-constructing the CNAME target — the target depends on the tenant prefix and on whether the domain uses the older format (onmicrosoft.com) or the newer one (dkim.mail.microsoft). Always copy the exact CNAME values from the Defender portal or from the Get-DkimSigningConfig output rather than building them by hand.
3. Publishing only one selector — both selector1 AND selector2 are required. Only one signs at a time, but the other must be resolvable before the next rotation; Microsoft says to always create both records, because the inactive selector is needed for a seamless rotation.
4. Publishing as TXT instead of CNAME — M365 DKIM is CNAME-only. Operators experienced with cPanel or Google Workspace sometimes publish a v=DKIM1; k=rsa; p=... TXT at the selector location, which the Defender portal cannot use.
5. Forgetting the trailing dot in the CNAME target — depending on the DNS provider's UI, the target may need a trailing dot to be treated as a fully-qualified name. The Defender portal shows the target without the trailing dot; some DNS UIs require it. If dig reports the resolution chain pointing at your-domain.com.<target> you have a missing-trailing-dot bug.
6. Enabling DKIM before Microsoft detects the CNAMEs — the Set-DkimSigningConfig -Enabled $true cmdlet fails and the status stays CnameMissing as long as the CNAMEs are not visible to Microsoft. Check the records with dig, wait a while and try again.
7. Assuming DKIM stops spoofing on its own — DKIM authenticates that a specific signing domain produced the message, but receivers do not enforce on DKIM alone. DMARC is the enforcement layer that consumes DKIM and SPF verdicts. Without DMARC at p=quarantine or p=reject, spoofed mail still delivers regardless of DKIM state.

Troubleshooting decision matrix

Map the observed symptom to the diagnostic next step:

• Symptom: Authentication-Results shows dkim=none.
  Diagnosis: DKIM is not enabled for the sending domain. Run Get-DkimSigningConfig -Identity <your-domain> — likely returns Enabled=False or no config exists for the domain at all.
  Fix: Publish CNAMEs and enable per the Step 1 / Step 2 sections above.
• Symptom: Authentication-Results shows dkim=pass but header.i=@tenant.onmicrosoft.com and DMARC fails.
  Diagnosis: The onmicrosoft.com gotcha. CNAMEs may be published but signing is not enabled for the custom domain.
  Fix: Set-DkimSigningConfig -Identity <your-domain> -Enabled $true.
• Symptom: Authentication-Results shows dkim=fail (body hash mismatch).
  Diagnosis: Message body was modified after signing — a forwarder, mailing list, or security gateway rewrote the body or added a footer. M365 uses c=relaxed/relaxed canonicalization, which tolerates whitespace and header-case changes but not body content modification.
  Fix: For forwarders/gateways in your control, configure ARC sealing (see ARC explained); for upstream forwarders out of your control, accept the failure and rely on DMARC's relaxed-mode SPF + DKIM any-pass-wins alignment.
• Symptom: Set-DkimSigningConfig -Enabled $true returns an error and the status is CnameMissing.
  Diagnosis: Microsoft does not see the CNAME records — propagation is incomplete, or a record has the wrong name or target.
  Fix: Verify CNAMEs resolve from your local resolver (dig +short selector1._domainkey.<your-domain> CNAME) and that the target matches the portal value exactly; wait a while; re-run.
• Symptom: DKIM verifies for messages sent from Outlook on the web but fails for messages sent via SMTP submission from a third-party application.
  Diagnosis: Some SMTP submission paths bypass Exchange Online's DKIM signer (legacy POP/IMAP relays, on-prem hybrid routes, misconfigured SMTP AUTH endpoints).
  Fix: Verify the submission path lands on smtp.office365.com:587 with STARTTLS and AUTH LOGIN — that path always signs. Legacy direct-send endpoints do not.

Frequently asked questions

How do I enable DKIM on Microsoft 365?

Three steps. (1) Publish the two CNAME records the Defender portal displays for your custom domain: selector1._domainkey.<your-domain> CNAME selector1-<dashed-your-domain>._domainkey.<tenant>.onmicrosoft.com and selector2._domainkey.<your-domain> CNAME selector2-<dashed-your-domain>._domainkey.<tenant>.onmicrosoft.com. The dashed-domain transformation converts dots to dashes (example.com becomes example-com). (2) Wait 24-48 hours for DNS propagation, then verify resolution: dig selector1._domainkey.<your-domain> CNAME should return the .<tenant>.onmicrosoft.com target. (3) In the Microsoft 365 Defender portal (security.microsoft.com), navigate to Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM. Select your custom domain and click Enable, or run Set-DkimSigningConfig -Identity <your-domain> -Enabled $true from Exchange Online PowerShell. From this moment Exchange Online signs outbound mail from your custom accepted domain with DKIM-d=<your-domain> instead of d=<tenant>.onmicrosoft.com.

Why does Microsoft 365 use two DKIM selectors?

So that key rotation runs without interruption and without DNS changes. For each custom domain you publish two CNAME records (selector1._domainkey and selector2._domainkey) pointing to two independent key materials in Microsoft's infrastructure. Only one selector signs at any given time; the other is needed for rotation, which is why Microsoft says to always create both records. The administrator starts a rotation, in the Defender portal or with Rotate-DkimSigningConfig; the new key starts signing after four days (96 hours), and until then the existing key is used. Operators never see the private key; it stays entirely in Microsoft's infrastructure. The dual-selector design is what distinguishes M365 DKIM from Google Workspace DKIM (single selector google._domainkey with TXT publication) and cPanel/self-hosted DKIM (single selector default._domainkey with a self-managed key in a TXT record).

Why are my Microsoft 365 messages signed under onmicrosoft.com instead of my custom domain?

Because DKIM was never enabled for your custom accepted domain in the Defender portal. M365 always signs outbound mail with SOME DKIM key — the default key is your tenant.onmicrosoft.com key, which Microsoft provisions automatically when the tenant is created. To get DKIM signing under your custom domain (your-company.com instead of your-company.onmicrosoft.com), you must (1) publish the two CNAMEs for selector1 and selector2 of the custom domain, (2) wait for DNS propagation, then (3) enable DKIM signing for that custom domain via the Defender portal "Enable" toggle or Set-DkimSigningConfig -Identity your-company.com -Enabled $true. Until that explicit Enable call fires, DMARC will fail because the DKIM-signing domain (onmicrosoft.com) does not align with the visible From: header domain (your-company.com). This is by far the #1 cause of DMARC failures on M365 tenants.

What is the difference between Microsoft 365 DKIM and Google Workspace DKIM?

Three structural differences. (1) Record type: M365 publishes CNAMEs delegating to the tenant's key material under <tenant>.onmicrosoft.com; Workspace publishes a TXT record containing the public-key bytes directly. (2) Selectors: M365 uses TWO selectors (selector1 and selector2) and switches between them during a rotation; Google Workspace uses ONE selector (google._domainkey) and the operator creates a new one at rotation. (3) Key publication: in M365 a new key appears behind the same CNAME records with no change in the domain's DNS; in Google Workspace a new public key reaches DNS only when the operator publishes a new TXT record. In both services the private key stays with the provider and the administrator starts the rotation. The practical consequence: an M365 rotation requires no DNS change, a Google Workspace rotation does. Both produce RFC 6376 §3.6.2 compliant v=DKIM1 records that receivers verify identically.

How do I rotate Microsoft 365 DKIM keys manually?

In the Microsoft Defender portal (security.microsoft.com > Email & collaboration > Policies & rules > Threat policies > Email authentication settings > DKIM) select your custom domain and choose Rotate DKIM keys, or run Rotate-DkimSigningConfig -Identity <your-domain> -KeySize 2048 in Exchange Online PowerShell. The rotation creates a new key pair on the inactive selector; the change is not immediate: the new key starts signing after four days (96 hours), and until then the existing key is used. The CNAME records do not need to change as long as both are published. Check key sizes with Get-DkimSigningConfig in the Selector1KeySize and Selector2KeySize properties; if they show 1024, pass -KeySize 2048 when rotating. Microsoft compares key rotation to changing passwords periodically: do it regularly, and immediately after any suspected key compromise.

Why does my DKIM-Signature header show d=onmicrosoft.com after I enabled DKIM for my custom domain?

Most likely DNS propagation is incomplete or the Defender portal Enable click never landed. Microsoft 365 falls back to signing with the <tenant>.onmicrosoft.com key when (a) the selector1 and selector2 CNAMEs for your custom domain do not yet resolve to the .<tenant>.onmicrosoft.com targets, (b) DKIM signing was published in DNS but never enabled in the portal (the Enable toggle on the Defender DKIM panel is OFF or the Set-DkimSigningConfig -Enabled flag is $false), or (c) the sender is mailing through a non-custom-accepted-domain identity. Diagnose with three commands: dig selector1._domainkey.<your-domain> CNAME must return the tenant target; Get-DkimSigningConfig -Identity <your-domain> | Format-List Enabled must return Enabled=True; the failing message's DKIM-Signature header d= tag must match your custom domain. If all three pass, run Set-DkimSigningConfig -Identity <your-domain> -Enabled $true again to force the activation cycle.

Do I need to publish a DKIM ADSP or DMARC record for DKIM on Microsoft 365 to work?

No to ADSP, yes to DMARC if you want enforcement. RFC 5617 DKIM ADSP was deprecated in 2013 (RFC 6376 §5 explicitly states DKIM does not authorise messages by itself); receivers ignore ADSP records and look at DMARC instead. DKIM on M365 functions standalone — Exchange Online signs your mail, downstream receivers verify the signature, and the Authentication-Results header reports the verdict. DMARC enters the picture when you want receivers to enforce a policy when DKIM (or SPF) fails: publish v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain at _dmarc.<your-domain> and read reports for 2-6 weeks before advancing to p=quarantine then p=reject. See help_dmarc_for_microsoft_365.php for the full rollout walkthrough.

Can I bring my own DKIM key to Microsoft 365 instead of using the tenant key?

Not for native Exchange Online signing. The CNAME-delegation model that M365 uses by design places the private key inside Microsoft's tenant infrastructure — operators publish CNAMEs pointing at the tenant key material; they do not publish the public-key bytes directly. Two workarounds exist: (a) for third-party senders relayed via M365 (e.g., a security gateway, mailing-list platform, or marketing tool that signs before relaying through Exchange Online), the upstream sender can sign with its own key and own d= signing domain — Exchange Online preserves DKIM-Signature headers it did not generate; (b) for full DKIM control over the d=<your-domain> identity, an organization must move outbound mail flow out of Exchange Online (custom MTA, third-party signing relay) — incompatible with native M365 send. The pragmatic recommendation: keep native M365 signing on selector1/selector2 with the tenant key, and rotate it regularly from the Defender portal.

Related guides

• DMARC for Microsoft 365 — the full deployment walkthrough where DKIM is Step 2. Read once you have DKIM enabled to advance through DMARC p=none → p=quarantine → p=reject.
• DMARC for Office 365 hybrid — the dual-transport-path DKIM-coordination sibling within the M365 deployment cluster — the M365-cluster-sibling deep dive on the Exchange-hybrid-coexistence topology where the DKIM signing-architecture THIS page documents (the canonical cloud-only Exchange Online dual-selector CNAME-delegated selector1 / selector2 architecture signing with the Microsoft-managed 2048-bit rotated keys) is one half of a DUAL DKIM-SIGNING configuration on hybrid deployments. Where THIS page documents the SINGLE-PATH cloud-only Exchange Online DKIM signing setup, the hybrid-deployment spoke documents the DUAL-PATH DKIM coordination operators with concurrent Exchange-on-prem + Exchange-Online mailbox populations must execute: the on-prem Exchange edge MTA typically signs with the operator's public domain via an Exchange Edge Transport rule (operator-managed key, published as a TXT record at the operator's own DNS authoritative server), while EOP signs cloud-mailbox mail with the CNAME-delegated Microsoft-managed key documented on THIS page — both must pass DKIM- verification AND both must align with the From: header per RFC 7489 §3.1.1 before any DMARC policy advance, because a broken-DKIM-on-one-path failure produces aligned-SPF-but- unaligned-DKIM mail on that path that the DMARC verdict-evaluation will still pass (DMARC is "either-passes"), but which the operator should fix before advancing because the path's DMARC-pass margin is then dependent on SPF authorisation alone. The hybrid topology introduces a coordination challenge the cloud-only DKIM setup documented on this page does not face: the on-prem DKIM-signing key rotation cadence is operator-managed (the operator must manually rotate the on-prem signing key on a documented cadence), while the cloud DKIM-signing key rotation is Microsoft-managed (six-month automatic rotation through the selector1 / selector2 alternation documented on this page) — the operator must coordinate both cadences across the hybrid deployment to avoid a rotation-overlap window where one path's key is stale. Read the hybrid-deployment spoke when the hybrid topology's dual-DKIM-signing configuration interacts with the single-path DKIM signing-setup this page documents — the hybrid spoke documents the dual-transport-path topology variation of the same M365 deployment cluster the cloud-only DKIM-for-M365 spoke lives in. Closes the M365-cluster sibling-orphan parity gap between DKIM-for-Microsoft-365 (single-transport-path cloud-only) and DMARC-for-Office-365-hybrid (dual- transport-path coexistence).
• DMARC for transactional email — the M365-TENANT-DKIM-SIGNING-COVERS- EOP-EGRESS-FOR-CORPORATE-TRANSACTIONAL- STREAMS-WHILE-EXTERNAL-ESP-RELAYED- TRANSACTIONAL-STREAMS-REQUIRE-PARALLEL- PER-ESP-DKIM-DELEGATION companion to this M365 DKIM deployment guide. Where THIS page documents the cloud-only Exchange-Online dual-selector CNAME- delegated selector1 / selector2 DKIM-signing architecture (Microsoft-managed 2048-bit rotated keys, EOP-signed outbound egress per tenant), the transactional-email spoke is the per- message-type deployment companion documenting FOUR M365-tenant- transactional-sender-pattern dimensions: (i) M365-internal corporate transactional streams — Outlook-composed account-lifecycle messages, in-tenant SharePoint sharing-invitation notifications, Teams meeting-invite and recording-shared notifications, Power Automate / Power Apps system- triggered notifications, Microsoft Bookings appointment-confirmation messages → ALL signed by EOP using the dual-selector CNAME-delegated Microsoft-managed signing keys this page documents — the transactional-email spoke documents the canonical M365-internal transactional-stream inventory operators must include in their DMARC-pass-rate floor computation (the dual-selector EOP-signed M365-native transactional stream is typically the easiest stream to achieve the 99%-DMARC-pass-rate BIMI-eligibility floor on, because the CNAME-delegated Microsoft-managed keys handle key-rotation discipline with zero operator-side coordination burden); (ii) External-ESP- relayed transactional streams — SaaS- platform-triggered order confirmations relayed via SendGrid / Mailgun / Postmark / Amazon SES → REQUIRE PARALLEL per-ESP DKIM-signing infrastructure with per-ESP CNAME- delegation patterns DISTINCT FROM the M365 tenant's selector1 / selector2 — the transactional spoke documents the canonical M365-tenant operator failure pattern where the operator configures DKIM for the M365 tenant (this page's setup) but assumes that DKIM-signing posture covers ALL outbound mail from the operator's domain — the external-ESP-relayed transactional streams (e-commerce checkout confirmations triggered by the operator's storefront, password- reset emails triggered by the operator's SaaS authentication provider, OTP delivery triggered by the operator's 2FA platform) flow through DIFFERENT egress paths with DIFFERENT signing-key infrastructure and the operator MUST configure per-ESP DKIM delegation INDEPENDENTLY of the M365 tenant's EOP signing setup; (iii) per-stream subdomain pattern coordination across the M365-tenant boundary — corporate-internal stream on apex domain (signed by EOP) + transactional-stream on dedicated subdomain (signed by ESP) + marketing-stream on dedicated subdomain (signed by separate marketing-automation platform) — the transactional spoke documents the operationally-significant canonical M365-tenant operator anti-pattern where ALL streams are signed at the apex domain (forcing the DMARC-pass-rate floor across EOP-signed + ESP-signed + marketing- signed heterogeneous streams onto the slowest stream's enforcement ramp) and the per-stream-subdomain coordination pattern that decouples each stream's DMARC enforcement ramp INDEPENDENTLY of the others; (iv) M365-tenant per-ESP SPF include: cascade interacts with the M365-tenant SPF include:spf.protection.outlook.com token → 10-DNS-lookup-limit coordination across the combined M365 + external-ESP cascade — the transactional spoke documents the canonical M365-tenant SPF-cascade failure pattern (publish SPF with spf.protection.outlook.com + SendGrid + Mailgun + Amazon SES + Postmark + Salesforce + HubSpot include: tokens and hit PermError at the 10-lookup ceiling), the per-tenant flattening-vs-include trade-off operators face when the M365 tenant emits transactional mail through multiple external ESPs, and the per-tenant Return-Path coordination operators must enforce across the M365 + external-ESP boundary. Read the transactional- email spoke when deploying DKIM in an M365 tenant that emits transactional mail through external ESPs in addition to the EOP-signed M365- native streams documented on this page — the spoke is the authoritative per-message-type operational reference for the M365-tenant-DKIM-meets- external-ESP-transactional-DKIM- coordination cross-cluster boundary within the M365 deployment cluster.
• DMARC for SaaS senders — the M365-TENANT-VS-SAAS-PLATFORM-DKIM- DEPLOYMENT-CONTRAST companion to this M365 DKIM deployment guide. Where THIS page documents the per-M365-tenant single-customer cloud-only EOP-signed dual-selector selector1._domainkey / selector2._domainkey CNAME- delegated Microsoft-managed 2048-bit rotated keys DKIM-signing architecture, the SaaS-senders spoke is the MULTI- TENANT-PLATFORM-OPERATOR-VIEW documenting the structurally-distinct per-customer-domain CNAME-delegation discipline customer-engagement-platform operators (Mailchimp / HubSpot / Marketo / Pardot / Klaviyo / Salesforce Marketing Cloud / Shopify / BigCommerce) apply to the same DKIM publication primitive at FOUR per-M365-tenant-vs- SaaS-platform deployment-contrast dimensions: (i) single-customer- domain vs multi-tenant-shared-pool key- management — M365 publishes one per-tenant CNAME pointing at a per-tenant Microsoft-managed key target; SaaS platforms publish per-customer CNAMEs pointing at a master-zone per-customer key target the platform operator manages across the entire customer fleet; (ii) per-tenant-managed vs platform-managed rotation cadence observability — M365 Microsoft- managed rotation is OPAQUE to the tenant (the selector1 / selector2 alternation happens behind the CNAME automatically); SaaS-platform master-zone rotation is OPAQUE to the customer-domain operator (the platform operator rotates k1 → k2 → k3 on their schedule and customers observe the rotation only by watching the s= selector field in decoded-RUA dkim=pass entries cycle through the per-customer CNAME-target rotation cadence); (iii) per- tenant cloud-egress IP-pool vs SaaS- platform shared-tenant-pool IP source- IP attribution — M365 outbound mail egresses through Exchange-Online Protection's per-tenant-attributable cloud-egress IP pool; SaaS-platform outbound mail egresses through the platform's shared-tenant pool IPs with NO sub-tenant differentiation in the RUA aggregate-report's source_ip column, creating the cross-tenant-attribution gap the SaaS-senders spoke documents; (iv) per-tenant-DKIM-failure- attribution vs platform-wide-DKIM- rotation-event-attribution operator coordination — M365 DKIM-pass- rate troughs attribute directly to the per-tenant CNAME-target configuration; SaaS-platform DKIM-pass-rate troughs attribute either to a per-customer CNAME-target misconfiguration the customer can fix unilaterally OR to a platform-wide master-zone rotation drift the customer can only escalate through platform-side support — the spoke documents the per-attribution- class coordination workflow. Pair this M365 DKIM deployment guide (the single-customer-domain per-tenant CNAME- delegation reference) with the SaaS- senders spoke (the multi-tenant- platform per-customer CNAME-delegation reference) for any operator running BOTH an M365 tenant AND outbound mail delegated to a SaaS multi-tenant platform.
• SPF for Microsoft 365 — the SPF operator reference. SPF + DKIM together are the alignment prerequisite for DMARC enforcement.
• SPF 10-DNS-lookup limit (RFC 7208 §4.6.4) — the M365-TENANT-CASCADE-AS-LOAD-BEARING- CANONICAL-CONSUMER-OF-THE-10-DNS-LOOKUP- BUDGET-CEILING companion to this M365 DKIM deployment guide. Where THIS page documents the M365-tenant DKIM deployment workflow (dual-selector selector1._domainkey / selector2._domainkey CNAME delegation, the per-tenant Microsoft-managed key-rotation cadence, and the M365 Defender / EAC enablement procedure), the SPF-lookup-limit spoke is the BUDGET-ACCOUNTING REFERENCE documenting the per-mechanism cost M365-tenant operators MUST track to avoid the RFC 7208 §4.6.4 permerror receiver-side rejection that STRUCTURALLY-DOWNGRADES the DMARC composite verdict from pass to fail (and therefore weakens the per-tenant per-custom-domain anti-spoofing posture the DKIM-deployment on THIS page operationalizes). FOUR per-M365-tenant SPF-budget-consumption dimensions: (i) M365-tenant include:spf.protection.outlook.com canonical-cascade inherited cost — every M365 tenant's published SPF record MUST contain include:spf.protection.outlook.com to authorise Exchange Online's *.mail.protection.outlook.com outbound IPv4 + IPv6 blocks; the SPF- lookup-limit spoke documents the per- include recursive-expansion accounting algorithm receivers apply at evaluation time and the measured per-receiver-side ~3-5-lookup expansion cost of the Microsoft-managed include cascade; (ii) M365-tenant third-party-ESP include-accumulation cost — when the M365 tenant uses transactional ESPs (SendGrid include:sendgrid.net ~2-3 lookups, Mailgun include:mailgun.org ~2 lookups, Amazon SES include:amazonses.com ~3 lookups), the cumulative budget consumption is the canonical permerror-trigger M365 tenant operators encounter; the SPF-lookup-limit spoke documents the per-ESP measured-cost table M365 tenants use to budget the remaining capacity in the 10-lookup ceiling; (iii) M365-tenant SPF- flattening as DMARC-DKIM-RELIANCE- STRENGTHENING discipline — when the M365-tenant SPF budget saturates, operators rely on the per-tenant DKIM signature (the deployment THIS page documents) as the sole alignment input to the DMARC composite verdict; the SPF- lookup-limit spoke documents the per-budget-overflow operational decision points where the per-tenant DKIM deployment ON THIS page becomes the load- bearing alignment input; (iv) M365- tenant void-lookup risk on stale-include operator-tracking — RFC 7208 §4.6.4 also imposes a void-lookup cap of 2 (TXT lookups returning NXDOMAIN); M365 tenants retaining include: tokens for legacy ESPs whose authorization-SPF sub-record has been retired silently accumulate void- lookups on every receiver-side evaluation; the SPF-lookup-limit spoke documents the void-lookup cap enforcement contract AND the canonical operator-side monitoring discipline (DMARC-aggregate-report spf=permerror row inspection) M365 tenants apply to detect void-lookup accumulation BEFORE the 2-cap saturates and breaks SPF evaluation across the entire M365-tenant custom-domain. Pair this M365 DKIM deployment page with the SPF-lookup-limit spoke (the per-mechanism budget-accounting reference) when authoring the M365-tenant outbound-egress SPF cascade — the spoke documents the per-vendor measured-cost matrix AND the void-lookup cap that M365 tenants must budget BEFORE publishing the SPF record at the M365-tenant DNS-zone-editor.
• SPF permerror vs temperror — the SPF-VERDICT-CLASS-TAXONOMY- PARALLEL-TO-DKIM-VERDICT-CLASS-TAXONOMY companion to this M365 DKIM deployment guide. Where THIS page documents the per- M365-tenant per-custom-domain DKIM dual- selector CNAME-delegation deployment workflow (selector1._domainkey / selector2._domainkey CNAME- delegation at the M365-tenant DNS-zone- editor + Microsoft-managed key-rotation cadence + Defender / EAC enablement procedure), the SPF-permerror-vs-temperror spoke is the VERDICT-CLASS-TAXONOMY- DISTINCTION reference documenting the per- message spf=permerror vs spf=temperror verdict-class distinction whose receiver-side per-message DMARC-composite-verdict-evaluation disposition (permerror → SPF-leg permanent fail per RFC 7489 §6.6.2 invalidating the SPF-leg of DMARC alignment disjunction; temperror → receiver-side retry semantics per RFC 7489 §6.6.2 deferring SPF-leg verdict pending re-resolution) is the STRUCTURAL PARALLEL to the per-M365-tenant per-custom-domain DKIM verdict-class taxonomy at FOUR per-M365-tenant-DKIM- deployment-vs-SPF-permerror-temperror- verdict-class-taxonomy coupling dimensions: (i) per-tenant per- custom-domain DKIM-CNAME-delegation permerror at per-tenant per-domain onboarding ↔ SPF-record-malformed permerror at per-tenant per-domain publication — per-M365-tenant DKIM CNAME-delegation produces dkim= permerror when the operator forgets to publish the selector1._domainkey + selector2._domainkey CNAME pair OR publishes a malformed selector record at the per-tenant DNS-zone- editor; per-tenant SPF include:spf. protection.outlook.com cascade produces spf=permerror when the per-tenant SPF record is malformed at the per-tenant DNS-zone-editor — both per-message verdict-class taxonomy outcomes are PERMANENT-DNS-RESOLUTION-FAILURE verdict-class taxonomy outcomes whose per- receiver per-message DMARC composite- verdict-evaluation collapses the affected authentication-leg structurally per RFC 7489 §6.6.2; (ii) per-tenant per- domain DKIM-CNAME-delegation temperror at per-receiver per-resolver transient DNS- cache-eviction ↔ SPF-cascade temperror at per-receiver per-resolver spf.protection.outlook.com SERVFAIL — per-M365-tenant DKIM CNAME-delegation produces dkim= temperror when per-receiver per- resolver per-message DNS resolution transiently fails (SERVFAIL / authoritative- NS-timeout / cache-eviction); per-tenant SPF include:spf.protection.outlook. com cascade produces spf= temperror when per-receiver per- resolver per-message DNS resolution transiently fails at any of the ~3-5 recursive sub-lookups — both per-message verdict-class taxonomy outcomes trigger receiver-side retry semantics per RFC 7489 §6.6.2 deferring per-leg verdict pending per-receiver per-resolver re-resolution; (iii) per-receiver per-day DMARC RUA policy_evaluated/dkim=permerror ↔ policy_evaluated/spf= permerror attribution stream as cross-leg per-tenant per-domain publication-discipline-drift observability signal — per-receiver per- day DMARC RUA aggregate-XML policy_evaluated/dkim=permerror + policy_evaluated/spf=permerror per-source-IP attribution stream is the load-bearing observability signal per-M365- tenant operators consume to triage per- tenant per-domain CNAME-delegation publication-discipline-drift (DKIM-leg) AND per-tenant SPF-record publication- discipline-drift (SPF-leg) at the per- tenant per-day per-source-IP attribution granularity; (iv) per-message verdict-class taxonomy receiver-side retry-semantics protocol-state-machine coupling per RFC 7489 §6.6.2 — receiver-side per-message DMARC composite-verdict-evaluation protocol-state-machine treats per-leg permerror verdict as PERMANENT- FAIL collapsing the affected leg from the DMARC alignment-disjunction, while per-leg temperror verdict triggers receiver-side retry-semantics (typical retry-interval 5-15 minutes per per- receiver-implementation) deferring the per- message DMARC composite-verdict pending re-resolution — per-M365-tenant operators triaging per-message policy_evaluated attribution rows MUST distinguish per-message permerror (permanent publication-discipline-drift defect) from per-message temperror (transient per-receiver-resolver state), and the SPF-permerror-vs-temperror spoke documents this verdict-class taxonomy distinction the M365-tenant-side DKIM verdict-class taxonomy directly mirrors. Read the SPF-permerror-vs-temperror spoke when interpreting per-M365-tenant per- domain per-receiver per-day RUA policy_evaluated/dkim=permerror / policy_evaluated/dkim=temperror attribution rows whose verdict-class taxonomy is structurally identical to the per-tenant SPF-cascade policy_evaluated/spf=permerror / policy_evaluated/spf=temperror attribution rows the spoke documents.
• MTA-STS for Microsoft 365 — the transport-security companion in the M365 deployment set. Once SPF + DKIM + DMARC are at p=reject the next gap is opportunistic-TLS downgrade: senders to your M365 tenant can be intercepted by STARTTLS-stripping middleboxes unless MTA-STS forces them to require TLS. Covers the canonical *.mail.protection.outlook.com mx: list, where to host the /.well-known/mta-sts.txt file for an Exchange Online tenant, the testing-mode burn-in workflow paired with TLS-RPT, and the M365-specific gotchas (the absence of DANE for inbound, the EOP outbound TLS posture). Audit it alongside SPF + DKIM whenever you review the M365 email-authentication stack.
• MTA-STS vs DANE for SMTP — the M365-TENANT-TRANSPORT-LAYER- SECURITY-MECHANISM-PRE-DETERMINED-AS- MTA-STS-DUE-TO-EXCHANGE-ONLINE-NO-DANE- SUPPORT companion documenting why the M365-tenant transport-layer-security choice between MTA-STS and DANE is STRUCTURALLY PRE-DETERMINED in favour of MTA-STS by Microsoft's platform- engineering decision NOT to deploy DNSSEC-signing on the protection.outlook.com infrastructure. Where THIS page documents the M365-tenant DKIM deployment workflow (the dual-selector selector1._domainkey / selector2._domainkey CNAME delegation to selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com and the corresponding selector2 target, the Microsoft 365 Defender / Exchange- Admin-Center DKIM-enablement procedure, the per-tenant key-rotation cadence Microsoft auto-manages for the signing- domain identifier, the per-tenant onmicrosoft.com-vs-custom- domain Friendly-From-header signing scope, and the CNAME-chase troubleshooting for the dkim=permerror / dkim=temperror common failure modes), the MTA-STS-vs-DANE comparison spoke documents the OPERATOR-FACING TRANSPORT-LAYER-SECURITY DECISION REFERENCE that an M365-tenant operator encounters when scoping the transport-layer-security component complementing the DKIM-application-layer deployment THIS page documents: M365 tenants are STRUCTURALLY PRE-DETERMINED into MTA-STS because the inbound MX target <tenant>-com.mail.protection.outlook.com (and the generic *.mail.protection.outlook.com wildcard) is not served behind a DNSSEC-signed zone — the parent protection.outlook.com zone is unsigned, and Microsoft has publicly stated they have no roadmap to introduce DNSSEC on the Exchange Online platform. DANE (which requires the receiver's MX hostname to resolve via a DNSSEC-signed chain) is therefore STRUCTURALLY UNAVAILABLE for inbound mail to any M365 tenant, and MTA-STS (which uses the X.509 CA-chain trust-model and is deployable on any DNS zone without DNSSEC) is the ONLY RFC-standardised transport-layer- security mechanism the M365 tenant can deploy to close the STARTTLS-strip / opportunistic-TLS-downgrade / forged-MTA-CA / BGP-hijack transport- layer attack vectors. Read the MTA-STS-vs-DANE comparison spoke alongside this M365 DKIM deployment guide when scoping the transport-layer- security component complementing the DKIM-application-layer deployment — the comparison spoke documents the decision rationale that M365 tenants deploy MTA-STS not as a free choice but as the only available RFC-standardised option given Microsoft's no-DNSSEC platform-engineering decision. Closes the DKIM-deployment-cluster ↔ MTA-STS-cluster bridge whereby the M365-tenant transport-layer-security mechanism choice (MTA-STS, not DANE) is the STRUCTURAL TRANSPORT-LAYER COMPLEMENT to the DKIM-application- layer deployment workflow THIS page documents.
• DANE for SMTP — the DANE-AS-EXPLICITLY-UNAVAILABLE-FOR- M365-INBOUND companion documenting the DNSSEC-anchored TLSA-publication mechanism whose explicit UNAVAILABILITY at the protection.outlook.com infrastructure is the load-bearing platform-engineering precondition that FORCES the M365-tenant operator into the MTA-STS-as-only-option transport-layer choice the M365 DKIM deployment workflow THIS page documents must coordinate with. Documents FOUR M365-tenant DANE- decision-consequence dimensions (Microsoft's platform-engineering decision NOT to DNSSEC-sign the protection.outlook.com infrastructure removes the TLSA-publication prerequisite at the receiver-MX surface, making DANE STRUCTURALLY UNAVAILABLE for any sender attempting TLS enforcement to an M365 inbox — the operator CANNOT publish TLSA at the EOP-controlled MX target and receiving-side DANE-validation is impossible by design; the M365-tenant operator's downstream operational constraint is that the TRANSPORT-layer security choice for inbound mail is PRE-DETERMINED as MTA-STS exclusively, BUT the M365-tenant operator's OUTBOUND mail flow CAN encounter DANE-validating receivers at the destination — when M365 outbound mail delivers to a recipient domain whose receiving MX publishes TLSA records, Microsoft's outbound EOP infrastructure DOES validate the receiver-side TLSA chain since 2022, so DANE is part of the OUTBOUND M365 mail path even though it is unavailable on the inbound M365 mail path; the M365- tenant DKIM signing infrastructure documented HERE produces per-message DKIM signatures whose downstream- receiver-side DKIM verification can be BLOCKED at the transport-layer if the receiver enforces DANE and the intermediary mail-relay fails the TLSA-chain validation — DKIM-application- layer signing must coordinate with the transport-layer DANE-or-MTA-STS infrastructure at every per-hop boundary the message traverses; the receiver-side DANE-enforcement posture observability is per-recipient-domain — M365-tenant operators monitoring DKIM-pass-rate outcomes per-recipient-domain MUST cross-reference per-recipient-domain DANE-enforcement-posture data to attribute per-recipient-domain DKIM- downstream-block events correctly, rather than misattributing transport- layer DANE failures as DKIM-signing- layer regressions). Read the DANE explainer spoke when authoring M365- tenant operational documentation that must explain WHY MTA-STS is the only receiver-side TLS-enforcement mechanism available for inbound M365 mail — the DANE spoke documents the DNSSEC-anchored TLSA mechanism whose unavailability at M365 is the load-bearing structural precondition for the MTA-STS-only choice.
• MX records explained — the DNS-RR foundation whose <tenant>.mail.protection.outlook.com single-MX target routes inbound mail to the Exchange Online MTA — the M365-MX-FOUNDATIONAL-INBOUND-DELIVERY companion to this M365 DKIM deployment guide. Where THIS page documents the M365-specific DKIM signing workflow (the selector1._domainkey / selector2._domainkey CNAME-delegated pair pointing at selector1-<tenant>-com._domainkey.<tenant>.onmicrosoft.com, the Exchange Admin Centre key-rotation workflow, the 2048-bit key upgrade path), the MX-records spoke documents the DNS-RR-MECHANICS-LAYER reference the M365 inbound-mail-flow gates on: the canonical single-MX <tenant>.mail.protection.outlook.com target M365 mandates for inbound mail delivery to Exchange Online, the <preference> <target> wire format (RFC 1035 §3.3.9), the per-MX preference-value semantics, the Microsoft-managed A/AAAA resolution chain behind the mail.protection.outlook.com endpoint, the nslookup -type=MX / dig MX diagnostic workflow the M365 Setup & Domain Verification wizard relies on, and the co-existence-with-Connectors anti-pattern where MX is left pointing at a legacy on-prem Exchange behind a Connector instead of M365. Read the MX-records spoke alongside this DKIM-for-M365 deployment guide when an inbound delivery to the M365 tenant fails and the operator must verify whether the failure layer is MX publication, Microsoft-managed A/AAAA resolution, or downstream EOP routing.
• DKIM explained — the protocol primer covering RFC 6376 mechanics, signing pipeline, header canonicalization, and the Authentication- Results stack.
• DKIM alignment with DMARC — the M365-TENANT-DKIM-D-DOMAIN-VS-HEADER- FROM-DOMAIN-ALIGNMENT-AT-EOP-OUTBOUND- PIPELINE companion to this Microsoft-365- DKIM-deployment guide. Where THIS page documents the M365 Defender portal's "Enable DKIM signing" toggle workflow and the EOP-side outbound-pipeline DKIM-signing mechanics (the selector1._domainkey.<tenant-domain> CNAME-delegation chain resolving to selector1-<tenant-domain-with-dashes>._domainkey.<onmicrosoft-tenant>.onmicrosoft.com), the DKIM-alignment-with-DMARC spoke is the DKIM-PASS-VERDICT-IS-NECESSARY-BUT-INSUFFICIENT- FOR-DMARC-PASS reference documenting the receiver-side organizational-domain alignment step every M365-tenant message must clear AFTER the receiver verifies the DKIM signature byte-correctness. The M365-DKIM- ALIGNMENT-FAILURE-MODE-CATALOGUE cross- reference establishes FOUR structurally- distinct M365-specific DKIM-alignment- failure-mode dimensions where the DKIM-alignment spoke is the load-bearing receiver-side decision reference: (i) M365 tenant uses <tenant>.onmicrosoft.com domain in From-header but DKIM-Signature d= declares the custom organizational domain (or vice-versa) → alignment failure — M365 tenants operating dual-domain workflows (production on the custom domain, internal on the onmicrosoft alias) frequently emit messages where the From-header domain and the DKIM-Signature d= domain diverge; the DKIM-alignment spoke documents the RFC 7489 §3.1.1 organizational-domain alignment rule (Public Suffix List + 1 label) that the receiver applies — a divergence between From-header organizational domain and DKIM-Signature d= organizational domain produces dkim- alignment=fail despite the DKIM signature verifying as cryptographically valid; (ii) third-party SMTP-AUTH submission from outside M365 produces external-signer DKIM-Signature with non-aligned d= — M365 tenants permitting third-party SMTP-AUTH submission (Mailchimp, SendGrid, Mailgun authenticating against EOP connectors) frequently get the THIRD-PARTY platform's DKIM signature added by the platform's own MTA pipeline, with the d= tag declaring the platform's domain (sendgrid.net, mailgun.org) not the M365 tenant's organizational domain; without proper per-platform DKIM-CNAME delegation at the tenant's DNS zone, these messages emit dkim=pass but dkim-alignment=fail per the spoke's documented evaluation rule; (iii) Centralized Mail Transport (CMT) hybrid topology with on-prem- signing-before-EOP-egress produces double-signed messages where alignment depends on signature-ordering — M365 hybrid deployments with on-premise Exchange signing messages BEFORE forwarding to EOP for egress produce messages with TWO DKIM-Signature headers (on-prem signer + EOP); the receiver-side DMARC alignment evaluator considers BOTH signers' d= values for alignment per RFC 7489 §3.1.1 (any aligned signer produces dkim- alignment=pass) — but the alignment spoke documents the per-signer alignment-decision-tree the receiver walks to determine which signer wins; (iv) EOP outbound rewrite scenarios (DLP-triggered footer injection, transport-rule body-modification) producing post-sign body-hash mismatch → DKIM-signature-fail and dkim- alignment=fail in parallel — when EOP's outbound DLP or transport rules modify the message body AFTER the DKIM signing step (a known operational defect when DLP rules sit downstream of the DKIM-sign pipeline), the receiver-side body-hash recomputation fails → dkim=fail → the alignment evaluator never reaches the d=-vs-From-domain decision step because dkim=fail forces dkim-alignment to inherit the fail; the spoke documents the dkim=fail-as-input- to-alignment-evaluation receiver decision tree the M365 tenant must understand to attribute the failure correctly. Read the DKIM-alignment-with-DMARC spoke alongside this M365 DKIM deployment guide when auditing per-tenant DKIM Authentication-Results headers in receiver-side message-trace data — the spoke is the canonical receiver-side decision reference whose four alignment-failure-mode dimensions directly map to M365-tenant deployment defects this page diagnoses.
• DKIM-Signature header format — the M365-EOP-SIGNED-EGRESS-PER-MESSAGE- HEADER-BYTE-LAYOUT companion to this Microsoft-365-DKIM-deployment guide. Where THIS page documents the Defender portal workflow at security.microsoft.com → Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM and the per-tenant publisher-side dual-selector CNAME- delegation lifecycle (publish selector1._domainkey + selector2._domainkey CNAMEs → Enable DKIM signing toggle → EOP-signed egress with Microsoft-managed 2048-bit key rotation alternating between the two selectors on a six-month cadence), the DKIM-signatures-explained spoke documents the BYTE-LAYOUT of the actual DKIM-Signature: header that EOP's signing gateway prepends to every outbound message once the toggle flips on — the canonical RFC 6376 §3.5 tag- value grammar covering the eight load- bearing tags every receiver parses to verify M365 egress: (i) v=1 version, (ii) a=rsa-sha256 algorithm (EOP default; the legacy rsa-sha1 is deprecated per RFC 8301 and EOP does NOT emit it), (iii) d=<domain> signing domain (the M365 tenant's primary domain; the receiver compares this against the From: header's organizational-domain for DMARC alignment — the cross-link to the dmarc-for- microsoft-365 spoke's enforcement-cadence playbook this page already documents), (iv) s=selector1 or s=selector2 selector (alternates on EOP's six-month automatic rotation per the dkim-key-rotation spoke — the dual-selector overlap window is the receiver-side rationale for why both selector1._domainkey AND selector2._domainkey CNAMEs must be published before the Enable DKIM signing toggle flips), (v) c=relaxed/relaxed canonicalization (EOP default; the cross-link to the dkim-canonicalization spoke), (vi) h=<header-list> signed-header roster (EOP signs the canonical From, To, Subject, Date, Message-ID, MIME-Version, Content-Type roster plus M365-specific X-MS-Exchange-* headers the EOP signing-policy table enumerates), (vii) bh=<base64> body-hash (the SHA-256 hash of the canonicalised body, computed before the signature is signed), (viii) b=<base64> signature value (the RSA-signed hash of the canonicalised signed-headers list + body-hash). Read the dkim-signatures- explained spoke when DEBUGGING an M365 DKIM verification failure surfacing in receiver Authentication-Results (the receiver-side spec-cross-reference for "what tag in the DKIM-Signature header is the verifier complaining about") OR when AUTHORING a receiver-side DKIM- verification policy that interacts with EOP-signed egress (the receiver-side bytes EOP produces are what the verifier consumes). The dkim-signatures-explained spoke completes the M365-DKIM publisher- side STACK: dkim_explained = protocol primer, dkim_dns_syntax = published-key TXT-record byte format (which the M365 CNAME-delegation chain ultimately resolves to), dkim-signatures-explained = per-message DKIM-Signature header byte format, dkim_canonicalization = the c= tag's body-and-header transformation, dkim_selectors_explained = the s= tag's dual-selector M365 rotation semantics.
• DKIM DNS record syntax — the M365-CNAME-DELEGATION-TARGETS- RESOLVE-TO-MICROSOFT-MANAGED-DKIM-DNS- BYTE-SYNTAX companion to this Microsoft 365 DKIM deployment guide. Where THIS page documents the M365-tenant-specific DKIM deployment surface (the Defender portal workflow, the selector1._domainkey + selector2._domainkey CNAME delegation pattern pointing to selector{1,2}-<domainGuid>._domainkey.<tenant>.onmicrosoft.com, the Set-DkimSigningConfig / Rotate-DkimSigningConfig cmdlets, the onmicrosoft.com signing fallback gotcha), the DKIM DNS-record- syntax spoke is the BYTE-SYNTAX REFERENCE documenting the RFC 6376 §3.6.1 TXT-record format Microsoft actually publishes at the resolved CNAME target. The M365-CNAME- DELEGATION-TARGETS-RESOLVE-TO- MICROSOFT-MANAGED-DKIM-DNS-BYTE-SYNTAX cross-reference establishes four M365-CNAME-specific resolution mappings: (i) M365 tenant publishes selector1._domainkey.<domain> CNAME selector1-<guid>._domainkey.<tenant>.onmicrosoft.com — the receiver-side DNS lookup follows the CNAME to Microsoft's authoritative zone where the TXT record is published in the byte-syntax THIS deployment page describes operationally and the DNS- record-syntax spoke documents byte-by- byte (v=DKIM1; k=rsa; p=...); (ii) Microsoft-managed 2048-bit RSA keys post-2024 platform update — the published p= tag value in Microsoft's zone is a 2048-bit BASE64-encoded RSA public key chunked into multiple 255-octet TXT substrings per the chunking rule the byte-syntax spoke documents; THIS page documents the operator-side activation via Defender portal / Set-DkimSigningConfig; (iii) Rotate-DkimSigningConfig atomic dual-selector swap — rotation publishes a new TXT record at the dormant selector target while the active selector continues serving; the byte-syntax spoke documents the p=-empty revocation semantics Microsoft uses on the retiring selector once the rotation completes; (iv) onmicrosoft.com fallback selector format — when custom-domain DKIM is NOT enabled, Microsoft signs with d=<tenant>.onmicrosoft.com and the receiver fetches the published TXT record at that fallback selector path; the byte-syntax spoke documents the byte format of that fallback record so operators understand WHY the dkim= pass verdict shows the d=onmicrosoft.com domain instead of the desired custom-domain. Read THIS page for the M365-tenant deployment workflow; read the DKIM DNS- record-syntax spoke for the byte-format REFERENCE describing what Microsoft actually publishes at the CNAME-delegated zone (and what every verifying receiver consumes during signature verification).
• DKIM canonicalization — the deep dive on the c=relaxed/relaxed tag M365 uses by default and the simple-vs-relaxed tradeoff.
• DKIM selectors explained — the cross-provider selector deep dive with the full per-provider naming catalogue (M365 selector1/selector2, Workspace google, cPanel default, SendGrid s1/s2, etc.).
• DKIM key rotation — the cross-provider rotation reference. In M365 the administrator starts a rotation, and it needs no DNS change.
• DKIM best practices — the M365-TENANT-DKIM-DEPLOYMENT- CONSUMER-OF-DKIM-KEY-CRYPTOGRAPHY-AND- SIGNING-HYGIENE-OPERATOR-REFERENCE companion reference. Where THIS page documents the M365-tenant CNAME- delegated EOP selectors mechanics (selector1/selector2 CNAME → Microsoft- managed TXT publication; six-month automatic rotation cadence; tenant- side enable/disable lifecycle from the Defender Email Authentication settings page), the dkim_best_practices spoke is the CROSS-PROVIDER OPERATOR- HYGIENE canonical reference documenting the key-cryptography + signing-hygiene + selector-custody + rotation-discipline invariants the M365-tenant operator structurally consumes even when Microsoft manages the day-to-day selector custody. FOUR structurally-distinct M365-TENANT- DKIM-BEST-PRACTICES-CONSUMER dimensions the operator-hygiene spoke defines that this M365-tenant page structurally consumes: (i) RFC 8301 2048-bit RSA key-size discipline AS THE M365-TENANT-INHERITED OPERATOR- HYGIENE INVARIANT for cross-receiver DKIM-pass robustness against per- receiver weak-key-deprecation policy — the dkim_best_practices spoke documents the RFC 8301 weak-key deprecation pressure that mailbox providers (Gmail, Yahoo, Outlook, Apple) progressively apply against sub-2048-bit RSA signatures (1024-bit flagged as weak from 2023 onwards, rejected outright by Gmail from October 2024); M365's CNAME-managed selectors publish 2048-bit RSA keys by default (verified at dig +short TXT selector1._domainkey.<tenant>.onmicrosoft.com via the EOP-managed CNAME-target publication), aligning M365-tenant DKIM-pass-rate posture with the cross- receiver weak-key-deprecation floor the dkim_best_practices spoke catalogues; the M365 operator inherits this 2048-bit posture without publishing the key material directly (the CNAME-delegation transfers custody to Microsoft) but should verify the delegation target periodically (dig +short CNAME selector1._domainkey.<tenant> returns selector1-<tenant-onmicrosoft>._domainkey.<tenant>.onmicrosoft.com); (ii) RFC 6376 §3.6.1 k=rsa + h=sha256 signing-algorithm discipline AS THE M365-TENANT-INHERITED HASH-ALGORITHM CHOICE — the dkim_best_practices spoke documents the RFC 6376 + RFC 8301 signing-algorithm baseline (RSA-SHA-256 as the receiver-canonical default; ED25519 per RFC 8463 as the next-generation alternative); M365's managed selectors publish k=rsa; h=sha256 tag defaults; the M365-tenant operator inherits these algorithm choices via the CNAME-delegated publication AND inherits the operator-side review obligation (when ED25519 becomes the receiver-canonical default in the future, M365's selector- management transition becomes a tenant- observability concern); (iii) per- selector custody discipline AS THE M365- TENANT-DELEGATED-CUSTODY OPERATOR- HYGIENE BOUNDARY — selector custody rotates to Microsoft via CNAME- delegation, BUT the per-selector publication-position discipline remains tenant-controlled — the dkim_best_practices spoke documents per-selector custody discipline (one selector per signer-infrastructure instance; no selector-reuse across operator-distinct signers; selector- retirement-on-no-traffic discipline); for the M365-tenant operator, the selector1/selector2 CNAME-delegation custody transfer to Microsoft means the M365 tenant operator does NOT manage the day-to-day selector-rotation cutover but DOES manage the per-domain CNAME-publication discipline (per organisational domain published with the custom-domain DKIM feature in Defender); when authoring a multi-signer M365 deployment (M365 signing + third-party ESP signing for marketing mail under the same organisational domain), the per-selector custody discipline the dkim_best_practices spoke documents becomes the boundary discipline (M365 selectors selector1/selector2 are custody-delegated to Microsoft; the ESP's distinct selector e.g. s1._domainkey.<domain> is custody-managed by the ESP — NEVER reuse a Microsoft-managed selector name for a non-Microsoft signer); (iv) RFC 6376 §3.6.1 overlap-window rotation discipline AS THE M365-MANAGED- SIX-MONTH-AUTOMATIC-ROTATION-CADENCE OPERATOR-INHERITED INVARIANT — the dkim_best_practices spoke documents the overlap-window rotation discipline (publish new selector ≥7 days before retiring the old; per-rotation per-receiver DKIM-pass-rate monitoring; per-rotation t=y-tag-emission discipline for test-mode); M365's six-month automatic rotation cadence operationalizes this discipline at the managed-selector tier (Microsoft handles the cutover; operator inherits the per-rotation DKIM-pass-rate observability obligation via per-day RUA aggregate- report monitoring). Read the dkim_best_practices spoke alongside this M365-tenant page when authoring the cross-provider DKIM-hygiene posture an M365-tenant organisation deploys — the operator-hygiene spoke is the cross-provider operator-reference every M365-tenant deployment inherits even when CNAME-delegation transfers day-to-day custody to Microsoft.
• DKIM replay attacks — the threat-model deep dive on signature-replay risk, dwell-time bounding via rotation, and the operator-side defenses Microsoft already implements automatically.
• DKIM troubleshooting — the symptom-driven debugging companion for the M365-specific DKIM failure patterns this page documents. The canonical M365 DKIM failure modes — CNAME-delegation propagation timing (the selector1-<tenant>.<initial>._domainkey.<tenant>.onmicrosoft.com chain takes hours to propagate after portal enable), the d=<tenant>.onmicrosoft.com DMARC-alignment gotcha (DKIM passes but alignment fails because the d-domain is the tenant initial-domain, not the public sending domain), the selector1 / selector2 rotation misalignment (Microsoft rotates one selector while the other is in active use; signing key mismatch produces dkim=fail on a small percentage of messages until the new selector propagates) — all map to specific symptom paths in the troubleshooting page. Read this when the M365 DKIM deployment is in place but Authentication-Results headers or aggregate-report payloads show unexpected dkim=fail / dkim=permerror / dkim=temperror results.
• DKIM failure verdicts explained — the PER-VERDICT-RECEIVER-SIDE-DKIM- FAIL-DECODE-FOR-M365-EOP-SIGNED-EGRESS- AND-CNAME-DELEGATED-SELECTOR-PROPAGATION- AND-TENANT-RENAME-AND-DUAL-SELECTOR- ROTATION-FAILURE-MODES companion to this M365-tenant DKIM-deployment guide. Where THIS page documents the Microsoft 365 Exchange Online Protection (EOP) DKIM- signing deployment (Defender-portal- enabled per-tenant signing, dual-selector selector1 / selector2 publication via Microsoft-managed CNAME delegation to selector{1,2}-<tenant>.<initial>._domainkey.<tenant>.onmicrosoft.com, Microsoft-managed automatic key rotation, per-tenant Defender-portal-managed selector toggle), the dkim-failures-explained spoke documents the receiver-side per-verdict decode reference operators consume to diagnose the canonical M365-tenant DKIM- deployment failure modes when the Authentication-Results headers or aggregate-report payloads surface unexpected non-dkim=pass verdicts. Four M365-DKIM-DEPLOYMENT-VS- DKIM-VERDICT-FAILURE-MODE-DECODE axes the dkim-failures-explained spoke documents that converge on this provider deployment: (i) CNAME-delegation propagation timing-gap as dkim=permerror verdict — when the operator flips the Defender portal "Enable DKIM signing" toggle, the M365 control plane starts signing outbound messages with the new selector public-key BEFORE the operator-side CNAME-delegation TXT record at selector1._domainkey.<tenant- domain> has propagated through the DNS resolver caches; receivers see the s=selector1 tag in the DKIM-Signature header but cannot resolve the public-key TXT record and emit dkim=permerror; the dkim- failures-explained spoke's per-verdict decode reference is the operator-side translation that confirms the per- receiver dkim=permerror-on-just- enabled-M365-tenant aggregate-rate signature matches the CNAME-delegation propagation timing-gap root cause; (ii) Tenant-rename-leaves-stale- CNAME-target as dkim=temperror then dkim=permerror verdict progression — when an operator renames a tenant from <old-tenant>.onmicrosoft.com to <new-tenant>.onmicrosoft.com without updating the per-customer-domain CNAME-delegation TXT records, the per-CNAME resolution path returns SERVFAIL (the stale CNAME target's TXT record never published under the new tenant) producing receiver-side dkim=temperror intermittently and dkim=permerror once the resolver caches the negative response; the dkim-failures-explained spoke documents the per-verdict-class regression diagnosis the operator consumes; (iii) Dual-selector mid-rotation-fallback-misalignment as dkim=fail verdict — Microsoft's per-tenant automatic rotation toggles between selector1 and selector2 on a per-rotation cadence; if the customer-domain CNAME delegation for the inactive selector falls out of sync (e.g. operator updated only selector1 CNAME during the tenant rename above), then when Microsoft rotates to the inactive selector, receivers see DKIM-Signature headers with the new s=selector2 tag pointing to a misaligned CNAME that produces a body-hash-mismatch dkim=fail; the dkim-failures-explained spoke's dkim=fail-body-hash-mismatch decode is the receiver-side diagnosis operators consume to confirm the Microsoft-rotation-during-stale-CNAME regression; (iv) Shared-EOP- egress-IP-pool with cross-tenant signing as dkim=none on legitimate- relay traffic — when an M365 tenant's outbound mail is routed through the shared-EOP egress-IP pool but a legitimate relayed message (e.g. via an on-prem Exchange hybrid configuration, a Microsoft Defender for Office 365 SEG chain, or a Microsoft Power Automate flow) bypasses the tenant's per-tenant DKIM-signing layer, receivers see no DKIM-Signature header at all and emit dkim=none; the dkim- failures-explained spoke documents the per-verdict-class root-cause taxonomy operators consume to distinguish "legit- relay-bypass-of-tenant-signing" dkim=none from "third-party- sender-not-enrolled-in-tenant-signing" dkim=none. Pair this M365- DKIM-deployment guide (the per-tenant deployment-procedure-and-failure-mode- catalogue) with the dkim-failures- explained spoke (the per-verdict receiver-side decode reference) for the complete M365-deployment-AND-DKIM- verdict-failure-mode-diagnosis posture every M365-tenant operator needs to triage the unexpected non- dkim=pass aggregate-report- row patterns that surface on the M365-tenant signing-egress boundary.
• DKIM cryptography basics — the cryptographic primer covering RSA-SHA256 (M365's default algorithm), 2048-bit key sizes, and the public-key verification chain.
• BIMI explained — the PER-M365-TENANT-DKIM-ALIGNED-PASS- AS-UPSTREAM-PRECONDITION-FOR-PER-M365- TENANT-BIMI-RENDERING-AT-OUTLOOK-PLUS- GMAIL companion to this M365-tenant DKIM deployment guide. Where THIS page documents the per-M365-tenant DKIM activation discipline (the Defender Portal Email authentication setting that creates the selector1._domainkey. <M365-author-domain> + selector2._domainkey.<M365- author-domain> CNAME records pointing at the EOP-managed selector1-<author-domain- slug>._domainkey.<onmicrosoft.com- tenant> infrastructure, the per-M365-tenant dual-selector key-rotation infrastructure EOP rotates on the publisher's behalf), the BIMI-explained pillar documents the per-M365-tenant BRAND-TRUST-MONETISATION OUTCOME the per-M365-tenant DKIM-aligned-pass verdict STRUCTURALLY UNLOCKS at the per-receiver consumer-inbox-view: (i) the per-M365- tenant authoritative DNS publishes a default._bimi.<M365-tenant- author-domain> BIMI TXT RR carrying v=BIMI1; + the per-tenant brand-logo SVG-Tiny-PS URL + the per-tenant VMC URL; (ii) Outlook's BIMI-rendering policy (the canonical per-receiver target for M365-tenant outbound mail to M365-recipient inboxes) plus Gmail's BIMI-rendering policy (the canonical cross-tenant per-receiver target for M365-tenant outbound mail to Gmail-recipient inboxes) verify BOTH the per-message DKIM-aligned-pass verdict from THIS page's CNAME-delegated dual- selector signing infrastructure AND the per-M365-tenant DMARC terminal- enforcement state at p=quarantine or p=reject at the moment of per-message rendering — neither precondition alone suffices; (iii) the per-M365-tenant per-day per-author-domain rolling-average of per-message DKIM-pass rate from THIS page's dual-selector CNAME-delegated signing infrastructure directly determines whether the receiver- side BIMI rendering cache renders the brand-indicator at the per-M365-tenant's outbound message receiver-side inbox; and (iv) the per-M365-tenant VMC trademark- bound certificate-chain verification is itself a per-message DOWNSTREAM CONSUMER of the per-message DKIM-d=- tag canonical author-domain identity that THIS page's M365-tenant CNAME-delegated EOP signing infrastructure produces at signing time. Read this WITH the M365- tenant DKIM activation guide when the Phase 6 brand-trust-monetisation question moves to the operator's queue: THIS page documents the per-M365-tenant DKIM CNAME-delegated EOP signing infrastructure, the BIMI-explained pillar documents the per-receiver brand- indicator rendering OUTCOME that M365- tenant signing infrastructure STRUCTURALLY UNLOCKS.
• BIMI Verified Mark Certificates (VMC and CMC) — the M365-TENANT-DKIM-SIGNED-EGRESS- AS-LOAD-BEARING-PRECONDITION-FOR- BIMI-VMC-RENDERING-AT-OUTLOOK-AND- RECEIVER-CONSUMER-INBOX companion to this M365-tenant DKIM deployment reference. Where THIS page documents the M365-tenant DKIM-signing-identity publication infrastructure (the CNAME-delegated selector1._domainkey / selector2._domainkey publication topology resolving via Microsoft-managed selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com / selector2-<tenant>._domainkey.<tenant>.onmicrosoft.com TXT-record-leaf targets, the EOP-managed dual-selector automatic ~6-month rotation cadence, and the Defender portal's "Enable DKIM signing" toggle), the BIMI-VMC/CMC spoke documents the DOWNSTREAM CONSUMER of the M365-tenant DKIM- pass verdict at the receiver-side inbox-rendering layer. Concretely, the spoke documents FOUR M365-tenant-DKIM-signing-as-BIMI- precondition dimensions: (i) M365-tenant BIMI VMC rendering at Outlook-consumer inbox structurally requires DMARC-pass-with-enforcement-policy on the protected tenant domain — per BIMI Working Group BR §2.3 receiver-side rendering prerequisite, BIMI VMC rendering only fires when the receiver observes DMARC alignment-pass on the From:-aligned tenant domain AND the publisher's policy is p=quarantine minimum (Yahoo / Apple Mail) or p=reject (Gmail) — a DKIM-failed message from the M365 tenant CANNOT render BIMI VMC at receiver-side regardless of how well-formed the VMC chain is; (ii) M365-tenant DKIM-pass verdict directly unlocks BIMI VMC rendering at consumer-side inbox — the M365-tenant DKIM-signing infrastructure THIS page documents at the EOP-managed CNAME-delegated dual- selector publication boundary IS THE LOAD-BEARING primitive that produces the DKIM-pass verdict BIMI VMC rendering eligibility requires — every M365 tenant ramping toward BIMI deployment depends on the Defender-portal "Enable DKIM signing" toggle being flipped to ON and the CNAME-delegated selector1 / selector2 records being published on the tenant's custom-domain DNS zone the BIMI VMC chain references at the l= tag value; (iii) M365-tenant BIMI VMC chain validation at receiver- side runs STRUCTURALLY SEPARATELY from the DKIM signature validation but BOTH must succeed for BIMI rendering — the receiver-side verification stack performs (a) DKIM signature validation per RFC 6376 §6 against the CNAME-delegated EOP-managed public-key THIS page documents, then (b) BIMI VMC chain validation per BIMI WG BR §6.3 against the BIMI-WG-approved CA root and trademark-binding-extension — two STRUCTURALLY DISTINCT cryptographic chain validations the M365 tenant coordinates by publishing the DKIM CNAME-delegation chain (THIS page's domain) AND the BIMI record at default._bimi TXT-record on the tenant's custom- domain; and (iv) M365- tenant BIMI VMC procurement coordination with DKIM key rotation — the M365- tenant operator coordinating BIMI VMC procurement (annual CA- issuance-cadence) ALONGSIDE the DKIM key-rotation cadence THIS page documents (EOP-managed ~6- month dual-selector automatic rotation) operates two STRUCTURALLY DISTINCT cryptographic-material-lifecycle cadences AT THE SAME tenant — the BIMI VMC certificate lifecycle is CA-issuance-bound 13-month validity period with annual trademark-re-verification + certificate-re-issuance, while the DKIM key rotation is Microsoft-managed automatic cadence the M365 tenant does NOT directly control; the BIMI certificate procurement workflow the spoke documents is the operator-controlled COMPLEMENT to the platform-managed DKIM key-rotation infrastructure THIS page documents. Read the BIMI-VMC/CMC spoke alongside THIS M365 DKIM deployment guide when the M365 tenant operator is SCALING the tenant's brand- attestation deployment from DKIM-only (per-message-signature identity primitive THIS page documents) to DKIM + BIMI VMC (per-message-signature identity PLUS per-tenant-trademark- attestation rendering primitive the spoke covers) — the spoke documents the downstream BIMI-VMC-rendering consumer of the M365-tenant DKIM-pass verdict that materialises the M365 tenant's brand-attestation rendering outcome at consumer- side inbox.
• BIMI SVG Tiny PS asset-format requirements — the M365-TENANT-DKIM-PASS-AS-BIMI- SVG-ASSET-DISPLAY-PRECONDITION companion to this M365-tenant DKIM deployment reference. Where THIS page documents the M365-tenant DKIM- signing-identity publication infrastructure (the CNAME-delegated selector1._domainkey / selector2._domainkey publication topology, the EOP-managed dual-selector automatic ~6-month rotation cadence, the Defender portal "Enable DKIM signing" toggle), the BIMI-SVG-Tiny-PS-requirements spoke is the BIMI-SVG-ASSET-BYTE-LEVEL- SPECIFICATION companion documenting WHAT the M365-tenant operator must actually publish at the BIMI l=-tag URL once the M365-tenant DKIM-pass verdict THIS page documents meets BIMI's display- eligibility precondition at the receiver-side Outlook rendering boundary. Concretely, the spoke documents FOUR M365-DKIM-signing- as-BIMI-SVG-asset-display-precondition dimensions: (i) BIMI SVG asset publication at default._bimi.<M365-tenant-author-domain> is downstream of the M365-tenant DKIM-pass verdict this page documents — the receiver- side Outlook BIMI-eligibility evaluator only fetches the M365-tenant operator- published SVG asset AFTER the per- message DMARC verdict is pass-with- Friendly-From-header-alignment AND the M365-tenant 90-day rolling DMARC- pass-rate exceeds receiver-internal eligibility thresholds — both gating conditions are themselves consumers of the M365-tenant CNAME-delegated dual- selector DKIM-signing infrastructure THIS page documents (the selector1 / selector2 EOP-managed rotation cadence produces the per- message DKIM-pass verdict that feeds the rolling pass-rate the BIMI- eligibility evaluator gates on); (ii) BIMI SVG-Tiny-PS asset format is the same byte-level contract for M365-tenant publishers regardless of DKIM-signing-identity — the SVG must satisfy baseProfile="tiny-ps", square viewBox with 1:1 aspect ratio, no scripts / animation / external resources, RGB- only color, 32KB ceiling, base64- encoded for inline embedding — the M365-tenant CNAME-delegated dual- selector DKIM-signing infrastructure does NOT influence the SVG format contract, but format failures (PNG instead of SVG, rectangular viewBox, embedded scripts, oversized binary) produce identical BIMI-display-loss outcomes regardless of how cryptographically-correct the M365- tenant DKIM-Signature is; (iii) M365-tenant BIMI deployment is a single asset-publication surface per author-domain regardless of M365- tenant DKIM-key-rotation cadence — the BIMI TXT record at default._bimi.<M365-tenant-author-domain> with v=BIMI1; l=<svg-url>; a=<vmc-url> is published once per author-domain; the M365-tenant operator does NOT re-publish or rotate the BIMI record in tandem with the EOP-managed selector1 ↔ selector2 automatic ~6-month DKIM-rotation cadence — BIMI publication and DKIM rotation are operationally independent publication surfaces with structurally- distinct cadences; and (iv) VMC certificate validity is an additional layered precondition beyond M365-tenant DKIM-pass and SVG-Tiny-PS format conformance — the a=<vmc-url> tag in the M365-tenant BIMI record points to a Verified Mark Certificate (per RFC 9788) issued against the published SVG, and the certificate's logotype extension contains the SVG fingerprint the receiver verifies against the published-at-l=-URL asset — VMC chain validation runs SEPARATELY from M365-tenant DKIM- verification but BOTH cert-validation contracts must succeed for receiver- side Outlook BIMI display, with the M365-tenant operator coordinating VMC procurement (Entrust, DigiCert for VMC; Entrust for CMC) with the operator-managed Friendly-From-domain's author-domain DNS-publication surface independent of the EOP-managed DKIM-signing-key rotation cadence THIS page documents. Read the BIMI-SVG-Tiny-PS-requirements spoke alongside this M365-tenant DKIM deployment reference when the M365- tenant operator advances past terminal p=reject and is ready to deploy BIMI for the M365-tenant author-domain — the M365-tenant DKIM-pass verdict this page documents is the load-bearing gating precondition the BIMI SVG asset publication consumes at receiver-side Outlook rendering.
• MTA-STS for Google Workspace — the M365-EXCHANGE-ONLINE-OUTBOUND- CONNECTOR-DELIVERS-DKIM-SIGNED-MAIL-TO- WORKSPACE-TENANT-MX-AT-aspmx.l.google.com- INVENTORY-AT-WORKSPACE-OPERATOR-PUBLISHED- MTA-STS-ENFORCE-MODE-BOUNDARY-WHOSE- STARTTLS-NEGOTIATION-OUTCOME-IS-CROSS- PROVIDER-ORTHOGONAL-COMPLEMENT-TO-M365- TENANT-DKIM-SIGNING-IDENTITY companion to this M365-tenant DKIM-signing-identity deployment reference. Where THIS page documents the M365-Exchange-Online tenant's outbound DKIM signer mechanics (the selector1._domainkey + selector2._domainkey dual-CNAME publication to selector1-<tenant>.<initial>._domainkey.<tenant>.onmicrosoft.com, the six-month Microsoft-managed automatic key rotation, the Defender-portal Enable toggle, the DKIM-Signature header the outbound message carries at delivery time) — i.e. the M365-TENANT APPLICATION-LAYER DKIM-SIGNING-IDENTITY-AT-MAIL-AUTHOR-TIME side of the cross-provider mail-delivery pipeline — the MTA-STS-for-Google-Workspace spoke is the WORKSPACE-RECEIVER-TENANT TRANSPORT-LAYER STARTTLS-ENFORCEMENT companion documenting the structurally- orthogonal cross-provider delivery boundary an M365-Exchange-Online-outbound message delivered to a Workspace-hosted recipient MUST respect: (i) an M365-tenant outbound mail message DKIM-signed under d=<customer-vanity-domain> at M365-Exchange-Online author-time delivers to a Workspace-hosted recipient's MX at the aspmx.l.google.com / alt1.aspmx.l.google.com / alt2.aspmx.l.google.com / alt3.aspmx.l.google.com / alt4.aspmx.l.google.com tier'd MX inventory the Workspace spoke documents — at that cross-provider delivery boundary, the M365 outbound connector's STARTTLS negotiation respects the Workspace-recipient-tenant's MTA-STS policy (when mode:enforce is published at https://mta-sts. <workspace-domain>/.well-known/ mta-sts.txt); (ii) the M365- tenant DKIM-signing-identity (anchored at d=<customer-vanity-domain> via the dual-CNAME publication this page documents) and the Workspace-recipient- tenant transport-layer STARTTLS-enforcement (anchored at the mta-sts.<workspace-domain> policy publication) are structurally ORTHOGONAL controls — the M365 DKIM-signing posture this page documents does NOT influence whether the Workspace- recipient-tenant's MTA-STS-enforce-mode accepts or rejects the cross-provider STARTTLS handshake, and the Workspace MTA- STS publication does NOT influence whether the M365 DKIM signature survives in-flight to the Workspace recipient mailbox; (iii) operators running mixed M365-sender ↔ Workspace-recipient mail flows (a common cross-tenant business-correspondence pattern) must independently maintain BOTH the M365-tenant DKIM-signing publication (this page) AND understand the Workspace- recipient-tenant's MTA-STS-enforce posture (the spoke) — neither side's publication discipline alone constitutes a complete cross-provider mail-delivery posture; (iv) the Workspace recipient's TLS-RPT JSON aggregate ( emitted by the aspmx.l.google.com-fronted Workspace MX stack to the _smtp._tls.<workspace-domain> TXT-record-published subscriber endpoint) records per-receiver STARTTLS negotiation outcomes for M365-Exchange-Online-outbound mail-streams — an operator reconciling M365-side DKIM-Signature survival evidence (from this page's deployment posture) against Workspace-side TLS-RPT negotiation outcomes (from the Workspace spoke's transport-layer infrastructure) gets a more complete cross-provider mail-delivery picture than either evidence stream alone provides. Read the MTA-STS-for-Google-Workspace spoke alongside this M365 DKIM deployment reference when operating mixed cross- provider mail flows where M365-tenant- signed outbound mail terminates at Workspace-hosted recipient mailboxes — the Workspace-recipient-tenant MTA-STS-enforce publication topology the spoke documents is the load-bearing transport-layer cross- provider delivery boundary that the M365 DKIM-signing-identity this page documents operates ORTHOGONALLY to but cannot replace.
• DKIM for Google Workspace — the sibling provider-deployment spoke covering the same RFC 6376 protocol for Google Workspace tenants. Operators running mixed M365 + Workspace estates (a common large-enterprise pattern) deploy both with markedly different DKIM moving parts. M365 uses a CNAME-delegated dual-selector model (selector1._domainkey / selector2._domainkey → selector1-<tenant>.<initial>._domainkey.<tenant>.onmicrosoft.com) with hands-off Microsoft-driven six-month automatic key rotation; Workspace uses a TXT-published single-selector model (google._domainkey as the canonical selector, with the public key published as a TXT record directly under the domain and rotation managed by the Workspace operator from the Admin Console). The contrast matters because DMARC alignment (d= tag vs From: header) works identically across the two providers but the OPERATOR experience — whether to keep the d=<tenant>.onmicrosoft.com domain-of-record problem or face the Workspace TXT-record size limit at 2048-bit — is fundamentally different. Read this when planning cross-tenant DKIM rollouts, auditing existing DKIM postures, or comparing the two provider-deployment shapes side-by-side.
• DMARC alignment — the alignment engine that consumes DKIM d= tags. The onmicrosoft.com gotcha is fundamentally an alignment failure.
• DMARC for Google Workspace — the sibling per-mailbox-provider deployment guide. Compare the TXT-publication DKIM model (Workspace) with the CNAME-delegation DKIM model (M365) side by side.
• ARC explained — the Authenticated Received Chain protocol that preserves DKIM verdicts across forwarding hops. Pair with M365 Defender for Office 365 Trusted ARC Sealers for inbound flow protection.
• SPF forwarding issues — the per-publisher per-domain SPF second-hop-forwarding DEFECT-CLASS catalogue IS the canonical why-per-M365- tenant-DKIM-publication-discipline-matters upstream-defect-class reference companion to this M365 DKIM CNAME-delegation guide, forming the natural defect → solution pair with the immediately-preceding ARC entry (SPF-forwarding-issues catalogues the defect class, ARC catalogues the trust- chain solution that preserves authentication results across forwarders). Where THIS page documents the per-M365- tenant Defender-portal-driven selector1._domainkey.<tenant-domain> + selector2._domainkey.<tenant-domain> dual-selector CNAME-delegation publication workflow that enables Microsoft-managed DKIM signature emission on M365-egress mail from tenant.mail.protection.outlook.com, the SPF-forwarding-issues spoke documents the per-publisher per-domain second-hop- forwarding defect class that materially gates why the per-M365-tenant DKIM-CNAME- publication-discipline floor THIS page operationalises is load-bearing for per- M365-tenant per-accepted-domain DMARC- aligned-pass-rate floor preservation at FOUR per-M365-tenant-DKIM-CNAME-publication- to-SPF-forwarding-defect-class coupling dimensions: (i) per-M365-tenant second-hop forwarder SPF-aligned-pass collapse as load-bearing DKIM-aligned-pass OR-conjunction safety-net trigger per RFC 7489 §6.6.2 — when M365-egress mail from tenant.mail.protection.outlook.com is forwarded by a downstream forwarder (alias-handler, distribution-list-expander, recipient-side mailbox-rule-forwarder), the downstream forwarder's re-emission from its own IP collapses the per-publisher per- domain SPF-aligned-pass leg because the forwarder's IP is NOT in the per-M365- tenant SPF record's include:spf.protection.outlook.com authorisation set — the per-M365-tenant DKIM-CNAME-publication-discipline floor THIS page operationalises is the OR- conjunction safety-net leg that PRESERVES the per-publisher per-domain DMARC-aligned- pass verdict via the per-M365-tenant Microsoft-managed DKIM signature surviving the forwarder re-emission (DKIM is body- and-header-signed, transport-layer agnostic); (ii) per-M365-tenant per-accepted- domain SRS sender-rewriting scheme vs DKIM- preservation publication-decision coupling — forwarders that implement SRS rewrite the envelope-MAIL- FROM to restore SPF-aligned-pass against the forwarder's own SPF record but the rewritten envelope-MAIL-FROM organisational- domain (e.g., SRS0=hash=ts=originaldomain.com=user@forwarder.example) no longer aligns with the per-publisher per-domain From-header organisational- domain for DMARC-SPF-alignment per RFC 7489 §3.1.1 — the per-M365-tenant DKIM- CNAME-publication-discipline floor THIS page operationalises is the ONLY surviving per-publisher per-domain DMARC-alignment- preservation leg post-SRS-rewriting; (iii) per-M365-tenant per-accepted- domain second-hop-forwarding observability- attribution boundary on per-receiver per- mailbox-provider DMARC aggregate-XML — the per-publisher per-domain forwarder- induced SPF=fail attribution emits per-row row/auth_results/spf/result=fail evidence in per-receiver per-day per- source-IP per-disposition aggregate-XML bins where the per-source-IP attribution is the forwarder's IP NOT the per-M365- tenant spf.protection.outlook.com authorised egress IP-pool — the per-M365- tenant DKIM-CNAME-publication-discipline floor THIS page operationalises is the per-publisher per-domain row/auth_results/dkim/result=pass + policy_evaluated/dkim=pass attribution evidence-stream that preserves the per-publisher per-domain DMARC-aligned- pass-rate floor against the per-receiver per-mailbox-provider per-forwarder per-day SPF-failure-attribution noise floor; (iv) per-M365-tenant per-accepted- domain Phase-2 p=none baseline- observability DKIM-aligned-pass-rate floor enforcement as forwarder-induced-SPF-fail- survival prerequisite for Phase-3 pct=-ramp progression — the per- M365-tenant per-accepted-domain Phase-3 pct=-ramp progression from pct=10 through pct=25 / pct=50 / pct=75 to pct=100 REQUIRES per- publisher per-domain composite-aligned- pass-rate floor preservation against the forwarder-induced-SPF-failure noise floor — the per-M365-tenant DKIM-CNAME- publication-discipline floor THIS page operationalises is the load-bearing per- M365-tenant per-accepted-domain DKIM- aligned-pass-rate floor that survives the forwarder-induced SPF-fail collapse and gates per-tenant per-accepted-domain Phase-3 pct=-ramp progression past the per-receiver per-mailbox-provider per- forwarder-induced false-positive- quarantine cliff into Phase-4 p=quarantine and Phase-5 p=reject enforcement.
• DMARC policy rollout — the PER-M365-TENANT DKIM-DUAL-SELECTOR-CNAME-DELEGATION- PUBLICATION-AS-LOAD-BEARING-PHASE-1- PUBLICATION-BASELINE-PREREQUISITE companion to this M365 DKIM CNAME- delegation guide. Where THIS page documents the per-M365-tenant Defender portal → Email & Collaboration → Policies & rules → Threat policies → DKIM → Rotate-DKIM-keys / Enable-signatures workflow that flips the tenant from unsigned to DKIM-signed egress under the selector1._domainkey.<tenant-domain> + selector2._domainkey.<tenant-domain> dual-selector CNAME-delegation pair pointing to selector1-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com / selector2-<domain-with-dashes>._domainkey.<tenant>.onmicrosoft.com, the DMARC-policy-rollout spoke documents the per-M365-tenant five- phase rollout workflow whose every per- pct=-ramp-stage advancement and per- phase cutover gate depends on this M365-tenant DKIM-CNAME-publication floor at FOUR per-M365-tenant-DKIM- CNAME-publication-to-DMARC-policy- rollout coupling dimensions: (i) Phase-1 per-M365-tenant DKIM- CNAME-delegation publication-baseline as load-bearing receiver-side dkim=pass- verdict-availability prerequisite for the per-M365-tenant rollout to launch — the Phase-1 publication-baseline floor REQUIRES the per-M365-tenant dual-selector CNAME-delegation pair to have been published at the operator's DNS provider AND DNS-propagated AND the Defender portal "Enable signatures for this domain" toggle to have been flipped to ON for the receiver-side dkim=pass verdict to be emitted in the FIRST place against M365- egress mail from tenant.mail.protection.outlook.com; any per-M365-tenant DKIM-CNAME-publication defect (CNAME-typo, only-one-selector- published, Defender-portal-toggle-off, Microsoft-side-key-rotation-not-yet- published-to-onmicrosoft.com-target) collapses Phase-1 to dkim=fail via the default attribution to d=<tenant>.onmicrosoft.com (which breaks DKIM-alignment because the From-header organizational-domain is not onmicrosoft.com) and blocks the M365 tenant from launching the per-tenant policy rollout; (ii) Phase-2 p=none baseline- observability per-M365-tenant DKIM- aligned-pass-rate-floor enforcement as Threat-Explorer-driven M365-egress aggregate-XML row/auth_results/dkim/result=pass row-count input — the Phase-2 observability baseline REQUIRES the per- M365-tenant dual-selector CNAME- delegation discipline floor to be in place across every per-tenant per- accepted-domain deployment before advancing into Phase-3 — the per- source-IP per-receiver per-day rua aggregate-XML row/policy_evaluated/dkim=pass row-count distribution (alongside the M365-tenant Defender for Office 365 Threat Explorer per-receiver-cohort DKIM-aligned-pass-rate dashboard) is the gate-keeping observability surface that confirms the M365-tenant CNAME- delegation is reliably translating into receiver-side dkim=pass verdicts at the per-M365-tenant per-accepted- domain floor required for Phase-3 advancement; (iii) Phase-3 per- M365-tenant pct=-ramp per-stage advancement gate-keeping DKIM-aligned- pass-rate-floor enforcement as per- ramp-stage-cutover-confidence input — every Phase-3 per-stage advancement (pct=10 → pct=25 → pct=50 → pct=75 → pct=100) REQUIRES the per-M365-tenant DKIM-aligned-pass- rate floor to remain stable across the per-tenant per-accepted-domain deployment; any per-stage DKIM-aligned- pass-rate regression caused by a per- M365-tenant DKIM-CNAME-delegation discipline drift (Microsoft-initiated key-rotation-cutover-during-pct=-ramp without operator selector1/selector2 CNAME flip, new-accepted-domain- onboarded-without-Enable-signatures- toggle, default-tenant-onmicrosoft.com- d=-tag-attribution-DKIM-alignment- failure-mode) must be remediated BEFORE advancing the per-stage cutover; (iv) Phase-4-p=quarantine and Phase-5-p=reject per-M365-tenant cutover-confidence floor as M365-egress per-receiver per-source-IP DKIM-aligned- pass-rate-coverage-completeness prerequisite — the terminal- state Phase-4-p=quarantine and Phase-5- p=reject cutovers REQUIRE the per-M365- tenant DKIM-CNAME-delegation floor to be in place across every per-tenant per-accepted-domain per-receiver M365- egress deployment with zero outstanding M365-DKIM-CNAME-delegation discipline defects — the terminal-state cutover is the point where any remaining M365 DKIM-CNAME-delegation drift translates directly into M365-egress legitimate- mail-bounce-rate uplift, so the per- receiver per-source-IP M365-egress DKIM-aligned-pass-rate-coverage- completeness floor must be empirically confirmed via the rua aggregate-XML stream AND the M365 Defender Threat Explorer per-receiver dashboard BEFORE the terminal-state cutover. Read the DMARC-policy-rollout spoke alongside THIS page when the M365-tenant operator asks "how does the per-M365-tenant Defender portal DKIM CNAME-delegation workflow translate into the per-tenant five-phase DMARC-policy-rollout cadence" — the answer is FOUR-LAYERED: THIS page documents the per-M365- tenant Defender portal DKIM CNAME- delegation workflow, the DMARC-policy- rollout spoke documents the per-M365- tenant five-phase deployment workflow whose every per-pct=-ramp-stage advancement and per-phase cutover gate consumes the M365-egress DKIM-aligned- pass-rate floor THIS page's selector1 / selector2 CNAME-delegation pair underpins.
• SPF for Google Workspace — the CROSS-CLOUD-PROVIDER-PER-CLOUD- TENANT-AUTHENTICATION-PUBLICATION- TOPOLOGY-PARALLEL companion to this per- M365-tenant DKIM deployment reference. Where THIS page documents the per-M365- tenant selector1._domainkey.<domain> + selector2._domainkey.<domain> DKIM-dual-selector-CNAME-delegation publication topology (the Defender portal "Enable DKIM signing" toggle workflow, the per-tenant Microsoft- managed public-key bytes Microsoft publishes at the selectorN-<tenant>._domainkey.<onmicrosoft-tenant> CNAME targets, the per-tenant rolling- dual-selector rotation cadence Microsoft operates, the per-tenant EOP- signing-egress invariant the Defender toggle controls), the spf_for_google_ workspace spoke documents the structurally-parallel per-Workspace- tenant SPF-include-cascade publication topology at FOUR cross-cloud-provider per-cloud-tenant authentication- publication dimensions: (i) per- Workspace-tenant include:_spf.google.com SPF-include-cascade publication topology AS STRUCTURAL-PARALLEL TO per- M365-tenant selector1._domainkey.<domain> + selector2._domainkey.<domain> DKIM-dual-selector-CNAME-delegation publication topology — both are per-cloud-tenant per-DNS-record publication primitives where the cloud- provider operates the canonical egress- authorization infrastructure and the per-tenant operator publishes a delegated DNS-record at a fixed- convention per-tenant DNS-namespace (per-Workspace-tenant include:_spf.google.com cascade publishing Google's outbound IP prefixes vs per-M365-tenant selector1 / selector2 CNAME-delegation targets publishing Microsoft's EOP- managed DKIM public-key bytes); the spf_ for_google_workspace spoke documents the Workspace-side per-tenant SPF- publication topology whose publication- discipline operators familiar with M365- side DKIM-CNAME-delegation publication topology can transfer directly to; (ii) per-Workspace-tenant include:_spf.google.com cascade RFC 7208 §4.6.4 ten-DNS-lookup ceiling consumption AS STRUCTURAL- PARALLEL TO per-M365-tenant dual- selector CNAME-chain resolution consumption — Workspace's per- tenant include:_spf.google.com cascade itself consumes 3-5 of the ten- DNS-lookup ceiling budget structurally paralleling how M365's per-tenant dual-selector CNAME-chain resolution consumes per-zone CNAME-record budget; the spf_for_google_workspace spoke documents the per-Workspace-tenant publication-budget discipline whose preservation parallels the per-M365- tenant publication-budget discipline THIS page documents at the cross-cloud- provider per-tenant publication-budget- discipline boundary; (iii) per- Workspace-tenant SPF-include-cascade ALIGNMENT WITH per-publisher DMARC aspf=relaxed / aspf=strict alignment- mode publication AS APPLICATION-LAYER DMARC-ALIGNMENT-COMMITMENT-PARALLEL TO per-M365-tenant DKIM-d-tag alignment with per-publisher DMARC adkim=relaxed / adkim=strict alignment- mode publication THIS page's DKIM- deployment depends on at receiver-side DMARC-alignment evaluation time — both per-cloud-tenant authentication- publication topologies must coordinate with the per-publisher DMARC alignment- mode publication; the spf_for_google_ workspace spoke documents the per- Workspace-tenant SPF-alignment-mode coordination whose structural parallel to the per-M365-tenant DKIM-alignment- mode coordination operators master for one cloud-provider transfers directly to the other; (iv) per- Workspace-tenant SPF-include-cascade per-source-IP authorization-failure- evidence emitted in per-M365-tenant DMARC-rua aggregate-reports AS STRUCTURAL-PARALLEL TO per-M365-tenant DKIM-aligned-pass-rate evidence emitted in per-Workspace-tenant DMARC- rua aggregate-reports — when Workspace-tenant-authored mail is delivered to M365-tenant recipient domains, the cross-cloud-provider rua- aggregate-report-emitter records per- source-IP-per-disposition rows attributing both the per-Workspace- tenant SPF-aligned-pass verdict AND the per-M365-tenant DKIM-aligned-pass verdict; the spf_for_google_workspace spoke documents the per-Workspace- tenant SPF-aggregate-evidence emission discipline whose structural parallel to the per-M365-tenant DKIM-aggregate- evidence emission discipline THIS page documents is the canonical cross- cloud-provider per-tenant authentication-observability-feedback- loop pattern. Read the spf_for_google_ workspace spoke alongside this M365 DKIM deployment reference whenever the cross-cloud-provider operator scopes a per-cloud-tenant-authentication- publication coordination plan — the per-Workspace-tenant SPF-include- cascade publication topology the spoke catalogues IS the cross-cloud-provider sibling-pattern to the per-M365-tenant DKIM-CNAME-delegation publication topology THIS page operationalises at the cross-cloud-provider per-cloud- tenant authentication-publication- topology boundary.
• Microsoft 365 Defender portal — the operator entry point for DKIM management.
• Microsoft Learn: Use DKIM to validate outbound email — the canonical primary-source Microsoft documentation for the CNAME-based DKIM configuration on Exchange Online.
• Email Header Analyzer — paste any email's headers and see SPF, DKIM, DMARC, and ARC results.
• Domain Security Checker — live DNS lookups for every email- authentication record on a domain. Surfaces the published selector1 / selector2 CNAMEs and the tenant target.
• DNS Record Generator — SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• DMARC monitoring — the PER-M365-TENANT-PER-CUSTOM-DOMAIN- DKIM-AS-LOAD-BEARING-UPSTREAM-AUTH-RESULTS- D-EQUALS-S-EQUALS-PRIMITIVE companion to this M365 DKIM deployment reference. Where THIS page documents the per-M365- tenant per-custom-domain DKIM signing- activation workflow (Exchange Admin Center DKIM-Enable toggle, dual selector1._domainkey.<d> / selector2._domainkey.<d> CNAME publication pointing at the per- tenant selector*-<tenantId> ._domainkey.<onmicrosoft-tenant> provider-managed public-key TXT-RR, 2048-bit modulus, per-tenant rotation operational discipline), the DMARC- monitoring spoke documents the per- publisher per-domain KPI-dashboard whose per-day per-receiver per-source-IP DKIM-aligned-pass-rate KPI is DIRECTLY FED by the per-message dkim=pass d=<custom-domain> s=selector1|selector2 verdicts this M365 DKIM activation produces at every outbound message. The M365-DKIM- ACTIVATION-VS-DMARC-MONITORING-KPI- DASHBOARD cross-reference establishes FOUR coupling dimensions: (i) per- M365-tenant per-custom-domain DKIM-Enable toggle as upstream gate of the per- publisher per-domain DKIM-aligned-pass- rate KPI — when an M365 tenant operator flips the DKIM-Enable toggle from off → on at the Exchange Admin Center for a custom domain this page documents, the next 24-hour aggregate- report window the monitoring spoke ingests shows the per-publisher per- domain DKIM-aligned-pass-rate KPI step- function jump from zero (rua= aggregate-XML rows with empty DKIM result-set or dkim=none per-source-IP cohort) to per-receiver per-source-IP aligned-pass coverage proportional to the per-tenant outbound- message-volume share routing through Microsoft 365's signing infrastructure; the monitoring spoke documents this DKIM-Enable-toggle as the canonical signal of upstream per-tenant DKIM- activation completion; (ii) per- M365-tenant selector1/selector2 rotation cadence as upstream determinant of per- source-IP DKIM-aligned-pass-rate continuity in the per-day KPI trajectory — the per-tenant Microsoft-managed selector1 ↔ selector2 rotation cadence this page documents (per-tenant key- rotation events surfacing as s=selector1 → s=selector2 verdict- switching at the per-receiver per-day- bucket boundary) is the upstream signing- layer event that determines whether the monitoring spoke's per-day per-source-IP DKIM-aligned-pass-rate KPI shows a smooth per-rotation overlap window or a per-rotation pass-rate cliff if the new-selector CNAME has not yet propagated to the per-receiver-side validator at the time of the rotation; (iii) per- M365-tenant per-custom-domain DKIM- Signature d= field as load-bearing DMARC- alignment-determinant primitive feeding the monitoring KPI dashboard's per-day per-receiver per-source-IP DKIM-aligned- pass attribution-key set — every per-message DKIM-Signature this M365 deployment emits carries d=<custom-domain> matching the publisher's RFC5322-From domain at organizational-domain alignment scope; this d=-to-From-domain alignment evaluation at the per-receiver-side DMARC evaluator is the load-bearing per-message verdict the monitoring spoke's per-day per-source-IP DKIM-aligned-pass-rate KPI cohort aggregates per-receiver per-source- IP per-day-bucket cohort row; (iv) per-M365-tenant DKIM-failure-mode catalogue as upstream determinant of the monitoring KPI dashboard's per-source-IP DKIM-fail-rate alert thresholds — the per-tenant per-custom-domain DKIM- failure-mode catalogue this page documents (CNAME mis-publication, post-rotation CNAME-not-yet-propagated, EAC DKIM-Enable toggle off, mailbox-rule body-rewrite breaking b= signature integrity, per- tenant per-third-party-sender DKIM-not- configured fallback) is the upstream signing-layer regression catalogue whose per-source-IP per-day-bucket DKIM-fail appearance drives the monitoring spoke's per-source-IP DKIM-fail-rate alert- threshold triggers and per-receiver per-tenant-attributable regression triage. Read the DMARC-monitoring spoke alongside this M365-tenant DKIM- activation reference when operating per-M365-tenant per-custom-domain DKIM signing visibility through the per- publisher per-domain aggregate-report KPI dashboard.
• Reverse DNS (PTR records) explained — the PER-M365-TENANT-OUTBOUND-IP-POOL- PTR-RDNS-AS-DKIM-SIGNED-MAIL-DELIVERABILITY companion to this M365-tenant DKIM activation reference. Where THIS page documents the per-M365-tenant per-custom-domain DKIM CNAME-delegation publication workflow (selector1._domainkey / selector2._domainkey at the custom-domain DNS zone, the Set-DkimSigningConfig activation, the Defender portal DKIM enable toggle), the reverse-DNS-PTR spoke is the EOP-OUTBOUND-IP-POOL-PTR-RDNS-PRECONDITION REFERENCE every M365-tenant operator consults when investigating per-tenant deliverability outcomes that correlate with upstream Exchange Online egress IP-pool PTR-record continuity. Three structurally- distinct M365-DKIM-vs-PTR coordination dimensions: (i) Exchange Online's per-region EOP outbound IP pool publishes per-IP PTR records pointing to mail-<region>.<subdomain>.outbound.protection.outlook.com hostnames whose forward-confirmed reverse DNS resolution at the per-receiver inbound MX gates per-tenant deliverability ACCEPTANCE before the per-message DKIM evaluator runs — a receiver rejecting per-PTR-absent or per-PTR-mismatched connections at SMTP 550 produces zero per-message DKIM-verification evidence; (ii) per-M365-tenant DKIM-signed mail's deliverability KPI gap-analysis requires the M365 operator to coordinate the per-tenant DKIM-signature publication discipline this page documents WITH the upstream EOP-managed per-IP-pool PTR-record publication discipline (the M365 operator doesn't directly control EOP outbound IP PTR records but consumes Microsoft's per-IP-pool PTR publication SLA, which the M365 operator's deliverability team must monitor); (iii) per-M365-tenant hybrid Exchange topologies that egress from on-prem Edge transport (the M365 operator DOES control on-prem PTR records) produce per-message per-receiver deliverability outcomes that interact with the dual-signer DKIM model — the per-PTR- misconfigured on-prem egress IP can cause per-receiver rejection of mail bearing the on-prem DKIM-Signature header BEFORE the receiver's DKIM evaluator can verify either the on-prem or cloud signature.
• RFC 6376 — DKIM Signatures
• RFC 8301 — Cryptographic Algorithm and Key Usage Update to DKIM — the key-size requirements: at least 1024 bits, 2048 recommended.
• DNS propagation timing — the PER-M365-TENANT-DUAL-SELECTOR-CNAME- DELEGATION-DNS-PROPAGATION-AS-LOAD-BEARING- UPSTREAM-INFRASTRUCTURE-LAYER-PRECONDITION- FOR-PER-TENANT-DKIM-ROTATION-CADENCE companion reference. Where THIS page documents the per-M365-tenant dual-selector DKIM publication discipline (the per-customer-domain selector1._domainkey.<customer- domain> / selector2. _domainkey.<customer-domain> CNAME records the tenant operator publishes at the customer-domain master zone pointing to the Microsoft-managed selector1-<customer-domain-with- dashes>._domainkey. <initial-domain>.onmicrosoft.com target, the Defender-Rotate-DkimSigningConfig per-quarter Microsoft-managed key-rotation cadence selector-flip-at-DKIM-management- blade, the per-tenant DKIM-management-blade Enable-DkimSigningConfig + Rotate- DkimSigningConfig workflow), the DNS- propagation spoke documents the per-customer- domain master-zone CNAME-delegation publication's DNS-zone-authoritative-server- to-receiver-side-recursive-resolver propagation-completion timing whose per- receiver-resolver-cache TTL-bounded completion gates whether per-M365-tenant DKIM verification succeeds at the receiver side, across four per-M365-tenant-dual- selector-CNAME-delegation-publication-to- per-message-verification-coupling dimensions: (i) per-M365-tenant-CNAME- delegation-chain-propagation-as-upstream- precondition-for-per-message-verification — the per-message DKIM verifier at receiver side resolves the per-tenant selector1._domainkey.<customer- domain> CNAME to the Microsoft- managed selector1-<customer-domain- dashes>._domainkey. <initial-domain>.onmicrosoft.com target THEN resolves that target's TXT record to retrieve the Microsoft-managed per-tenant public key bytes the per-message b= tag must verify against; receiver-side resolver-cache propagation- incompleteness during the per-tenant Enable-DkimSigningConfig onboarding window produces per-message dkim=temperror / dkim=permerror verdicts at receivers whose recursive resolvers have not yet propagated the customer-domain master- zone CNAME chain; (ii) per-tenant- TTL-budget-as-receiver-cache-staleness- window-during-Defender-rotation — the per-customer-domain master-zone CNAME record's TTL value (typically 3600s at the operator's DNS provider) directly bounds the per-receiver-resolver-cache staleness window during which an in-flight Defender-Rotate- DkimSigningConfig per-quarter rotation produces per-message dkim=permerror verdicts at receivers whose recursive- resolver cache still holds the prior Microsoft-managed CNAME-target zone-content that no longer matches the per-message DKIM-Signature header's d= + s= tag pair post-rotation; (iii) per-M365-tenant-pre-Enable- DkimSigningConfig-CNAME-pre-publication- window-discipline — M365 tenant operators publishing the per-customer-domain master-zone CNAME pair BEFORE invoking Enable-DkimSigningConfig at the per-tenant DKIM-management-blade MUST WAIT for the per-receiver-resolver-cache propagation- completion window (one TTL cycle at minimum, ideally three for worldwide cache convergence) BEFORE flipping the per-tenant Enable-DkimSigningConfig switch to start emitting per-message DKIM-Signature headers with the per-customer-domain d=<customer-domain>; s=selector1 tag pair, ensuring receiver-side per-message verification reliably resolves the per-customer-domain master-zone CNAME chain to the matching Microsoft-managed per-tenant public-key TXT record; (iv) per-tenant-customer- domain-onboarding-CNAME-propagation-as- load-bearing-input-to-Defender-rotation- cadence-effective-window — the Defender-Rotate-DkimSigningConfig per- quarter rotation cadence's selector-flip- at-DKIM-management-blade only takes operational effect at receiver-side per- message DKIM verification after the per- customer-domain master-zone CNAME chain has fully propagated to ALL receiver-side recursive resolvers worldwide; M365 tenant operators sequencing per-quarter rotation flips MUST account for the per-receiver- resolver-cache TTL-bounded propagation- completion window WITHIN the per-quarter rotation cadence to ensure per-message DKIM verification at receivers reflects the post-rotation Microsoft-managed per-tenant public-key bytes. Read this WITH the per- M365-tenant DKIM-management-blade workflow reference when the per-tenant Enable- DkimSigningConfig onboarding sequence or Defender-Rotate-DkimSigningConfig per- quarter rotation cadence reaches the operator's queue: THIS page documents the per-tenant dual-selector CNAME-delegation publication discipline + per-quarter rotation cadence, the DNS-propagation spoke documents the INFRASTRUCTURE-LAYER propagation-timing discipline whose per- receiver-resolver-cache TTL-bounded completion gates whether the per-tenant DKIM publication / rotation cadence can take effect at receiver-side per-message DKIM verification.
• TLS-RPT report format — the per-M365-tenant RFC 8460 TLS-RPT JSON-aggregate report as peer transport- layer cross-tenancy observability primitive companion to this per-tenant DKIM-publication- discipline reference. Where THIS page documents the per-tenant dual-selector CNAME-delegation publication discipline + Microsoft-managed key + per-quarter rotation cadence as the application-layer authentication- publication-discipline, the TLS-RPT-report- format spoke documents the RFC 8460 JSON- aggregate report schema that is the LOAD- BEARING transport-layer observability primitive the operator MUST co-ingest alongside the application-layer DKIM-aligned-pass RUA evidence. Four PER-M365-TENANT-VS-TLS-RPT- JSON-AGGREGATE-REPORT cross-correlation axes the TLS-RPT-report-format spoke documents: (i) the per-M365-tenant outbound DKIM-signed mail traversing per-receiver- side STARTTLS upgrade is captured in the receiver-side RFC 8460 JSON-aggregate as per-publisher per-receiver per-day summary.total-successful-session-count + per-failure failure-details rows — the per-tenant DKIM-aligned-pass RUA evidence is INCOMPLETE without the per-publisher per-day TLS-RPT JSON-aggregate confirming the transport-layer envelope- encryption preconditions that protect the DKIM-signed message body from in-flight body mutation; (ii) the per-M365-tenant inbound MTA-STS policy publication (the _mta-sts.<tenant>.onmicrosoft.com + *.mail.protection.outlook.com canonical MX hostname glob) emits per- sender per-day TLS-RPT JSON-aggregate rows the receiving M365-tenant operator reads for cross-tenancy transport-layer-failure attribution between M365-side / sender-side / in-flight TLS-stripping root causes; (iii) the per-M365-tenant DKIM- replay-attack mitigation discipline STRUCTURALLY DEPENDS on transport-layer envelope-encryption preconditions surfaced in the per-day TLS-RPT JSON-aggregate — DKIM-signed messages that traverse downgraded transport-layer sessions surface as failure-details.result-type=starttls-not-supported or certificate-host-mismatch rows in the per-day JSON-aggregate, and the per-tenant DKIM-replay-mitigation discipline MUST cross-correlate these transport-layer downgrade rows with the application-layer DKIM-replay-attack attribution evidence; (iv) the per-M365-tenant cross-protocol-pillar authentication-and-encryption-posture investigation discipline requires the per- publisher per-day TLS-RPT JSON-aggregate co-ingested with the per-publisher per-day DMARC RUA aggregate — the JSON-aggregate's per-failure failure-details rows attribute transport-layer failures per-source-MTA-IP + per-receiving-MX-hostname while the RUA aggregate's policy_evaluated rows attribute application-layer authentication verdicts per-source-IP — together they form the complete per-tenant cross-protocol-pillar observability stream. Read THIS page when CONFIGURING the per-tenant DKIM publication discipline; read the TLS-RPT- report-format spoke when DECODING the per- day RFC 8460 JSON-aggregate that completes the per-tenant cross-protocol-pillar authentication-and-encryption-posture observability stream alongside the per- tenant DKIM-aligned-pass RUA evidence stream.
• Business Email Compromise (BEC) — the per-attacker per-target-domain BEC-ATTACK-THREAT-MODEL companion to this per-M365-tenant per-custom- domain DKIM publication tutorial. Where THIS page documents the per- M365-tenant per-custom-domain DKIM publication discipline (the Exchange Online / Microsoft 365 Defender admin-center DKIM enablement flow, the selector1._domainkey / selector2._domainkey per-tenant CNAME publication, the 2048-bit per-tenant DKIM key-rotation cadence), the BEC spoke documents the per-attacker per-target-domain BEC attack-vector catalogue (CEO- impersonation wire-transfer-fraud, vendor-impersonation invoice-redirect, payroll-redirect attacks) whose per-M365-tenant per-custom-domain DETERRENCE the per-tenant DKIM- aligned-pass publication directly SUPPORTS as the per-publisher per- message cryptographic-authentication- evidence stream that DRIVES the per- receiver per-domain DMARC p=reject enforcement verdict-distribution closing the BEC- attacker per-target-domain impersonation attack-surface. Read the BEC spoke when MOTIVATING the per-M365-tenant per-custom-domain DKIM publication-discipline investment as a load-bearing per- target-domain BEC-deterrence cryptographic-authentication control.
• Phishing protection — the PER-M365-TENANT-PER-CUSTOM- DOMAIN-DKIM-PUBLICATION-AS-LOAD-BEARING- ANTI-PHISHING-PRIMITIVE companion reference. Where THIS page documents the per-M365-tenant per-custom-domain DKIM publication discipline (the Exchange Online / Microsoft 365 Defender admin-center DKIM enablement flow, per-tenant selector1._domainkey / selector2._domainkey CNAME publication, per-tenant 2048-bit per-custom-domain DKIM key-rotation cadence), the phishing-protection spoke is the PER-PUBLISHER-PER-DOMAIN- PHISHING-ATTACK-THREAT-MODEL companion whose per-M365-tenant per-custom- domain anti-phishing posture the DKIM- publication discipline directly supports. Four M365-tenant per-custom- domain anti-phishing coupling dimensions the spoke addresses: (1) per-publisher per-domain display-name spoofing deterrence — attackers forge the RFC 5322 From: display-name to read "CEO <attacker@evil.tld>" impersonating the per-M365-tenant executive — the per-M365-tenant per- custom-domain DKIM-aligned-pass evidence at the receiver-side cryptographically distinguishes legitimate per-custom-domain mail from attacker-controlled lookalike-domain mail in the receiver-side per-message Authentication-Results header, enabling per-receiver per-day display-name- spoofing-attack-campaign detection signals; (2) per-publisher per-domain lookalike-domain registration deterrence — attackers register contos0.com (zero in place of "o"), contoso.co (truncated TLD), or microsoft.support (vanity TLD) imitating the per-M365-tenant custom domain — the per-M365-tenant per-custom-domain DKIM-aligned-pass publication discipline produces the per-publisher per-domain cryptographic-authentication primitive the per-receiver per-domain lookalike- domain-attack-campaign empirical- detection pipeline consumes to flag per-receiver per-day lookalike-domain per-message anomalies; (3) per- publisher per-domain IDN-homograph deterrence via UTS #39 confusables — attackers register contoso.com homographs using mixed-script Unicode confusables (Cyrillic "о" U+043E replacing Latin "o" U+006F) — the per- M365-tenant per-custom-domain DKIM- aligned-pass evidence allows per- receiver per-domain confusable-mapping empirical-detection pipelines to cryptographically distinguish legitimate per-custom-domain mail from confusable-spoofed attacker mail; (4) per-publisher per-domain per-source-IP per-day DMARC-aligned- fail-rate spike as empirical-detection signal — the per-M365-tenant per- custom-domain DMARC RUA aggregate- report stream surfaces per-receiver per-day per-source-IP per-publisher per-day DMARC-aligned-fail-rate spikes as the literal empirical-detection signal for active per-publisher per- custom-domain spoofing-attack- campaigns; the per-message RUF ARF diagnostic-block stream from per- domain ruf= publication enables per-attack-campaign forensic-evidence- collection for SOC incident-response. Read the phishing-protection spoke when MOTIVATING the per-M365-tenant per-custom-domain DKIM publication discipline as the load-bearing per- publisher per-domain cryptographic anti-phishing primitive whose receiver-side enforcement closes the per-publisher per-domain phishing- attack-campaign attack surface.
• DMARC multi-domain strategy — the PER-M365-TENANT-PER-VERIFIED-CUSTOM- DOMAIN-DKIM-PUBLICATION-COORDINATION companion to this per-tenant per-custom- domain DKIM enablement procedure. Where THIS page documents the per-M365-tenant per-custom-domain DKIM enablement discipline (the Exchange Online / Microsoft 365 Defender admin-center DKIM enablement flow, the per-tenant selector1._domainkey + selector2._domainkey CNAME publication, the per-tenant 2048-bit per-custom-domain DKIM key-rotation cadence), the multi-domain-strategy spoke documents the FOUR PER-M365-TENANT-PER- VERIFIED-CUSTOM-DOMAIN COORDINATION DIMENSIONS the operator MUST close when the per-tenant M365 instance hosts MULTIPLE verified custom domains added via Microsoft 365 admin center "Add domain" workflow (the parent corporate domain + per-product brand domains + per-subsidiary domains acquired through per-tenant M&A activity): (i) per-verified-custom- domain INDEPENDENT DKIM enablement — every verified custom domain under a single M365 tenant requires its OWN Exchange Online / Microsoft 365 Defender admin-center DKIM-enablement invocation producing per-domain selector1-<tenant>._domainkey.<domain> + selector2-<tenant>._domainkey.<domain> CNAME records published at THAT domain's customer-managed DNS zone; the per-tenant DKIM-enablement toggle is a per-custom- domain control, not a per-tenant blanket enablement; (ii) per-verified- custom-domain INDEPENDENT DMARC p=reject enforcement cadence — every verified M365 custom domain MUST publish its OWN _dmarc.<domain> aggregate record on an INDEPENDENT per-domain p=none → p=quarantine → p=reject rollout cadence so a per-domain Exchange- Online-side DKIM-enablement regression does NOT collapse the per-tenant portfolio- wide per-receiver per-day enforcement verdict distribution; (iii) per- verified-custom-domain INDEPENDENT rua= mailbox ingestion under a single per-tenant operator dashboard — every per-custom-domain rua= publication MUST funnel its receiver-side DMARC aggregate-report stream into a SINGLE per-tenant M365-operator dashboard so the per-tenant per-portfolio-domain DKIM- aligned-pass verdict surface is available to the per-tenant authentication-operator at one ingestion point — letting the operator attribute a per-receiver per-day per-custom-domain DKIM-aligned-pass-rate regression to the SPECIFIC verified custom domain whose Exchange Online DKIM- enablement toggle regressed; (iv) per-acquired-subsidiary-custom- domain admin-center verification + DKIM enablement ONBOARDING SEQUENCE — newly-acquired subsidiary custom domains added via per-tenant M&A activity require the standard Microsoft 365 admin- center "Add domain" TXT-record verification ceremony FOLLOWED BY a per-domain Exchange- Online DKIM-enablement toggle invocation FOLLOWED BY a per-domain DMARC p=quarantine → p=reject rollout cadence — the multi-domain- strategy spoke documents the canonical onboarding sequence that prevents the per-acquired-subsidiary-custom-domain becoming a per-tenant M365-portfolio authentication-coverage gap exploitable by a per-attacker subsidiary-domain BEC spoofing variant. Read the multi-domain- strategy spoke ALONGSIDE this per-tenant per-custom-domain Exchange Online DKIM enablement procedure when operating a per-M365-tenant MULTI-VERIFIED-CUSTOM- DOMAIN portfolio — the per-portfolio-per- custom-domain coordination catalogue is the canonical operator-facing companion every multi-custom-domain M365 tenant MUST execute to preserve the per-tenant per- portfolio DKIM-aligned-pass coverage assumption at the receiver-DMARC-engine alignment-check boundary.
• Email deliverability fundamentals — the per-publisher per-domain inbox- placement-rate-as-business-outcome primitive whose four per-M365-tenant per- custom-domain DKIM-publication-discipline- as-deliverability-input coupling dimensions THIS M365 DKIM publication-discipline reference materially feeds: (i) per- M365-tenant per-custom-domain DKIM-aligned- pass-rate-floor as load-bearing upstream input to per-receiver per-mailbox-provider per-sender-reputation-scoring (Outlook.com / Gmail / Yahoo Mail / Apple iCloud / ProtonMail / Yandex / mail.ru / 163.com) inbox-vs-Spam-folder placement decision each receiver's spam-filter applies to per- M365-tenant per-custom-domain outbound mail — per-tenant per-custom- domain DKIM-signing posture floor IS the deliverability-floor input; (ii) per- M365-tenant per-custom-domain DKIM publication-completeness (per-tenant Authenticate-email wizard engaged + per- custom-domain CNAME chain published + per- custom-domain DKIM-record-and-selector propagated) STRUCTURALLY GATES the per- receiver per-mailbox-provider per-sender positive-reputation-acquisition floor each per-receiver's per-sender-reputation scoring algorithm requires — per-tenant publication-completeness IS the per-receiver reputation-warmup-acceleration primitive; (iii) per-M365-tenant per-custom-domain DKIM-aligned-pass-rate regression (per-tenant Authenticate-email wizard disengaged via tenant-admin error + per-tenant CNAME-chain breakage + per- tenant DKIM-record TTL-window-bounded propagation-tail) SURFACES as per-receiver per-mailbox-provider per-sender-reputation regression THIS M365 DKIM publication- discipline reference's per-tenant operational-discipline runbook MUST detect before per-receiver inbox-placement-rate falls below the per-publisher per-domain business-outcome floor — per-tenant DKIM regression IS deliverability regression at the per-receiver consumption boundary; (iv) per-M365-tenant per- custom-domain DKIM-aligned-pass evidence as the per-receiver per-mailbox-provider per- sender Sender-Score / SNDS-dashboard / Postmaster-Tools-feedback positive- reputation-attribution input the per- publisher per-domain analytics team's per-receiver per-mailbox-provider per-day reputation-monitoring runbook materially consumes — the per-tenant per- custom-domain DKIM publication evidence loop closes through per-receiver per- mailbox-provider reputation-feedback channels back into the per-publisher per- domain operator's discipline floor validation. Read the email-deliverability fundamentals spoke alongside this M365 DKIM publication-discipline reference when positioning per-M365-tenant per-custom- domain DKIM publication-discipline within the broader per-tenant per-custom-domain deliverability operator-discipline floor, when authoring per-tenant per-custom- domain DKIM-publication-regression incident-response runbooks whose deliverability- impact-quantification protocol consumes per-receiver per-mailbox-provider per-day inbox-placement-rate evidence, or when coordinating per-M365-tenant per-custom- domain DKIM publication-discipline against per-receiver per-mailbox-provider per- sender-reputation-scoring-feedback channels the per-publisher per-domain operator's deliverability operator-discipline floor materially consumes.
• DMARC reporting pipeline — the PER-M365-TENANT-PER-CUSTOM-DOMAIN- DKIM-DUAL-SELECTOR-SIGNED-MAIL-FLOW-AS-PER- PUBLISHER-PER-DOMAIN-RUA-AGGREGATE-XML-PER- DKIM-SELECTOR-PER-RECORD-ROW-ATTRIBUTION- EVIDENCE-SOURCE companion to THIS M365- tenant DKIM deployment reference. Where THIS page documents the per-M365-tenant per- custom-domain DKIM dual-selector CNAME- delegation publication discipline (the per- tenant selector1._domainkey.<custom- domain> CNAME pointing to selector1-<custom-domain>._domain key.<tenant>.onmicrosoft.com, the parallel selector2._domainkey CNAME for the rotation overlap-window, the per-tenant Exchange Online per-message emission with c=relaxed/relaxed canonicalization and RSA-2048 signing algorithm, and the per-tenant Microsoft 365 admin-center DKIM-enable / DKIM-disable / DKIM-rotate operator-discipline floor), the DMARC-reporting-pipeline spoke documents the per-publisher per-domain RFC 7489 §7 RUA aggregate-XML report-ingestion-and-parsing pipeline (per-receiver per-day per-publisher per-domain RUA aggregate-XML stream consumed at the rua=mailto:-published endpoint, per-record per-source-IP per- disposition row dedup, per-receiver- organisation per-day per-publisher per- domain attribution storage) through which the per-M365-tenant per-custom-domain DKIM- signed mail-flow materially renders as per- publisher per-domain per-receiver per-day DKIM-aligned-pass-rate-floor evidence at FOUR per-M365-tenant-DKIM-vs-DMARC-reporting- pipeline coupling dimensions: (i) per- M365-tenant per-custom-domain DKIM-Signature header s=selector1/s=selector2 per-message attribution as per-publisher per- domain RUA aggregate-XML auth_results/dkim/selector per-record row attribution evidence — every per-receiver per-message per-publisher per-domain DKIM-aligned-pass evaluation captures the per-message DKIM-Signature header's s= selector tag in the per-receiver Authentication-Results header, and the per-receiver per-day per-publisher per-domain RUA aggregate-XML report's per- record auth_results/dkim/selector XML element preserves that per-selector attribution at the per-publisher per-domain operator-side observability boundary — letting the per-M365-tenant per-custom-domain operator attribute per-receiver per-day per- publisher per-domain DKIM-aligned-pass-rate variance to the SPECIFIC per-tenant per- selector (selector1 vs selector2) root cause; (ii) per-M365-tenant per-custom-domain DKIM rotation overlap-window discipline as per-publisher per-domain RUA aggregate-XML per-selector-distribution-shift observability surface — during the per-M365-tenant per-custom-domain DKIM selector rotation overlap-window (Exchange Online's per-tenant admin-center per-custom-domain DKIM-rotate workflow rotates from selector1 to selector2 over a per-tenant operator-discipline-controlled rotation cadence), the per-publisher per-domain RUA aggregate-XML report's per-selector per- record row distribution SHIFTS from selector1-attributed records to selector2-attributed records, and the per-publisher per-domain DMARC reporting-pipeline observability surface IS the per-publisher per-domain canonical rotation-completion verification evidence the per-M365-tenant operator-discipline floor materially consumes; (iii) per-M365- tenant per-custom-domain Exchange Online Protection (EOP) inbound-routing classification as per-publisher per-domain RUF forensic- report per-message per-failure-reason attribution input — when per-M365- tenant per-custom-domain inbound mail flows through Exchange Online Protection at the per- tenant per-custom-domain inbound-MX boundary (*.mail.protection.outlook.com), EOP per-message disposition decisions feed per-tenant per-custom-domain Microsoft Defender for Office 365 forensic-evidence streams that include per-publisher per- domain RUF forensic-report attribution where the per-publisher per-domain DMARC ruf=mailto: endpoint publication directs forensic-report delivery; the DMARC-reporting-pipeline spoke documents the per-publisher per-domain forensic-report ingestion-and-parsing discipline the per-M365-tenant per-custom- domain operator needs to materially consume EOP per-disposition forensic attribution evidence; (iv) per-receiver per-day per-publisher per-domain RUA aggregate-XML per-source-IP per-record row distribution as per-M365-tenant outbound-egress per-IP attribution evidence — the per-M365- tenant per-custom-domain outbound mail-flow egresses from the per-tenant spf.protection.outlook.com- published IP pool, and the per-publisher per- domain RUA aggregate-XML report's per-source- IP per-record row distribution attributes per-message disposition evidence to specific per-tenant per-egress-IP at the per-receiver per-day per-publisher per-domain aggregate- observability boundary — letting the per- M365-tenant operator attribute per-receiver per-day per-publisher per-domain disposition variance to specific per-tenant outbound- egress IP-pool segments. Read THIS M365- tenant DKIM deployment reference when PUBLISHING the per-tenant per-custom-domain dual-selector DKIM CNAME-delegation discipline AND when ROTATING the per-tenant per-custom-domain DKIM selector cadence against per-publisher per-domain DMARC reporting-pipeline observability evidence; read the DMARC-reporting-pipeline spoke when OPERATING the per-publisher per-domain RUA- and-RUF aggregate-and-forensic-report ingestion-and-parsing discipline against per- M365-tenant per-custom-domain DKIM-aligned- pass-rate-floor preservation THIS page documents.
• MTA-STS policy file byte-grammar — the structurally parallel transport-layer publication-discipline companion to this M365-tenant DKIM application-layer publication reference. Where THIS page documents the per-M365-tenant per-custom-domain DKIM dual-selector (selector1._domainkey + selector2._domainkey) CNAME- delegated DNS TXT-RR publication discipline at the application-layer per-message DKIM-Signature cryptographic-binding boundary, the MTA-STS- policy-syntax spoke documents the structurally parallel per-publisher per-domain MTA-STS policy file byte-grammar publication discipline at the transport-layer per-receiving-MTA STARTTLS enforcement boundary. Four per-M365-tenant per- custom-domain composite application-and-transport- layer publication-discipline coupling dimensions matter at the per-tenant per-custom-domain publication boundary: (i) per-tenant per-custom- domain DUAL publication channel — per-tenant DKIM CNAMEs live in the per-tenant zone-file DNS publication channel, per-tenant MTA-STS policy lives in the per-tenant HTTPS-served Well-Known- URI publication channel, both bound to the per- tenant per-custom-domain zone-file commit-and- propagation boundary; (ii) per-tenant per-custom- domain DUAL receiver-side verification — per- receiver per-message DKIM verification consumes per-tenant per-selector public-key RSA-bytes, per-receiver per-MX-host MTA-STS verification consumes per-tenant per-MX-host policy-line mx-pattern match; (iii) per-tenant per-custom- domain DUAL operational rotation — per-tenant DKIM key rotation cadence (every 6-12 months per RFC 6376 §3.6.1 best-practice) is independent of per-tenant MTA-STS policy-id rotation cadence (whenever the per-tenant per-MX-host set changes), but both share per-tenant per-custom- domain commit-and-propagation cadence discipline; (iv) per-tenant per-custom-domain composite authentication-and-transport-layer publication portfolio — per-tenant DKIM publication + per- tenant SPF publication + per-tenant DMARC publication + per-tenant MTA-STS policy publication + per-tenant TLS-RPT publication form the composite per-tenant per-custom-domain authentication-and-transport-layer publication- discipline-floor portfolio every per-M365-tenant per-custom-domain deployment THIS page documents materially coordinates publication discipline against.
• MTA-STS explained — the canonical RFC 8461 MTA-STS protocol primer every M365 tenant operator should read alongside this DKIM deployment walkthrough to understand how the per-tenant transport-layer https://mta-sts.<tenant-domain>/.well-known/mta-sts.txt HTTPS-served policy file (declaring mx: *.outlook.com for the EOP inbound MX hosts) pairs with the per-tenant per-accepted-domain DKIM dual-selector CNAME- delegated DNS publication this page documents to form the per-M365-tenant composite per- custom-domain application-layer-authentication + transport-layer-encryption publication- discipline portfolio. Where THIS page locks the per-message DKIM-Signature cryptographic- binding at the application-layer, the MTA-STS- explained primer locks the per-receiving-MTA STARTTLS-enforcement boundary at the transport- layer — together they close the per-tenant per- custom-domain authentication-and-encryption publication floor.
• DMARC deployment checklist — read the DMARC deployment-checklist alongside this per-M365-tenant DKIM deployment spoke when AUTHORING the per- tenant per-custom-domain composite SPF + DKIM + DMARC publication-readiness sequence, when AUDITING the per-tenant DKIM CNAME-delegation cutover-readiness before per-publisher per-domain DMARC enforcement-mode-ramp progression, or when DIAGNOSING per-publisher per-domain DMARC- aligned-pass-rate floor regression traceable to per-M365-tenant per-custom- domain DKIM CNAME-delegation drift the deployment-checklist's Phase 5 post- enforcement-hygiene step closes.
• DMARC attacker-bypass catalogue
• DMARC myths and misconceptions — the PER-M365-TENANT-PER-CUSTOM-DOMAIN-DKIM-DUAL-SELECTOR-CNAME-DELEGATED-PUBLICATION-DISCIPLINE-AS-LOAD-BEARING-REBUTTAL-EVIDENCE-FOR-DMARC-PROTECTION-SCOPE-MYTH-CORRECTION companion at four per-M365-tenant per-custom-domain DKIM-publication-vs-DMARC-myth-correction coupling dimensions: (i) the “per-M365-tenant DKIM publication alone replaces DMARC” operator-misreading rebuttal — per-M365-tenant per-custom-domain dual-selector CNAME-delegated DKIM publication-discipline THIS page documents produces per-receiver per-message dkim=pass verdict per RFC 6376 §6.3 but DOES NOT produce per-receiver per-message DMARC-aligned-pass verdict per RFC 7489 §3.1.1 absent the per-tenant per-custom-domain DMARC TXT-RR `_dmarc.<tenant-domain>` publication that binds the receiver-side `adkim=`/`aspf=` alignment-mode-tag-driven `d=`-domain-vs-header-`From:`-domain alignment-evaluation discipline — the per-tenant DKIM-deployment THIS page documents WITHOUT the per-tenant DMARC publication leaves every per-receiver per-day per-attacker per-tenant-domain cousin-domain-spoofing message-class with `disposition=none` softening; (ii) the “per-M365-tenant `p=none` enforcement-mode is sufficient” operator-misreading rebuttal — per-M365-tenant per-custom-domain dual-selector DKIM publication-discipline produces per-receiver per-day per-tenant per-custom-domain DMARC-aligned-pass-rate-floor evidence stream via per-receiver per-day RUA aggregate-XML attribution but per-tenant per-custom-domain `p=none` enforcement-mode leaves per-receiver per-day per-attacker per-tenant-domain spoofed-message-class with `disposition=none` softening across every receiver — the per-tenant DKIM publication-discipline THIS page documents is the load-bearing per-tenant per-custom-domain application-layer-authentication publication-readiness precondition the per-publisher per-domain `p=none → p=quarantine → p=reject` enforcement-ramp consumes, NOT a substitute for the enforcement-ramp itself; (iii) the “per-M365-tenant CNAME-delegated DKIM closes all DMARC attacker-bypass attack-classes” operator-misreading rebuttal — per-M365-tenant per-custom-domain dual-selector CNAME-delegated DKIM publication-discipline closes the per-attacker per-target-domain direct-domain-spoofing attack-class via per-receiver per-message DKIM-Signature `d=`-tag-vs-header-`From:`-domain-alignment-evaluation, but per-M365-tenant per-custom-domain DKIM-CNAME-delegation publication-discipline DOES NOT close per-attacker per-target-domain DMARC-policy-circumvention bypass-cascade classes (per-attacker per-M365-tenant-acquired-cousin-domain attack-class, per-attacker per-tenant per-mailing-list-cascade DKIM-resign-breakage attack-class, per-attacker shared-EOP-egress-IP-pool cross-tenant cousin-domain spoofing attack-class) the per-M365-tenant operator-side `help_dmarc_attacker_bypass.php` catalogue documents the per-attacker per-target-domain bypass-class mitigation operational-discipline of; (iv) the “per-M365-tenant DKIM publication closes per-attacker per-target-domain spear-phishing infrastructure-provisioning” operator-misreading rebuttal — per-M365-tenant per-custom-domain dual-selector DKIM-Signature application-layer cryptographic-authentication-leg publication-discipline closes per-receiver per-message direct-domain-spoofing verdict-evaluation but DOES NOT close per-attacker per-tenant-acquired-lookalike-domain + per-tenant-acquired-cousin-domain + per-tenant-acquired-IDN-homograph-domain PKI-layer cert-mis-issuance attack-class subset whose per-attacker per-target-domain HTTPS-enabled credential-harvesting + spear-phishing message-source infrastructure-provisioning depends on the per-attacker per-domain TLS-cert acquisition that the per-tenant per-accepted-domain CAA-RR per-CA-allowlist publication-discipline (NOT the per-tenant DKIM publication-discipline THIS page documents) blocks at per-CA-issuance time per RFC 8659 §3 — the per-tenant DKIM publication-discipline THIS page documents IS structurally one of seven application-and-transport-and-PKI-layer per-tenant per-custom-domain publication-discipline references whose composite-publication-portfolio coordination the per-publisher per-domain DMARC-myths-and-misconceptions rebuttal-catalogue corrects against the per-tenant per-custom-domain operator-side single-leg-suffices misreading.
• TLS-RPT explained — the per-publisher per-domain transport-layer aggregate-observability primer companion at four per-M365-tenant per-custom-domain DKIM-publication-vs-TLS-RPT-transport-layer-observability coupling dimensions: (i) per-M365-tenant per-custom-domain DKIM-Signature dual-selector application-layer cryptographic-authentication-leg per RFC 6376 §3.5 THIS page documents the per-M365-tenant per-custom-domain CNAME-delegated DKIM publication-discipline of IS the structurally-parallel application-layer authentication-leg companion to per-M365-tenant per-custom-domain MTA-STS transport-layer policy-publication discipline whose per-receiver per-day per-MX-host transport-handshake survival surfaces in per-M365-tenant per-custom-domain TLS-RPT JSON-aggregate-report policy + summary attribution per RFC 8460 §4.3 — both per-M365-tenant per-custom-domain per-leg publication-discipline references coordinate at the per-M365-tenant per-custom-domain composite cross-layer application-and-transport-layer publication-discipline coordination boundary; (ii) per-M365-tenant per-custom-domain DKIM-Signature CNAME-delegation publication-propagation cache-coherence cadence IS structurally parallel per-tenant per-custom-domain DNS-publication-cadence operational-discipline to per-M365-tenant per-custom-domain MTA-STS HTTPS-served-policy id: rotation cadence + _mta-sts.<tenant-domain> TXT-RR v=STSv1; id=<rotation-id> publication-cadence — both per-M365-tenant per-custom-domain DNS-publication-cadence references coordinate at the per-M365-tenant per-custom-domain composite cross-layer DNS-publication-cadence coordination boundary the per-publisher per-policy-domain TLS-RPT transport-layer observability stream THIS spoke documents materially surfaces; (iii) per-M365-tenant per-custom-domain DKIM-Signature CNAME-delegation publication-discipline drift (CNAME-delegation-not-propagated / dual-selector-mid-rotation-misalignment) surfaces as per-receiver per-day DMARC RUA per-source-IP dkim=temperror/dkim=permerror attribution IS structurally parallel publication-discipline-drift class to per-M365-tenant per-custom-domain MTA-STS publication-discipline drift (CNAME-not-propagated / HTTPS-host-cert-host-mismatch) surfacing in per-policy-domain TLS-RPT sts-policy-fetch-error/certificate-host-mismatch attribution per RFC 8460 §4.3; (iv) per-M365-tenant per-custom-domain DKIM-Signature application-layer cryptographic-authentication-leg IS structurally complementary to per-M365-tenant per-custom-domain MTA-STS + TLS-RPT transport-layer per-MX-host transport-integrity observability stream whose per-day per-MX-host per-failure-class attribution surfaces per-M365-tenant per-custom-domain transport-layer-coverage-gap evidence the per-publisher per-domain transport-layer aggregate-observability primer THIS TLS-RPT spoke documents the per-publisher per-policy-domain transport-layer per-failure-class catalogue of materially surfaces against the per-M365-tenant per-custom-domain dual-leg authentication-and-transport-coverage floor THIS page documents.
• CAA records explained — the PER-M365-TENANT-PER-ACCEPTED-DOMAIN-CAA-RR-PKI-LAYER-PER-CA-ALLOWLIST-PUBLICATION-DISCIPLINE-AS-STRUCTURALLY-PARALLEL-PKI-LAYER-PUBLICATION-DISCIPLINE-COMPANION-TO-PER-M365-TENANT-PER-ACCEPTED-DOMAIN-DKIM-DUAL-SELECTOR-CNAME-DELEGATED-APPLICATION-LAYER-PUBLICATION-DISCIPLINE companion at four per-M365-tenant per-accepted-domain CAA-RR-PKI-layer-publication-discipline-vs-DKIM-application-layer-publication-discipline coupling dimensions: (i) per-M365-tenant per-accepted-domain CAA-RR 0 issue "<ca-domain>" + 0 issuewild "<ca-domain>" property-tag publication-discipline per RFC 8659 §4.2 IS structurally parallel per-M365-tenant per-accepted-domain PKI-layer per-CA-allowlist publication-discipline to per-M365-tenant per-accepted-domain DKIM selector1._domainkey.<tenant-domain> + selector2._domainkey.<tenant-domain> dual-CNAME-delegated application-layer publication-discipline per RFC 6376 §3.6.1 THIS page documents — both are per-M365-tenant per-accepted-domain DNS-published per-tenant per-domain authentication-and-PKI-trust-anchor publication-discipline references at the per-M365-tenant per-accepted-domain composite application-layer-and-PKI-layer publication-discipline coordination boundary; (ii) per-M365-tenant per-accepted-domain CAA-RR 0 iodef "mailto:<security-contact>" incident-attribution-mailbox publication-discipline per RFC 8659 §4.4 IS structurally parallel per-tenant per-accepted-domain operator-side incident-attribution-mailbox publication primitive to per-M365-tenant per-accepted-domain DMARC rua=mailto: aggregate-report-URI + ruf=mailto: forensic-report-URI publication-discipline per RFC 7489 §6.2 — both per-M365-tenant per-accepted-domain operator-side per-incident-event attribution-discipline primitives whose per-M365-tenant per-accepted-domain operator-side per-attacker per-event mitigation-discipline depends on; (iii) per-M365-tenant per-accepted-domain CAA-RR per-CA-allowlist publication-discipline closes per-attacker per-M365-tenant-acquired-lookalike-domain + per-attacker per-M365-tenant-acquired-cousin-domain PKI-layer cert-mis-issuance attack-class subset whose per-attacker per-target-domain HTTPS-enabled credential-harvesting + spear-phishing message-source infrastructure-provisioning depends on per-attacker per-domain TLS-cert acquisition per RFC 8659 §3 BLOCKS — structurally parallel per-tenant per-accepted-domain application-layer authentication-leg discipline to per-M365-tenant per-accepted-domain DKIM-Signature application-layer per-message-authentication-leg discipline closing per-attacker per-target-domain direct-domain-spoof BEC attack-class via per-tenant per-accepted-domain DKIM-aligned-pass leg verdict-attribution per RFC 7489 §3.1.1; (iv) per-M365-tenant per-accepted-domain CAA-RR publication-discipline drift (missing CAA-RR at apex / overly-permissive `0 issue ";"` deny-all-but-self mis-publication / missing `iodef` incident-mailbox / CAA-RR DNSSEC-unsigned-zone exposing per-attacker per-zone CAA-RR DNS-cache-poisoning attack-class) directly opens per-M365-tenant per-accepted-domain PKI-layer per-attacker per-tenant-acquired-domain rogue-CA cert-issuance attack-window structurally parallel to per-M365-tenant per-accepted-domain DKIM selector1._domainkey.<tenant-domain>/selector2._domainkey.<tenant-domain> CNAME-delegation publication-discipline drift (CNAME-not-propagated / dual-selector mid-rotation-misalignment / per-tenant per-accepted-domain DKIM-aligned-pass-rate floor regression) the per-M365-tenant per-accepted-domain DKIM-for-M365 spoke THIS page documents the per-M365-tenant per-accepted-domain dual-CNAME-delegated-rotation publication-discipline of catalogues against — together the per-M365-tenant per-accepted-domain DKIM dual-CNAME-delegated application-layer cryptographic-authentication-leg publication-discipline THIS page documents AND the per-M365-tenant per-accepted-domain CAA-RR PKI-layer per-CA-allowlist publication-discipline compose the per-M365-tenant per-accepted-domain composite application-and-PKI-layer cross-layer authentication-and-PKI publication-discipline-floor coordination boundary.
• DMARC records explained
• DMARC troubleshooting — the diagnostic-workflow companion to this M365 DKIM page. Where this page documents the per-tenant per-accepted-domain dual-selector selector1._domainkey / selector2._domainkey CNAME-delegation publication discipline and the EOP-signing enablement steps, the DMARC-troubleshooting spoke documents the symptom-to-root-cause diagnostic path the operator follows when those steps go wrong: the per-receiver per-message dkim=fail in the RUA aggregate stream that traces to a CNAME-not-yet-propagated selector, the dkim=none that traces to EOP DKIM-signing left disabled in the Defender portal, the dual-selector mid-rotation misalignment window, and the adkim=s strict-mode alignment failure where the EOP d=<tenant>.onmicrosoft.com signing domain does not organisationally align with the visible From: domain. Read the DMARC-troubleshooting spoke when a tenant's RUA stream shows DKIM-fail or DMARC-fail rows and the operator needs the structured triage path from symptom back to the CNAME-delegation or EOP-signing root cause this M365 DKIM page documents the correct publication discipline for.
• Why SPF alone is insufficient — the protocol-layer rebuttal of the “we publish SPF, so we are covered” mental model. SPF authorises the envelope MAIL FROM (not the visible From: header) and breaks under forwarding; the DKIM signing this M365 guide sets up is the second authentication leg whose aligned-pass the why-SPF-alone spoke argues is mandatory for a DMARC p=reject contract.
• DMARC forensic reports — where a per-message authentication failure on your M365-tenant domain is captured in detail. When a selector1/selector2 CNAME is mispublished or a message arrives with a broken signature, a ruf= failure (forensic) report carries the redacted headers and the dkim=/spf= verdicts that show exactly which leg failed. Read the forensic-reports spoke to learn how to enable and read these per-failure samples alongside aggregate monitoring.
• SPF mechanisms explained — the envelope-layer companion to the DKIM signing this page sets up on your M365 tenant: the same domain that publishes selector1/selector2 DKIM CNAMEs also publishes an SPF record built from the include:spf.protection.outlook.com mechanism, so the DMARC composite has both legs to lean on. Read the SPF mechanism catalogue (a/mx/ip4/include/all + the RFC 7208 §4.6.4 10-DNS-lookup cap) to keep the tenant's SPF leg authorizing exactly the Outlook sending hosts without overflowing the lookup budget.
• Microsoft SNDS + JMRP monitoring — the consumer-network half of the Microsoft story: authentication can be perfect and Outlook.com/Hotmail will still junk-folder mail from an IP with a degraded SNDS filter verdict; SNDS grades every sending IP GREEN/YELLOW/RED and JMRP streams each Junk click back as an ARF complaint report.

Verify DKIM on your Microsoft 365 tenant now

DMARC Analyzer parses the daily aggregate reports Microsoft and other receivers send to your rua= mailbox and surfaces the per-sender DKIM verdict breakdown via includes/DmarcParser.php — catching the onmicrosoft.com signing-domain failure mode within hours of the first misaligned message. Live DNS verification for every DKIM selector on your domain runs through includes/DnsChecker.php; the Email Header Analyzer at header_analyzer.php diagnoses individual message failures by parsing the full Authentication-Results stack via includes/EmailHeaderParser.php.

Sign up — Free plan Check my Microsoft 365 DKIM setup