DMARC Analyzer

TL;DR

• Hybrid Exchange means outbound mail can flow through either Exchange on-premises or Exchange Online - or both. The DMARC story is harder than cloud-only because alignment must hold regardless of which side wrote and signed the message.
• The cleanest hybrid DMARC topology is Centralized Mail Transport (CMT): on-prem Exchange relays all outbound through Exchange Online, only the cloud signs DKIM, SPF lists only spf.protection.outlook.com, and DMARC alignment is unambiguous. Enable via the Hybrid Configuration Wizard or Set-HybridConfiguration -CentralizedTransportEnabled $true.
• SPF in classic hybrid must include BOTH sides: v=spf1 ip4:<onprem-NAT-range> include:spf.protection.outlook.com -all. Stay under the 10-DNS-lookup limit (RFC 7208 §4.6.4) - consolidate on-prem IPs into a single ip4: CIDR block when possible.
• The dual-signer DKIM problem is the #1 hybrid DMARC failure mode: both on-prem (via Exclaimer, GFI, or Zix transport agent) AND Exchange Online sign the same message under different d= domains, and receivers pick the wrong signature for alignment. Fix: choose ONE signing side; disable the other via Set-DkimSigningConfig -Identity your-domain.com -Enabled $false or uninstall the on-prem agent.
• ARC sealing (RFC 8617) is the standards-track way to preserve original SPF and DKIM verdicts across the on-prem-to-cloud relay. Configure Defender for Office 365 Trusted ARC Sealers via Set-ArcConfig -ArcTrustedSealers <your-onprem-fqdn>. The cloud trusts the on-prem ARC seal and re-evaluates DMARC using the original verdicts the on-prem boundary captured.
• The Default Frontend Connector DKIM strip is the classic hybrid gotcha: Exchange Online's inbound connector from on-prem strips existing DKIM signatures before transport, so on-prem DKIM is lost at the relay. Set Set-Connector -PreserveSmtpHeaders $true on the matching inbound connector, OR migrate to CMT so on-prem never signs in the first place.
• Send Connector relay loops occur when on-prem Send Connectors and cloud inbound connectors form a cycle. Symptom: NDR 5.4.6 Hop count exceeded. Prevention: accept the Hybrid Configuration Wizard's connector pair as-is, set accepted-domain DomainType correctly (Authoritative vs InternalRelay), and verify Get-MessageTrace shows exactly one cloud hop on outbound.
• DMARC rollout in hybrid takes longer than cloud-only: budget 4-8 weeks at p=none (vs 2-6 weeks cloud-only) because more sender paths surface in reports - one per hybrid mail-flow combination multiplied by every legitimate SaaS sender, application relay, and on-prem-only mailbox.
• The Feb 2024 Google/Yahoo bulk-sender requirements apply regardless of which side of hybrid handles outbound. Any domain sending >5000 messages/day to gmail.com or yahoo.com needs SPF + DKIM alignment, DMARC at minimum p=none, RFC 8058 one-click List-Unsubscribe, and a spam-complaint rate under 0.3%.
• The endgame for most hybrid deployments is full Exchange Online (cloud-only) mail flow, with on-prem retained for legacy public-folder access, on-prem journaling, or geographic compliance. The CMT topology is the operational stepping stone - eliminates the dual-signer problem without retiring on-prem servers.

1. What this guide covers

This is the operator-implementation walkthrough for deploying SPF, DKIM, ARC, and DMARC on a domain whose mail flow is split between Exchange on-premises and Exchange Online (Microsoft 365) - the topology Microsoft calls "hybrid Exchange" and the operator-pain segment the cloud-only DMARC for Microsoft 365 guide intentionally deferred. The guide assumes you are the administrator of a hybrid Exchange organisation and have access to:

• The Exchange Management Shell on the on-prem Exchange server (for Get-HybridConfiguration, Set-AcceptedDomain, Get-SendConnector, Get-TransportConfig, and related cmdlets).
• The Exchange Online PowerShell V3 module on a workstation (for Connect-ExchangeOnline, Set-DkimSigningConfig, Set-ArcConfig, Set-Connector -PreserveSmtpHeaders, and related cmdlets).
• The Microsoft 365 Defender portal at security.microsoft.com - the modern UI for DKIM management, Trusted ARC Sealers configuration, and anti-spoof policy.
• The on-prem Exchange Admin Center (typically at https://<exchange-fqdn>/ecp) for accepted-domain configuration, mail flow rules, and connector management on the on-prem side.
• Your domain's DNS provider (Cloudflare, Route 53, on-prem AD-integrated DNS, etc.) - used to publish SPF, the DKIM CNAMEs that route to your tenant's <tenant>.onmicrosoft.com key infrastructure, and the DMARC TXT record.
• A working email mailbox on the domain to receive DMARC aggregate reports (or a third-party report-ingestion service - DMARC Analyzer is one option).

The guide is structured as four sequential deployment steps (SPF for hybrid → dual-signer DKIM → ARC sealing the relay → DMARC rollout) plus a hybrid topology overview, an outbound mail-flow decision tree, Send Connector / Default Frontend connector pitfalls, hybrid-specific gotchas, common mistakes, and migration paths from classic hybrid through Centralized Mail Transport to fully cloud-routed mail flow.

What this guide does not cover:

• On-premises Exchange Server in isolation (no cloud component). Pure on-prem Exchange runs its own outbound boundary, signs DKIM via a transport agent like Exclaimer or Zix, and publishes SPF for its perimeter outbound IPs only. spf.protection.outlook.com is not part of the SPF.
• Exchange Online in isolation (no on-prem component). The DMARC for Microsoft 365 sibling page is the complete reference - this hybrid page explicitly defers cloud-only mechanics to it.
• Migration tooling from third-party platforms (Google Workspace to M365, Lotus Notes to Exchange Online, on-prem Exchange to Google Workspace). Those are separate migration projects with their own DMARC implications during the cutover window.
• Mailbox migration mechanics (move-mailbox cmdlets, MRS proxy, batch moves). The hybrid topology supports mailbox migration in both directions but mailbox migration itself does not affect DMARC - only the OUTBOUND mail flow topology does.

2. The hybrid topology spectrum

"Hybrid Exchange" is not a single topology - it spans a spectrum of configurations that differ in WHICH side handles outbound mail delivery, HOW mail is routed between the sides, and WHERE accepted domains are authoritative. The DMARC implementation follows from the topology, so identifying YOUR specific topology is the prerequisite for every other step in this guide.

2.1 Classic Hybrid (HCW-configured, on-prem outbound by default)

The default output of running the Hybrid Configuration Wizard (HCW) against an on-prem Exchange 2013+ organisation with at least one Exchange Online tenant. After HCW:

• On-prem Exchange is the outbound boundary for accepted domains that remain Authoritative on-prem.
• Exchange Online is the outbound boundary for cloud-mailbox users with accepted domains marked Authoritative in the cloud.
• The bidirectional Send Connector pair configured by HCW handles internal mail flow between the two sides with mutual TLS authentication via the on-prem certificate.

DMARC implications of classic hybrid: both sides need DKIM signing under the same custom domain (or you accept the dual-signer problem), SPF must include both sides (ip4: on-prem ranges plus include:spf.protection.outlook.com), and ARC sealing is essential for messages that traverse the on-prem-to-cloud relay. This is the highest-complexity hybrid topology from a DMARC perspective.

2.2 Centralized Mail Transport (CMT, cloud outbound boundary)

A Microsoft 365 feature that overrides the classic hybrid default: even mail composed on on-prem Exchange relays to Exchange Online for outbound delivery. Enabled via:

Set-HybridConfiguration -CentralizedTransportEnabled $true

or by selecting the "Centralized Mail Transport" checkbox during HCW. After CMT:

• Exchange Online is the single outbound boundary for ALL accepted domains - regardless of where mailboxes live.
• On-prem Exchange remains operational but only for internal mail and on-prem-to-cloud relay.
• DKIM signing happens only on the cloud side under the standard selector1 / selector2 CNAME-delegation workflow.

DMARC implications of CMT: this is the operator-friendliest hybrid topology. SPF drops the on-prem ip4: ranges (only include:spf.protection.outlook.com remains), only the cloud signs DKIM, and ARC sealing is optional because the relay leg from on-prem to cloud happens INSIDE the trust boundary. The dual-signer problem is eliminated by construction. The trade-off is bandwidth and latency: every outbound message round-trips through the cloud regardless of recipient location.

2.3 Split-domain coexistence

A non-HCW topology where the same SMTP domain has some mailboxes on-prem and some on Exchange Online, with mail routing decided per-mailbox via accepted-domain configuration and InternalRelay address spaces. Common during phased migration when you want to move mailboxes one batch at a time without changing the MX record. After split-domain configuration:

• The domain's accepted-domain DomainType is set to InternalRelay on both sides (not Authoritative).
• Each side has a complete address list and forwards mail for "unknown" local recipients to the other side.
• Outbound mail can leave either side depending on which mailbox sent it.

DMARC implications of split-domain: identical to classic hybrid because both sides independently handle outbound. The operational pain is amplified because every accepted domain effectively has two "homes" and operators must track which mailboxes are where.

2.4 Edge Transport servers

An on-prem topology where dedicated Edge Transport role servers sit at the perimeter (DMZ) and handle SMTP relay to and from the internet, with the internal Exchange Mailbox role servers sitting behind them. EdgeSync replicates accepted-domain and recipient information from the internal AD to the Edge servers.

Edge Transport is orthogonal to hybrid - you can run Edge Transport on top of classic hybrid or CMT. DMARC implications: SPF lists the Edge Transport perimeter IPs (NOT the internal Mailbox role IPs), DKIM signing is typically configured at the Edge Transport role (so messages leave the perimeter signed), and any on-prem ARC sealer runs at Edge Transport to capture the last verdict before the perimeter SMTP egress.

2.5 Identifying YOUR topology

From the Exchange Management Shell on the on-prem Exchange server, run:

Get-HybridConfiguration | Format-List
Get-AcceptedDomain | Format-Table DomainName, DomainType, AddressBookEnabled
Get-SendConnector | Format-Table Name, AddressSpaces, SmartHosts
Get-IntraOrganizationConnector | Format-Table Name, TargetAddressDomains, Enabled

Key fields to inspect:

• Get-HybridConfiguration .Features: contains CentralizedTransport if CMT is enabled.
• Get-HybridConfiguration .EdgeTransportServers: non-empty if Edge Transport is in use.
• Get-AcceptedDomain .DomainType: Authoritative means this side handles outbound for the domain; InternalRelay means split-domain coexistence.
• Get-SendConnector whose AddressSpaces match *: the connector handling all external outbound. If its SmartHosts point at *.mail.protection.outlook.com, you have CMT; if not, classic hybrid.

Once you know your topology, the decision tree in section 3 prescribes the SPF / DKIM / ARC / DMARC implementation steps for your specific case.

3. The outbound mail-flow decision tree

Use this decision tree to identify the SPF construction, DKIM signing side, and ARC sealing requirement for your hybrid topology. Answer the questions in order; the first match wins.

3.1 Question 1: Is Centralized Mail Transport enabled?

From the Exchange Management Shell:

(Get-HybridConfiguration).Features -contains "CentralizedTransport"

If True: you have CMT. Skip to 3.1.1 Implementation for CMT. Mail flow is cloud-out regardless of where messages originate.

If False: you have classic hybrid or split-domain. Proceed to Question 2.

3.1.1 Implementation for CMT

• SPF: v=spf1 include:spf.protection.outlook.com -all (plus any additional SaaS sender includes - see SPF explained).
• DKIM: cloud-side only. Use the standard selector1 / selector2 CNAME-delegation workflow from the DMARC for Microsoft 365 sibling page.
• ARC sealing: optional. The on-prem-to-cloud relay leg is inside the trust boundary; on-prem does not need to seal because the cloud is the only outbound boundary that emits Authentication-Results to external receivers.
• DMARC: identical to cloud-only deployment - publish v=DMARC1; p=none; rua=mailto: at _dmarc.<your-domain> and advance through the standard rollout phases.

3.2 Question 2: Does on-prem Exchange sign DKIM?

On the on-prem Exchange server, check for an installed DKIM transport agent:

Get-TransportAgent | Format-Table Identity, Enabled, Priority
Get-Module -ListAvailable | Where-Object Name -like "*Exclaimer*","*GFIMailEssentials*","*Zix*","*Symantec*"

Inspect the Authentication-Results header on a sample outbound message from an on-prem mailbox: if dkim=pass header.d= points at your custom domain, on-prem is signing. If dkim=none or no DKIM-Signature header is present, on-prem is NOT signing.

If on-prem signs AND cloud signs under the same custom domain: you have the dual-signer pattern. Proceed to section 5 and pick ONE side to disable.

If on-prem signs AND cloud is NOT signing: this is the cleanest classic hybrid pattern for DMARC purposes. Keep on-prem signing, ensure ARC sealing is configured for the on-prem-to-cloud relay (see section 6), and leave Set-DkimSigningConfig -Identity your-domain.com -Enabled $false on the cloud side.

If on-prem does NOT sign and cloud signs: the cleanest topology for DMARC. ARC sealing is unnecessary for outbound (since on-prem doesn't sign there's no original verdict to preserve) and you can treat the cloud-side DKIM workflow as cloud-only. However, you still need on-prem ARC sealing for INBOUND mail that traverses on-prem before reaching cloud mailboxes - the cloud needs original verdicts to apply spoofing protections.

If neither side signs: you have no DKIM at all. Start with the DKIM explained pillar then return here.

3.3 Question 3: Do messages traverse the on-prem-to-cloud relay?

Almost always yes in a hybrid topology - INBOUND mail to cloud mailboxes from external receivers either lands at on-prem first (if on-prem holds the MX record) or at cloud first (if cloud holds the MX record). The MX is typically at cloud after HCW unless explicitly reconfigured.

If MX points at cloud first (*.mail.protection.outlook.com): the cloud is the inbound boundary, Exchange Online evaluates SPF + DKIM + DMARC, and relays to on-prem only for on-prem mailboxes. ARC sealing across the cloud-to-on-prem hop is rarely needed because on-prem already trusts the cloud.

If MX points at on-prem first: on-prem is the inbound boundary, on-prem evaluates SPF + DKIM + DMARC, and relays to cloud for cloud mailboxes. ARC sealing is essential here: without it, cloud sees mail relayed from on-prem with rewritten Received headers and no surviving verdicts, and cloud-side anti-spoofing applies wrong dispositions.

4. Step 1: Configure SPF for the hybrid topology

Publish a single SPF TXT record at the domain apex (the root of your zone) that authorises EVERY legitimate outbound IP range AND every nested include for SaaS senders the domain uses. The defining hybrid challenge is including both sides while staying under the 10-DNS-lookup limit defined in RFC 7208 §4.6.4.

4.1 SPF for CMT (cloud outbound boundary)

With CMT enabled, on-prem Exchange does not talk to external receivers directly - it relays through the cloud. The SPF record therefore needs only the cloud include:

your-domain.com.   IN TXT  "v=spf1 include:spf.protection.outlook.com -all"

During the migration window before enforcement, use ~all (soft-fail) instead of -all:

your-domain.com.   IN TXT  "v=spf1 include:spf.protection.outlook.com ~all"

4.2 SPF for classic hybrid (both sides outbound)

Without CMT, both on-prem and cloud need SPF authorisation. Identify the on-prem outbound IPs - typically the perimeter firewall NAT pool for the Exchange Send Connector, NOT the Exchange server's internal IP:

# On the perimeter firewall, identify the outbound NAT range used
# by Exchange Send Connectors. This is the public IP set seen by
# external receivers in their Received: headers and the IP that
# SPF must authorise. Common pattern: a /29 or /28 CIDR block
# dedicated to the Exchange perimeter.
your-domain.com.   IN TXT  "v=spf1 ip4:203.0.113.0/29 include:spf.protection.outlook.com -all"

If on-prem outbound spans multiple IP ranges or geographic regions, consolidate into a single CIDR block when network addressing allows. Each separate ip4: token does NOT consume a DNS lookup, but readability and operational clarity favour consolidation. Example with multiple ranges:

your-domain.com.   IN TXT  "v=spf1 ip4:203.0.113.0/29 ip4:198.51.100.16/28 include:spf.protection.outlook.com include:sendgrid.net -all"

4.3 The 10-DNS-lookup limit in hybrid

spf.protection.outlook.com itself resolves to multiple nested includes and consumes more than one lookup. In hybrid topologies that also include SaaS senders (transactional ESPs, marketing platforms, on-prem application relays via SendGrid), the limit fills quickly. Use the Domain Security Checker to report the live lookup count against your SPF record - if the count exceeds 10, SPF evaluation will return permerror and DMARC fails.

Mitigation strategies for hybrid:

• Migrate to CMT: eliminates the on-prem ip4: entries entirely because on-prem no longer talks to external receivers directly. The single largest SPF simplification you can make.
• SPF flattening: resolve nested include: entries down to raw ip4: CIDRs - reduces lookups but breaks when the underlying provider changes IPs. Use only as a last resort with operational monitoring to detect drift.
• Subdomain delegation: delegate high-volume SaaS senders to dedicated subdomains (marketing.your-domain.com, transactional.your-domain.com) each with their own SPF - the apex SPF stays clean. The trade-off is operational complexity at the SaaS provider side (each provider must be configured to use the delegated subdomain as the visible From:).

Verify the record with dig +short txt your-domain.com after publication, or via the Domain Security Checker.

5. Step 2: Configure DKIM signing (and resolve the dual-signer problem)

DKIM signing in hybrid Exchange is the single highest-leverage operational decision in this guide. The cloud-only M365 page documents the standard selector1 / selector2 CNAME-delegation workflow - that workflow applies unchanged in hybrid on the cloud side. The hybrid-specific complexity is whether on-prem ALSO signs and, if so, under which d= domain.

5.1 The cloud-only signing pattern (preferred)

Strongly recommended for new hybrid deployments and required for CMT topology. Configuration:

1. On the cloud side, enable DKIM for the custom accepted domain per the standard M365 workflow:

   Connect-ExchangeOnline
   Set-DkimSigningConfig -Identity your-domain.com -Enabled $true
   Get-DkimSigningConfig -Identity your-domain.com

2. On the on-prem side, ensure NO DKIM transport agent is installed:

   Get-TransportAgent | Format-Table Identity, Enabled, Priority
   # Inspect for Exclaimer / GFI / Zix / Symantec DKIM agents.
   # If present, decide whether to uninstall (recommended) or
   # disable + remove from the signing pipeline.

3. Verify by sending a test message from an on-prem mailbox to a Gmail or Yahoo address. Inspect the message source - the DKIM-Signature header must show d=your-domain.com (the cloud signature, captured on the on-prem-to-cloud relay leg and carried out by Exchange Online to external).

5.2 The on-prem-only signing pattern (acceptable)

Acceptable for classic-hybrid topologies where on-prem is the outbound boundary AND you have a working on-prem DKIM signer. Configuration:

1. On the on-prem side, install and configure a DKIM transport agent. Common choices: Exclaimer Mail Signatures (commercial), GFI MailEssentials (commercial), Zix DKIM (commercial), or the open-source DKIM transport agent project. Each signer's UI is different; all need the same five inputs: the signing domain (d=your-domain.com), the selector (a label of your choice - convention is onprem or exchange), the RSA private key (generate via OpenSSL), canonicalisation modes (use relaxed/relaxed), and the list of headers to sign (canonical set: From, To, Subject, Date, Message-ID).
2. Publish the corresponding public-key TXT record at <your-selector>._domainkey.your-domain.com:

   onprem._domainkey.your-domain.com.   IN TXT  "v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAxxx...IDAQAB"

3. On the cloud side, DISABLE DKIM signing for the same accepted domain to prevent the dual-signer problem:

   Connect-ExchangeOnline
   Set-DkimSigningConfig -Identity your-domain.com -Enabled $false
   Get-DkimSigningConfig -Identity your-domain.com  # Confirm Enabled=False

4. Configure ARC sealing on the on-prem side (see section 6) so the on-prem DKIM verdict is preserved across the on-prem-to-cloud relay.

5.3 The dual-signer problem (avoid)

Occurs when BOTH on-prem and cloud sign outbound messages from the same custom domain - typically because the operator set up cloud-side DKIM but forgot (or did not know) that an on-prem DKIM transport agent was also installed and signing. The operational symptom:

• Outbound messages from on-prem mailboxes arrive at receivers with TWO DKIM-Signature headers - one from on-prem (d=your-domain.com, s=onprem) and one from cloud (d=<tenant>.onmicrosoft.com, s=selector1 or s=selector2).
• Outbound messages from cloud mailboxes have only ONE signature (cloud).
• Receivers iterate through both signatures looking for one that passes AND aligns with the From: header. The on-prem signature aligns (matches your-domain.com) but may be broken because the cloud Default Frontend connector modified the message body before relaying; the cloud signature passes but does NOT align (onmicrosoft.com ≠ your-domain.com).
• The receiver's DMARC verdict depends on implementation details of how the receiver iterates DKIM signatures - the outcome is non-deterministic and varies between gmail.com, yahoo.com, microsoft.com, and others.

Resolution: pick ONE signing side per section 5.1 or 5.2. The cloud-only pattern is strongly preferred unless you have a hard requirement to sign on-prem (typically a compliance signature-content requirement that the cloud signer cannot meet).

5.4 The onmicrosoft.com signing pattern (avoid)

Documented in the cloud-only M365 guide section 7 as the #1 cloud-only DMARC failure mode - the same failure mode applies in hybrid. If cloud signs under d=<tenant>.onmicrosoft.com instead of your custom domain, DMARC alignment fails regardless of what on-prem does. Fix: confirm both selector1._domainkey and selector2._domainkey CNAMEs resolve via:

dig +short cname selector1._domainkey.your-domain.com
dig +short cname selector2._domainkey.your-domain.com

Both must return selectorN-your-domain-com._domainkey.<tenant>.onmicrosoft.com. If they resolve but DKIM is still under onmicrosoft.com, the operator forgot to enable signing for the custom accepted domain - run Set-DkimSigningConfig -Identity your-domain.com -Enabled $true.

6. Step 3: ARC sealing the on-prem-to-cloud relay (RFC 8617)

ARC (Authenticated Received Chain, RFC 8617) is the standards-track mechanism for preserving original SPF / DKIM / DMARC verdicts across mail-relay hops that would otherwise break authentication. The canonical hybrid use case: a legitimate external message arrives at on-prem Exchange, on-prem evaluates SPF + DKIM + DMARC and captures verdicts, on-prem relays to Exchange Online for a cloud mailbox recipient, Exchange Online needs the original verdicts to apply correct anti-spoofing dispositions even though its own SPF / DKIM evaluation against the on-prem relay will fail.

6.1 ARC sealing on the on-prem side

On-prem Exchange does NOT include native ARC sealing - it must be installed via a third-party transport agent. The most common options:

• Exclaimer Mail Signatures with ARC module: commercial product, integrates with Exchange Transport pipeline at the on-prem side.
• The open-source ARC sealer for Exchange Transport: community-maintained PowerShell-based transport agent.
• Defender for Office 365 ARC Sealer in trusted-intermediary mode: Microsoft's first-party tool when the on-prem path is configured as a known relay.

The ARC sealer needs the same five inputs as a DKIM signer: signing domain (your-domain.com), selector (convention: arc), RSA private key, canonicalisation mode (relaxed/relaxed recommended), and the list of headers to seal. Additionally, the ARC sealer reads the Authentication-Results header on the inbound message (which on-prem Exchange writes itself) and captures those verdicts into the ARC-Authentication-Results header it inserts.

After configuration, every inbound message that on-prem will relay outward or to cloud gains three new headers inserted in the order ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results - the "ARC set" that downstream hops can verify and extend.

6.2 Trusted ARC Sealers on the cloud side

Exchange Online does NOT automatically trust ARC seals from arbitrary intermediaries - the operator must explicitly configure WHICH ARC-signing domains the cloud should trust. This is the Defender for Office 365 Trusted ARC Sealers feature:

Connect-ExchangeOnline
Set-ArcConfig -ArcTrustedSealers <your-onprem-fqdn>
Get-ArcConfig | Format-List

<your-onprem-fqdn> is the fully-qualified domain name of your on-prem Exchange ARC sealer - typically something like mail.your-domain.com. This is the domain in the d= field of the ARC-Seal header the on-prem sealer inserts.

Available to Defender for Office 365 Plan 1 or Plan 2 tenants (formerly Microsoft Defender for Office 365 P1/P2). E5 includes Plan 2 by default. After configuration, Exchange Online verifies the ARC seal on every inbound message; if the seal is valid AND the sealer is in the trusted list, the cloud re-evaluates DMARC using the verdicts the on-prem sealer recorded rather than its own (broken-by-relay) evaluation.

The portal-side equivalent: in the Microsoft 365 Defender portal (security.microsoft.com), navigate to Email & Collaboration > Policies & rules > Threat policies > Email authentication settings > ARC. Add the on-prem ARC-signing domain to the trusted-intermediaries list.

6.3 Verifying ARC across the relay

Send a test message from an external sender (a personal Gmail account works) to an on-prem-hosted mailbox in your hybrid org. After delivery, inspect the message source from Outlook or OWA. The headers should include:

• An Authentication-Results header written by on-prem Exchange showing the original SPF / DKIM / DMARC verdicts from the external sender.
• An ARC set (ARC-Seal, ARC-Message-Signature, ARC-Authentication-Results) inserted by the on-prem sealer, with d=<your-onprem-fqdn> and cv=none for the first hop.

Then send a test message from the same external sender to a CLOUD-hosted mailbox. The headers should additionally show that Exchange Online accepted the on-prem ARC seal and re-evaluated DMARC using the recorded verdicts - arc=pass in the cloud-side Authentication-Results header.

See the ARC (Authenticated Received Chain) explained pillar for the full protocol mechanics including ARC-Seal cv= chain validation, the i= instance numbering, and the recommended ARC signature scope.

7. Step 4: DMARC rollout in the hybrid context

With SPF, DKIM (one side, the other disabled), and ARC configured, the DMARC rollout itself follows the same five-phase pattern as cloud-only deployment - but takes 4-8 weeks at p=none instead of 2-6 weeks because more sender paths surface in aggregate reports.

7.1 Phase 1: Publish at p=none

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=none; rua=mailto:dmarc-reports@your-domain.com; fo=1"

Wait 24-48 hours for first reports to arrive. Never skip from p=none to p=reject - the intermediate p=quarantine phase is where you discover legitimate senders that are still misaligned, and the cost of jumping straight to reject is the loss of legitimate mail.

7.2 Phase 2: Inventory hybrid sender paths

For hybrid topology, the sender-path inventory has more distinct entries than cloud-only. Typical entries surfaced in the first 4 weeks of aggregate reports:

• Exchange Online direct: cloud mailbox users sending to external. Aligned if cloud-side DKIM is enabled for the custom domain.
• Exchange on-prem direct: on-prem mailbox users sending to external when on-prem is the outbound boundary. Aligned if on-prem-side DKIM is configured under the custom domain.
• On-prem to cloud relay (classic hybrid without CMT): on-prem mailbox user sends to external; mail traverses on-prem then cloud (or vice versa depending on Send Connector routing). Alignment depends on WHICH side signs.
• CMT relay (CMT enabled): on-prem mailbox user sends to external; mail relays through cloud regardless. Aligned via cloud DKIM.
• Application relay via on-prem: a CRM, ticketing system, or monitoring tool sends SMTP to on-prem Exchange as an anonymous relay client; on-prem relays externally. Alignment depends on whether the relay path signs DKIM for the custom domain (often it doesn't, surfacing as a high-volume DMARC failure pattern).
• SaaS senders: SendGrid, Mailgun, SES, Mailchimp, Salesforce Marketing Cloud, etc. Each sender path needs its own DKIM CNAME delegation - see the DMARC for SaaS senders sibling page.
• Edge Transport perimeter outbound: if Edge Transport is in use, the perimeter IPs appear as a distinct source. Alignment via whichever signer runs at the Edge Transport role.

Use DMARC Analyzer's dashboard to drill into each sender IP / sender domain combination. The per-reporter drill-down and per-source-IP drill-down views are the workhorses for hybrid inventory.

7.3 Phase 3: Advance to p=quarantine

After 4-8 weeks at p=none with every hybrid sender path inventoried and aligned (or quarantine-acceptable), advance:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=quarantine; rua=mailto:dmarc-reports@your-domain.com; fo=1"

Common pattern: a monthly cron job in an on-prem application relay surfaces only in the first month after quarantine enforcement. Watch reports closely for the first 30 days.

7.4 Phase 4: Advance to p=reject

After 1-3 months at p=quarantine without unexpected failures:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc-reports@your-domain.com; fo=1"

The DMARC policy rollout guide covers the Week 0 → Week 26 timeline in detail - the same pattern applies in hybrid with elongated intervals.

7.5 Subdomain policy in hybrid

Hybrid environments commonly have subdomains routed differently than the apex (a marketing subdomain at a SaaS sender, a transactional subdomain at another ESP, an internal-only subdomain at on-prem). Use the DMARC sp= tag to set the subdomain policy explicitly:

_dmarc.your-domain.com.   IN TXT  "v=DMARC1; p=reject; sp=reject; rua=mailto:dmarc-reports@your-domain.com; adkim=r; aspf=r; fo=1"

Without sp=, subdomain policy inherits the p= value. The DMARC alignment guide covers the organizational-domain / PSL boundary in detail.

8. Send Connector and Default Frontend Connector pitfalls

Exchange transport connectors are the plumbing of hybrid mail flow. Four specific connector misconfigurations cause the most common hybrid DMARC failures.

8.1 The Default Frontend Connector DKIM strip

The Default Frontend Connector on Exchange Online is the receive connector that accepts anonymous SMTP from on-prem Exchange in a hybrid topology. Older Exchange Online behaviour - and certain misconfigurations in current builds - cause this connector to STRIP existing DKIM-Signature headers from incoming messages, so when Exchange Online relays the message externally it re-signs under <tenant>.onmicrosoft.com and the on-prem DKIM signature is lost.

Symptom: every hybrid-relayed outbound message fails DMARC at external receivers because the visible From: domain (your-domain.com) has no aligning DKIM signature - the on-prem signature got stripped, and the cloud signature is under onmicrosoft.com.

Mitigation:

• Preserve SMTP headers explicitly:

  Connect-ExchangeOnline
  Get-InboundConnector | Where-Object ConnectorType -eq "OnPremises" | Format-List
  Set-InboundConnector -Identity "Inbound from your-onprem-exchange" -RequireTls $true
  # Note: PreserveSmtpHeaders is the parameter on the corresponding
  # inbound connector. Verify via Get-InboundConnector and adjust per
  # Microsoft's current Exchange Online PowerShell schema.

• Migrate to CMT: eliminates the problem by ensuring on-prem doesn't sign in the first place - cloud is the only signer and there's no stripping step.
• Use ARC sealing: even if the DKIM signature is stripped, the ARC chain preserves the original verdict so DMARC alignment can be reconstructed at the receiver. See section 6.

8.2 Send Connector relay loops

Occur when on-prem Send Connectors and cloud inbound connectors form a cycle. Symptom: NDR 5.4.6 Hop count exceeded after the message bounces between the two boundaries until Exchange transport detects the loop via Received-header count (default 20-30 in Exchange 2019; configurable via Set-TransportConfig).

Root causes:

• Manually created Send Connectors on on-prem that duplicate the HCW- generated connector pair.
• Accepted-domain DomainType set incorrectly: a domain marked Authoritative on BOTH sides causes each side to think it owns the domain and forward to the other.
• Inbound connector on Exchange Online routing based on hostname patterns that overlap with internal addressing.
• HCW interrupted mid-run leaving a partial connector configuration.

Prevention:

1. Accept the HCW-generated connector pair as-is. Do not manually create overlapping Send Connectors.
2. Confirm DomainType per accepted domain:

   Get-AcceptedDomain | Format-Table DomainName, DomainType, AddressBookEnabled

   Domains where the cloud is the canonical mailbox host should be Authoritative on the cloud side and InternalRelay on the on-prem side (or absent from on-prem accepted domains entirely).
3. Verify outbound mail exits cleanly with Get-MessageTrace on Exchange Online and Get-MessageTrackingLog on on-prem - a single sample message should show exactly one cloud hop before delivery to the external recipient.

8.3 TLS requirements on hybrid connectors

The HCW-configured Send Connector pair uses mutual TLS authentication via the on-prem Exchange certificate. If the on-prem certificate expires or the common name changes, the TLS handshake fails and mail flow halts. Symptom: 451 4.7.500 Server busy or 421 4.4.2 Connection dropped due to ConnectionReset in transport logs.

Prevention: monitor the on-prem certificate via Get-ExchangeCertificate and schedule renewals at least 60 days before expiry. Update the cloud-side inbound connector's TlsSenderCertificateName parameter if the certificate CN changes.

8.4 Anonymous SMTP relay through on-prem

Common in hybrid environments where legacy applications (printers, ticketing systems, CRM connectors, monitoring tools) authenticate as anonymous SMTP clients to on-prem Exchange and rely on on-prem to relay externally. The on-prem Receive Connector that accepts these clients usually has ExternalAuthoritative permission group granted, allowing relay without authentication.

DMARC implication: messages from anonymous relay clients arrive at on-prem WITHOUT pre-existing DKIM signatures. If on-prem is the outbound boundary AND on-prem signs DKIM, the messages get signed and pass DMARC. If on-prem doesn't sign (or if you're using cloud-only signing with CMT), the messages relay externally unsigned and fail DMARC.

Mitigation: identify every anonymous relay client (typical inventory: a few dozen items at a small enterprise, a few hundred at large) via Get-ReceiveConnector inspection and message-tracking logs. For each client, decide: (a) reconfigure to authenticate as a mailbox user and route through Exchange Online (cleanest for DMARC), (b) migrate to a SaaS sender via API integration, or (c) accept that on-prem signs all anonymous-relayed mail and configure DKIM signing on-prem.

9. Hybrid-specific gotchas

• Public folders on on-prem: if you still have public folders hosted on on-prem Exchange (a common long-tail in hybrid environments where modern Outlook public-folder migration to cloud has not completed), they generate outbound mail when configured for email delivery. Public-folder mail flows through the same Send Connectors as regular mailbox mail - if the on-prem outbound path doesn't sign DKIM, public-folder outbound fails DMARC.
• Microsoft 365 Direct Send: a feature that lets applications send SMTP directly to your-domain-com.mail.protection.outlook.com from any internet IP without authentication, as long as the recipient domain is hosted in the same tenant. Common in hybrid for scanner-to-email and other appliance outbound. Direct Send bypasses cloud-side DKIM signing - messages leave the cloud unsigned. If you rely on Direct Send for any sender path, those messages must either be routed through an alternate authenticated path or accepted as DMARC failures.
• SMTP AUTH submission via the cloud: applications that authenticate as a mailbox user and submit via Office 365 SMTP AUTH (smtp.office365.com:587 with TLS) get the same cloud-side DKIM signing as Outlook clients - no special configuration needed. Prefer this over Direct Send and anonymous on-prem relay for new application deployments.
• Mailbox migration during DMARC rollout: moving a batch of mailboxes from on-prem to cloud (or vice versa) changes the outbound path of every message those users send. If you're in the middle of DMARC rollout, plan the migration so the moved mailboxes all use the SAME side's DKIM signing as before - otherwise DMARC reports show a spike of alignment failures from the moved batch on day one of the move.
• The on-prem Authentication-Results header domain: on-prem Exchange writes its own Authentication-Results header tagged with the on-prem FQDN, not the public domain. If the ARC sealer reads this header to capture original verdicts, ensure the FQDN it expects matches the on-prem Exchange Authentication- Results identifier (configurable via Set-TransportConfig -Identity parameters).
• Defender for Office 365 license dependency: the Trusted ARC Sealers feature requires Defender for Office 365 Plan 1 or Plan 2 (formerly known as Microsoft Defender for Office 365 P1/P2). E5 includes Plan 2 by default. Without Defender, ARC sealing on the on-prem side is wasted - the cloud will not trust the seal.
• HCW re-run side effects: re-running the Hybrid Configuration Wizard regenerates the Send Connector pair and may revert manual customisations made via Set-SendConnector. If you've customised connectors post-HCW, document the changes so you can re-apply them after each HCW run.
• Exchange 2013 end-of-life: Exchange 2013 reached end-of-support in April 2023 and cannot host a modern hybrid topology - Microsoft removed support for HCW against Exchange 2013 in late 2023. If your on-prem Exchange is still 2013, the hybrid topology is unsupportable and you must either migrate fully to Exchange Online or upgrade on-prem to Exchange 2016 or 2019 first.

10. Common hybrid + DMARC mistakes

1. Both sides sign under the same custom domain: the dual-signer problem documented in section 5.3. Receivers iterate non-deterministically across the two signatures and DMARC pass/fail becomes a coin flip. Fix: pick ONE side and disable signing on the other.
2. Forgetting to add the on-prem outbound NAT range to SPF: classic hybrid where SPF lists only include:spf.protection.outlook.com but on-prem also delivers outbound directly. Outbound mail from on-prem fails SPF at external receivers (the connecting IP is your on-prem perimeter NAT pool, which is not in spf.protection.outlook.com). Fix: add the on-prem range via ip4: or migrate to CMT.
3. Exceeding the SPF 10-DNS-lookup limit: hybrid environments that also use multiple SaaS senders quickly hit the limit. Symptom: SPF returns permerror and DMARC fails. Fix: migrate to CMT to drop on-prem from SPF, consolidate senders, or delegate high-volume senders to subdomains.
4. Not configuring Trusted ARC Sealers when on-prem signs ARC: the on-prem ARC seal gets inserted but Exchange Online does not trust the sealer, so the seal is effectively ignored. Spoofed mail forwarded from on-prem to cloud still gets the wrong disposition. Fix: run Set-ArcConfig -ArcTrustedSealers <your-onprem-fqdn> on the cloud side.
5. Setting DomainType to Authoritative on BOTH sides: causes Send Connector relay loops (NDR 5.4.6). Fix: exactly one side is Authoritative; the other is InternalRelay or absent from accepted domains.
6. Trusting MX changes to propagate instantly: hybrid migrations often involve changing the MX record from on-prem to cloud. DNS propagation can take 24-48 hours per recursive resolver TTL. During the window, mail arrives at BOTH MX targets. If you decommission the old target before propagation completes, the inbound mail to the old target is bounced.
7. Anonymous SMTP relay clients that the operator forgot about: a legacy application from 2015 still relays through on-prem Exchange anonymously and nobody remembers it exists. Found only in DMARC aggregate reports when the cloud-only DKIM enforcement breaks it. Fix: inventory before rolling out DMARC enforcement; use the per-reporter drill-down in the DMARC Analyzer dashboard to find them.
8. Skipping p=quarantine: the keystone safety guardrail. Never skip from p=none to p=reject. Hybrid environments have more sender paths than cloud-only and skipping quarantine guarantees operational pain.
9. Trusting CMT to migrate seamlessly: enabling CMT immediately changes outbound routing for every on-prem mailbox. SPF must already be configured for cloud-only outbound BEFORE you enable CMT, otherwise outbound mail bypasses on-prem's already-authorised IP set and starts failing SPF (cloud is in SPF via the include, so this is usually fine - but verify with a test message before the cutover).
10. Defender for Office 365 anti-spoof policy collisions: Defender's "spoof intelligence" feature flags messages that fail DMARC implicitly even before your DMARC policy reaches p=reject. If a legitimate sender path is misaligned but flagged by spoof intelligence, the message gets quarantined even under your p=none DMARC. Tune via the Defender portal anti-spoof policy.

11. Migration paths: from classic hybrid to cloud-only

Most hybrid Exchange deployments evolve toward fully-cloud-routed mail flow (Exchange Online as the single outbound boundary, on-prem retained only for legacy components like public folders, journaling, or geographic compliance). The recommended migration sequence minimises operational risk by moving in discrete, reversible phases.

11.1 Phase A: Classic hybrid (baseline)

The starting state. Mail flow is split between on-prem and cloud. Both sides can deliver outbound directly. DKIM signing happens on whichever side handles a given message. ARC sealing preserves verdicts across the on-prem-to-cloud relay.

Operational focus: get DMARC to p=quarantine at minimum, inventory every sender path, document every anonymous relay client.

11.2 Phase B: Centralized Mail Transport (CMT)

Enable CMT to route all outbound through Exchange Online while keeping on-prem mailboxes operational. After CMT:

• SPF simplifies to include:spf.protection.outlook.com only (no on-prem ip4: ranges).
• DKIM signing happens on the cloud side only. Disable any on-prem DKIM transport agent.
• ARC sealing for outbound becomes optional - the on-prem-to-cloud relay is inside the trust boundary.
• The dual-signer problem is eliminated by construction.

Configuration:

Connect-ExchangeOnline
Set-HybridConfiguration -CentralizedTransportEnabled $true
Get-HybridConfiguration | Format-List Features

Trade-off: every outbound message round-trips through the cloud regardless of recipient location. Bandwidth and latency increase. For most enterprises this is invisible; for high-volume on-prem-to-on-prem inter-organisation flows it can be a measurable cost.

11.3 Phase C: Migrate remaining mailboxes to cloud

With CMT handling outbound routing, the on-prem mailboxes themselves are the next migration target. Use New- MoveRequest, batch moves via the Exchange Online Migration UI, or third-party migration tools (Quest, BitTitan, CodeTwo) to move mailboxes in batches. DMARC implications: minimal, because CMT already routes outbound through cloud regardless of where the mailbox lives.

11.4 Phase D: Decommission on-prem Exchange

The endgame. With all mailboxes migrated, on-prem Exchange becomes a candidate for decommission. Tasks:

1. Migrate any remaining public folders to cloud (or to a SharePoint / Teams equivalent).
2. Retire on-prem journaling - replace with Microsoft Purview compliance features or a third-party compliance archive.
3. Reconfigure every anonymous SMTP relay client to authenticate to Exchange Online via SMTP AUTH or migrate to a SaaS sender.
4. Run the Hybrid Configuration Wizard one last time in "remove hybrid configuration" mode to deconfigure the connector pair and federation trust.
5. Update MX records to point only at your-domain-com.mail.protection.outlook.com. Remove the on-prem MX.
6. Simplify SPF to remove on-prem ip4: ranges (already done in CMT phase but re-verify).
7. Decommission on-prem Exchange servers per Microsoft's documented decommission procedure.

11.5 Phase E: Long-term hybrid (when on-prem stays)

Some organisations have hard requirements to keep on-prem Exchange indefinitely: regulatory compliance requiring on-prem mail flow for certain domains, geographic data-sovereignty constraints (jurisdictions where Microsoft 365 is not available), or operational integration with legacy systems that only speak on-prem Exchange APIs. For these organisations, the CMT topology is the recommended long-term steady state - it gives the operational simplicity of cloud-only DMARC while keeping on-prem Exchange operational.

12. Troubleshooting hybrid DMARC failures

12.1 Identifying which side a message left from

The fastest hybrid debugging step: determine WHICH side of hybrid a failing message left through. Inspect the source-IP column in the DMARC aggregate report (or the per-source-IP drill-down in DMARC Analyzer):

• If the source IP is in Microsoft's outbound range (resolves under protection.outlook.com rDNS or matches the IPs in spf.protection.outlook.com): the message left through Exchange Online.
• If the source IP is your on-prem perimeter NAT pool: the message left through on-prem Exchange.
• If the source IP is a SaaS sender (SendGrid, Mailgun, etc.): the message was sent by a SaaS integration, not through your hybrid Exchange topology.

12.2 SPF failing for one side

Symptom: aggregate reports show SPF pass for cloud-source messages but SPF fail for on-prem-source messages (or vice versa). Cause: SPF record lists only one side's IPs. Fix: add the missing IP set or migrate to CMT.

12.3 DKIM failing for one side

Symptom: aggregate reports show DKIM pass for cloud-source messages but DKIM fail for on-prem-source messages. Cause: cloud signs DKIM but on-prem does not. Fix: configure on-prem DKIM signing OR migrate to CMT so on-prem doesn't deliver outbound directly OR accept that on-prem-source messages rely on SPF-only alignment (DMARC passes if SPF passes and aligns).

12.4 ARC seal not trusted by cloud

Symptom: on-prem ARC sealer inserts the ARC set but Exchange Online still re-evaluates DMARC using its own (broken-by-relay) verdicts. Cause: the on-prem ARC-signing domain is not in the cloud's trusted-sealers list. Fix:

Connect-ExchangeOnline
Get-ArcConfig | Format-List ArcTrustedSealers
Set-ArcConfig -ArcTrustedSealers <your-onprem-fqdn>

12.5 NDR 5.4.6 (hop count exceeded)

Send Connector relay loop. Causes and fixes documented in section 8.2. Quick diagnostic:

Get-MessageTrace -SenderAddress test@your-domain.com -StartDate (Get-Date).AddHours(-1) -EndDate (Get-Date)
# On the on-prem side:
Get-MessageTrackingLog -Sender test@your-domain.com -Start (Get-Date).AddHours(-1) -End (Get-Date) | Format-Table Timestamp, Sender, Recipients, EventId

Trace a sample message and confirm it exits to the external receiver after exactly ONE cloud hop. Multiple cloud hops = configuration drift.

12.6 Direct Send messages bypassing DKIM

Symptom: a subset of messages from your domain consistently fail DMARC at external receivers, the source-IP is NOT your hybrid Exchange topology, and the user-agent or application name suggests an appliance (multifunction printer, scanner, monitoring tool). Cause: the appliance is using M365 Direct Send (smtp to your-domain-com.mail.protection.outlook.com) which bypasses tenant-side DKIM signing. Fix: reconfigure the appliance to authenticate via SMTP AUTH to smtp.office365.com:587 using a service-account mailbox - this routes the message through the cloud-DKIM-signing path. Alternative: relay through on-prem Exchange (if on-prem signs) or through a SaaS transactional sender configured for your domain.

12.7 Using DMARC Analyzer for hybrid troubleshooting

The DMARC Analyzer dashboard surfaces every sender IP / sender domain combination present in your aggregate reports. For hybrid troubleshooting, the key views are:

• Source IP drill-down: per-IP breakdown showing which IPs are cloud, which are on-prem, and which are SaaS senders. Filter for DMARC failures to surface misaligned senders.
• Reporter drill-down: per-receiver breakdown. Google and Microsoft each report on different aggregate cadences and report coverage; the reporter view helps separate "my domain doesn't send to this receiver" from "this receiver isn't sending reports".
• Per-report records view: drill into a single report file to see message-level disposition, alignment, and Authentication- Results data. The richest data for diagnosing a specific failure pattern.
• Email Header Analyzer: paste the full headers of a failing message and see the SPF, DKIM, DMARC, and ARC verdict breakdown. Use this when a user forwards a "this should have worked" example.

13. Frequently asked questions

How do I set up DMARC on a hybrid Exchange topology?

Four steps. (1) Choose ONE outbound boundary. The cleanest hybrid DMARC story has Exchange Online as the single outbound boundary via Centralized Mail Transport (CMT) - on-prem servers relay through the cloud, the cloud signs DKIM under your custom domain, and DMARC alignment is unambiguous. (2) Publish SPF with include:spf.protection.outlook.com PLUS your on-prem outbound IP set if on-prem still delivers directly. Stay under the 10-DNS-lookup limit. (3) Configure DKIM signing on whichever side is the outbound boundary. If CMT, only Exchange Online signs. If classic hybrid with on-prem outbound, install an on-prem DKIM signer and publish ARC seals. (4) Publish DMARC at p=none and advance through p=quarantine to p=reject over 4-8 weeks.

What is Centralized Mail Transport in a hybrid Exchange topology?

Centralized Mail Transport (CMT) is a Microsoft 365 feature that routes outbound mail from on-prem Exchange THROUGH Exchange Online before external delivery. From a DMARC alignment perspective, CMT is the most operator-friendly hybrid topology: only Exchange Online needs to DKIM-sign mail, only Exchange Online needs to be in SPF, and the relay leg from on-prem to cloud happens inside the trusted boundary so ARC sealing across that hop is optional. Enable via Set-HybridConfiguration -CentralizedTransportEnabled $true.

What is the dual-signer DKIM problem in hybrid Exchange?

Occurs when BOTH Exchange on-prem and Exchange Online attempt to DKIM-sign a single outbound message - typically under different d= domains - causing DMARC alignment ambiguity at the receiver. Most common manifestation: on-prem has an Exclaimer / GFI / Zix DKIM transport agent signing under d=your-domain.com, the message relays to Exchange Online which ALSO signs under d=<tenant>.onmicrosoft.com. Receivers iterate non-deterministically across signatures. Fix: choose ONE signing side and disable the other.

How does ARC sealing work in a hybrid Exchange relay?

ARC (RFC 8617) lets each hop along the mail relay record the SPF / DKIM / DMARC verdicts it observed and cryptographically seal them so the final receiver can reconstruct the original verdicts even after intermediate header modifications. In hybrid: on-prem evaluates an inbound external message, captures verdicts, relays to Exchange Online with an ARC seal. Exchange Online verifies the seal, trusts on-prem as a configured intermediary via Defender Trusted ARC Sealers (Set-ArcConfig -ArcTrustedSealers), and applies disposition based on the recorded verdicts.

What is the Default Frontend Connector DKIM strip problem?

Older Exchange Online behaviour - and certain misconfigurations - cause the Default Frontend Connector that accepts on-prem SMTP to STRIP existing DKIM-Signature headers before transport, so when Exchange Online relays the message externally it re-signs under <tenant>.onmicrosoft.com and the operator's on-prem DKIM signature is lost. Mitigation: configure PreserveSmtpHeaders on the matching inbound connector, migrate to CMT (so on-prem never signs), or use ARC sealing to preserve the original DKIM verdict independently of header survival.

How do I avoid Send Connector relay loops in hybrid Exchange?

Occur when on-prem Send Connectors and cloud inbound connectors form a cycle. Symptom: NDR 5.4.6 "Hop count exceeded". Prevention: accept the HCW-generated connector pair as-is, set accepted-domain DomainType correctly (Authoritative on the canonical side, InternalRelay on the other), verify with Get-MessageTrace that a sampled outbound message exits cleanly after exactly one cloud hop, and monitor Defender portal Mail Flow > Message Trace for unexpected repeated hops.

Should I keep on-prem Exchange or move fully to Exchange Online for DMARC?

From a DMARC simplicity perspective, fully cloud-routed mail flow is unambiguously preferable: single DKIM signing side, single SPF include, uniform Defender anti-phishing application. That said, fully eliminating on-prem Exchange is a multi-quarter project. Reasons to keep hybrid include public-folder migration not yet complete, on-prem journaling for legal hold, compliance frameworks requiring on-prem mail flow, or geographic data-sovereignty constraints. If you must keep hybrid, the recommended target is Centralized Mail Transport (CMT).

What does the Hybrid Configuration Wizard configure for DMARC?

HCW configures the bidirectional Send Connector / Receive Connector pair, the inbound connector on Exchange Online that recognises mail from your on-prem org as trusted, and accepted-domain registration on both sides. HCW does NOT configure DKIM signing (run Set-DkimSigningConfig manually), DMARC TXT records, on-prem ARC sealing, or Trusted ARC Sealers on the cloud side. The HCW configures the plumbing; DMARC alignment requires post-HCW work.

14. Related guides

• DMARC for Microsoft 365 - the cloud-only sibling deployment guide. Read this FIRST if your outbound mail flow is entirely through Exchange Online with no on-prem Exchange component. The hybrid page assumes familiarity with the cloud-only mechanics (selector1 / selector2 CNAME delegation, Defender portal UI paths, Set-DkimSigningConfig).
• DMARC for Google Workspace - the alternative mailbox-provider deployment guide. Compare the Workspace TXT-publication DKIM model with the M365 CNAME-delegation model when evaluating cloud platforms.
• BIMI SVG Tiny PS asset-format requirements — the HYBRID-EXCHANGE-DUAL-EGRESS-PATH- BIMI-SVG-ASSET-PUBLICATION-CONSUMER companion to this hybrid Exchange deployment reference. Where THIS page documents the hybrid Exchange dual- egress-path DMARC posture (the on-prem Exchange + Exchange Online dual-signer DKIM model, the CMT-vs-classic-hybrid outbound-boundary decision, the ARC- sealer Trusted-ARC-Sealers boundary, the Default Frontend Connector DKIM- strip and Send-Connector relay-loop failure modes), the BIMI-SVG-Tiny-PS- requirements spoke is the BIMI-ASSET- FORMAT-BYTE-LEVEL-SPECIFICATION companion documenting WHAT the hybrid Exchange tenant operator must actually publish at the BIMI l=-tag URL once the hybrid Exchange DMARC posture this page establishes meets BIMI's display eligibility precondition. Concretely, the spoke documents FOUR hybrid- Exchange-BIMI-SVG-asset-coordination dimensions: (i) BIMI SVG asset publication is downstream of the hybrid Exchange dual-egress DMARC posture this page establishes — the BIMI-eligibility evaluator at receiver-side Outlook / Gmail / Yahoo only fetches the published SVG asset AFTER the per-message DMARC verdict is pass-with-Friendly-From-header- alignment AND the publisher's per- author-domain 90-day rolling DMARC- pass-rate exceeds receiver-internal eligibility thresholds — both gating conditions are themselves downstream consumers of the hybrid Exchange dual-egress posture this page coordinates (any path that breaks alignment also breaks BIMI display for THAT path's mail); (ii) BIMI SVG-Tiny-PS asset format is the same byte-level contract regardless of which hybrid egress path produced the underlying DMARC-aligned mail — the SVG must satisfy baseProfile="tiny-ps", square viewBox with 1:1 aspect ratio, no scripts / animation / external resources, RGB- only color (no CMYK / no ICC color profiles), 32KB ceiling, and base64- encoded for inline embedding — format failures (PNG instead of SVG, rectangular viewBox, embedded scripts, external href URLs, oversized binary) produce identical BIMI-display-loss outcomes whether the underlying mail emerged from on-prem Exchange or Exchange Online egress; (iii) hybrid Exchange tenants publish ONE BIMI SVG at default._bimi.<d-domain> regardless of dual-egress topology — the BIMI TXT record is published at the Friendly-From-header organisational domain's _bimi subdomain with v=BIMI1; l=<svg-url>; a=<vmc-url>, a single asset-publication surface that serves BIMI display for ALL hybrid-emitted mail under the same Friendly-From-domain — operators running classic-hybrid (dual-egress with on-prem + cloud both emitting) do NOT publish a second BIMI record for the on-prem-emitted cohort, the single BIMI-published SVG asset applies to all dual-egress mail that reaches DMARC-pass with alignment; and (iv) VMC certificate validity precondition is layered on top of the SVG-Tiny-PS format requirements — the a=<vmc-url> tag in the BIMI record points to a Verified Mark Certificate issued against the published SVG (per RFC 9788), 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 but in conjunction with the SVG- Tiny-PS format-conformance check the spoke documents, and BOTH must succeed for receiver-side BIMI display. Read the BIMI-SVG-Tiny-PS-requirements spoke alongside this hybrid Exchange deployment reference when the hybrid tenant operator advances past terminal p=reject and is ready to deploy BIMI for the protected domain — the dual-egress hybrid DMARC posture is the gating precondition the BIMI SVG asset publication consumes.
• DMARC policy modes (p=none / p=quarantine / p=reject) - the PER-PHASE-ENFORCEMENT-TIER- SELECTION companion to this hybrid Exchange deployment reference. Where THIS page documents the dual-egress topology coordination at the complete authentication- stack level (DKIM dual-signing, SPF dual- include-cascade, ARC sealing on the on-prem- to-cloud relay leg), the DMARC-policy-modes spoke is the PER-PHASE POLICY-TAG SELECTION REFERENCE documenting the four-phase phased- enforcement-ramp every hybrid tenant MUST follow at cutover. The HYBRID-DEPLOYMENT-PHASE- VS-POLICY-TAG-SELECTION cross-reference establishes FOUR structurally-distinct hybrid- topology cutover stages each binding a specific RFC 7489 §6.3 policy-tag choice: (i) Phase 1 Discovery (p=none; pct=100; no sp= override) — the observation-only baseline phase during the FIRST 2–6 weeks of hybrid cutover when the operator is still inventorying the dual- egress legitimate-sender population (which applications and which on-prem MX hosts are authorised to egress through which path); the DMARC-policy-modes spoke documents the p=none contract that receivers report-without-acting against the aggregate- report feed surfacing both the EOP cloud- egress IP pool AND the on-prem Edge Transport outbound IPs whose authorisation gaps the hybrid operator must close in Phase 1 BEFORE ramping to soft-quarantine; (ii) Phase 2 Triage with p=quarantine + pct=10 percentage-ramp — the FIRST enforcement tier where receivers DO act (soft-quarantine to spam folder) but the pct= percentage-applicability sampling tag (RFC 7489 §6.3) constrains the receiver-side action to a 10% / 25% / 50% / 75% sample as the hybrid operator progressively closes the dual-egress authorisation gaps; the DMARC-policy-modes spoke documents the pct= sampling algorithm receivers apply during this phase and the per-percentage exit-criteria gate (DMARC-fail rate below per-percentage floor before advancing to the next ramp tier); (iii) Phase 3 Soft-Enforcement with p=quarantine + pct=100 full-sample steady-state — the FINAL soft-quarantine tier where 100% of receiver evaluations apply the soft-quarantine action and the hybrid operator's aggregate-report feed transitions from a "broken-flow discovery" phase to a "steady-state legitimate- flow regression-detection" phase; the DMARC- policy-modes spoke documents the p=quarantine exit-criteria gate (sustained DMARC-pass rate above the per- deployment floor for 14+ consecutive days before advancing to p=reject); (iv) Phase 4 Hard-Enforcement with p=reject + pct=100 + optional sp=reject subdomain- policy override — the FINAL hard- enforcement tier where receivers reject DMARC-fail messages at SMTP 5xx response time and the hybrid operator's dual-egress topology has graduated to the canonical post-deployment steady state; the DMARC- policy-modes spoke documents the p=reject + sp=reject coordination (mandatory for both apex and all sibling subdomains to defeat the attacker-bypass class of cousin-subdomain spoof attacks the hybrid tenant's broader Exchange Online surface inherently exposes). Pair this page (the hybrid Exchange deployment coordination reference) with the DMARC-policy- modes spoke (the per-phase policy-tag selection reference) when authoring the four-phase cutover runbook for a new hybrid tenant — the spoke documents the per-phase exit-criteria gates and the pct= / sp= coordination the hybrid operator MUST sequence correctly to avoid prematurely advancing to a stricter tier before the dual-egress authorisation coverage gates close.
• ARC (Authenticated Received Chain) explained - RFC 8617: the protocol behind Defender Trusted ARC Sealers and on-prem ARC sealing for the on-prem-to-cloud relay leg. Essential reading for any hybrid operator.
• SPF forwarding issues - the INTERNAL-RELAY-ENVELOPE-REWRITING- SPF-BREAKAGE companion to this hybrid Exchange deployment reference. Where THIS page documents the dual-egress topology (on-prem Edge Transport + Exchange Online Protection) and the dual-signing DKIM coordination problem, the SPF forwarding- issues spoke documents the FOUR canonical SPF-break scenarios that surface specifically in hybrid topologies: (i) the on-prem-to-cloud-to-external hairpin — a mailbox-rule auto-forward configured on a user's on-prem mailbox to an external recipient causes the on-prem Mailbox server to re-inject the original sender's RFC 5322 message into Exchange Online for outbound delivery, but the Exchange Online egress IP is NOT authorised in the original sender's SPF record (the original sender's record only authorises THEIR domain's outbound IPs), instantly producing a 5321.MailFrom SPF-fail on the external receiver (Gmail, Outlook.com, Yahoo Mail, iCloud) that surfaces in the original sender's aggregate-report feed as an "unaligned external IP" anomaly the operator did not expect, (ii) the Exchange Online send- connector-to-on-prem-smart-host-to- external hairpin — outbound mail from a cloud mailbox routed through a Send Connector targeting an on-prem smart host (a common pattern for application-driven mail that must traverse a DLP gateway or message- archiving appliance) then re-injected from the on-prem path to an external recipient, breaking SPF on the second- hop egress IP, (iii) the user- rule-driven auto-forward proliferation problem — Exchange Online inbox rules and on-prem mailbox-rule auto-forwarders are user-configurable and propagate quietly without operator oversight (the Defender portal's forwarding-report dashboard exists specifically for the operator to inventory the auto-forward surface), each configured rule a potential SPF- breakage source on a per-message basis, and (iv) the distribution-list expansion problem inside hybrid topologies — distribution-list groups in Exchange Online or on-prem AD rewrite envelope senders on outbound member fan-out, and when the list's bounce-handling address is in a sibling domain or subdomain different from the original sender's domain, the SPF authorisation check fires against the wrong policy. The forwarding-issues spoke documents the THREE canonical hybrid-applicable mitigations: SRS envelope-rewriting at the on-prem Edge Transport / forwarding boundary (RFC 5321 envelope-rewriting that swaps the original 5321.MailFrom for a hybrid- operator-authorised return-path), ARC sealing on the on-prem-to-cloud relay leg (the Defender Trusted ARC Sealer mechanism the hybrid topology REQUIRES for cross-tier authentication-result chain-of-custody preservation), and rule-surface auditing via the Defender portal's mail-flow rules + the on-prem Get-InboxRule cmdlet to inventory and prune the auto-forward attack surface. Read the SPF forwarding-issues spoke when the hybrid topology's aggregate- report feed surfaces SPF-fail rows attributable to forwarding paths the original sender's published SPF record does not (and CAN NOT) authorise.
• Email authentication overview - the cluster-intro pillar. SPF / DKIM / DMARC / BIMI / MTA-STS / TLS-RPT / CAA / ARC at the standards-overview level.
• Help center hub - the DMARC primer.
• SPF explained - the 10-DNS-lookup limit (RFC 7208 §4.6.4) is the load-bearing constraint for hybrid SPF construction. Read for include / ip4 / nested-include mechanics.
• SPF DNS TXT-record byte syntax (RFC 7208 §3 tag-list grammar) — the HYBRID-TOPOLOGY-DUAL-EGRESS-APEX-SPF- RECORD-BYTE-LEVEL-AUTHORING-DISCIPLINE companion to this hybrid Exchange deployment reference. Where THIS page documents the DUAL-EGRESS-TOPOLOGY COORDINATION at the complete authentication-stack level (Exchange Online Protection cloud-egress path PLUS the on-prem Edge Transport server egress path, each requiring per-path SPF authorisation at the same apex SPF record), the SPF DNS syntax reference documents the BYTE-LEVEL HOW the hybrid tenant's authoritative DNS publication must satisfy for both egress paths' outbound IPs to evaluate to spf=pass: (i) the canonical v=spf1 version-prefix that distinguishes the SPF TXT record from arbitrary TXT records; (ii) the byte-correct co-publication of the Microsoft-managed include:spf.protection.outlook.com token alongside the operator-managed ip4:<CIDR> literals for the on-prem Edge Transport server outbound IPs, with byte-correct spacing and ordering that every receiver-side SPF parser tolerates; (iii) the 255-octet per-character-string chunking rule that determines how the hybrid tenant authors a multi-string SPF record when the cumulative byte-length of the EOP include + on-prem ip4 literals + any parallel SaaS sender includes exceeds a single TXT character-string — a recurring authoring scenario for enterprise hybrid tenants with both substantial on-prem IP footprints and active parallel SaaS sender portfolios; (iv) the one-SPF-record-per- domain constraint per RFC 7208 §3.2 whose violation (publishing one SPF record for the M365 tenant and a second SPF record for the on-prem deployment separately) produces spf=permerror across every receiver evaluating the hybrid tenant's From: authentication — a canonical hybrid- topology defect class introduced when the on-prem and cloud DNS-management responsibilities sit with different operational teams; and (v) the canonical -all versus ~all tail-mechanism choice (RFC 7208 §4.6.2) that determines per-receiver enforcement during the hybrid cutover when legitimate mail can still egress via either the on-prem MX or the Exchange Online Protection relay — the conservative ~all SoftFail posture is the canonical mid-cutover choice; the -all Fail posture is the post-cutover steady-state. Read this WITH the hybrid Exchange deployment reference when the dual-egress apex SPF record authoring step moves to the operator's queue: the hybrid page documents the DUAL-PATH AUTHORISATION DESIGN, the SPF DNS syntax reference documents the BYTE- LEVEL HOW to publish that design at the tenant's authoritative DNS without collapsing the apex SPF record to spf=permerror.
• SPF mechanisms explained — the HYBRID-TOPOLOGY-DUAL-EGRESS-PER- MECHANISM-AUTHORISATION-CASCADE- CONSTRUCTION companion to this hybrid Exchange deployment reference. Where THIS page documents the dual-egress topology coordination at the complete authentication- stack level, the SPF-mechanisms-explained spoke is the PER-MECHANISM BYTE-GRAMMAR REFERENCE documenting how each of the eight RFC 7208 §5 mechanism primitives contributes to the hybrid tenant's apex SPF record construction. The HYBRID-DUAL- EGRESS-PER-MECHANISM-CASCADE cross- reference establishes FIVE structurally- distinct per-mechanism hybrid-tenant deployment patterns: (i) EOP cloud-egress via include:spf. protection.outlook.com — the canonical Microsoft-managed include token recursively expands into the spf-a.outlook.com / spf-b.outlook.com sub-include chain consuming ~3–5 of the 10-DNS-lookup budget per RFC 7208 §4.6.4; the SPF- mechanisms spoke documents the include: mechanism's per- token DNS-lookup cost the hybrid tenant must budget around when adding on-prem authorisation; (ii) on-prem Edge Transport authorisation via ip4: <public-ipv4-block> / ip6:<public-ipv6-block> literals — the SAFEST mechanism category per RFC 7208 §5.6 (deterministic, zero DNS lookup, zero void-lookup risk); the SPF-mechanisms spoke documents the per-mechanism budget contribution (zero) and the canonical literal-IP byte-format the hybrid tenant publishes alongside the EOP include token; (iii) on- prem MX-host authorisation via mx: mechanism — RFC 7208 §5.4 dynamic-resolution mechanism resolves to the on-prem Exchange-side MX RRs at evaluation time; the SPF-mechanisms spoke documents the per-MX-host A-record sub-resolution that adds up to 10 additional DNS lookups (per MX) AGAINST the 10-budget — hybrid tenants with multiple on-prem MX hosts MUST avoid the mx: mechanism and use ip4: literals instead; (iv) deprecated ptr: mechanism on legacy on-prem deployments — the SPF- mechanisms spoke documents the RFC 7208 §5.5 deprecation status; hybrid tenants migrating from a pre-2014 on-prem-only SPF record may have inherited a ptr: mechanism whose receiver-side DNS-lookup-budget cost (~5 of 10) consumes nearly the entire budget BEFORE the EOP include token even starts evaluating; (v) terminating all qualifier coordination during the hybrid cutover — the SPF-mechanisms spoke documents the four qualifier prefixes whose choice (+all permissive, -all strict fail, ~all soft fail, ?all neutral) determines receiver enforcement behaviour during the hybrid migration when legitimate mail can still egress via either path the apex SPF record authorises. Pair this page (the hybrid Exchange deployment coordination reference) with the SPF-mechanisms spoke (the per-mechanism byte-grammar reference) when authoring the apex SPF record for a new hybrid tenant cutover — the spoke documents the per-mechanism budget contribution and byte-format every hybrid-tenant operator must internalise before publishing the dual-egress authorisation cascade.
• SPF for Microsoft 365 - the HYBRID-TOPOLOGY-DUAL-EGRESS-SPF- AUTHORISATION-COORDINATION companion to this hybrid Exchange deployment reference. Where THIS page documents the dual-egress topology (on-prem Edge Transport + Exchange Online Protection) at the complete SPF + DKIM + DMARC + ARC + PTR coordination level, the SPF-for-Microsoft- 365 spoke documents the WORKSPACE-PARALLEL M365 SPF-DEPLOYMENT SURFACE specifically: (i) the canonical M365 apex SPF record — v=spf1 include:spf.protection.outlook.com -all — the cloud-only baseline that publishes ALL Exchange Online Protection egress IPs via Microsoft's managed include token, consuming ~3–5 DNS lookups via the recursive spf-a.outlook.com / spf-b.outlook.com sub-include chain that EOP unfolds at receiver evaluation time (leaving ~5–7 lookups of headroom — substantially more than Workspace's include:_spf.google.com chain), (ii) the HYBRID-SPECIFIC coordination requirement — a hybrid topology's apex SPF record MUST authorise BOTH the cloud-path Exchange Online egress IPs (covered by the standard include:spf.protection.outlook.com token) AND the on-prem Edge Transport / Mailbox server outbound IPs (covered by operator-managed ip4: CIDR literals for the on-prem perimeter IPs, or by an operator-controlled secondary include: token published under a control-plane subdomain), and getting the dual-coverage right is the single most common HYBRID-SPECIFIC SPF deployment failure (the on-prem path's SPF-fail surfaces in the aggregate-report feed as an "unaligned on-prem egress IP" anomaly until the operator extends the published record to include the missing on-prem IPs), (iii) the -all hard-fail tail decision — M365 hybrid deployments commonly publish -all (hard fail) where Workspace deployments publish ~all (soft fail); the hybrid topology's PTR / DKIM / ARC coordination discipline this page documents makes the hard-fail tail strictly safer for hybrid than for cloud-only Workspace, but operators migrating from a cloud-only M365 posture to a hybrid posture must re-audit the tail-qualifier choice before extending the record, and (iv) the partner-relay / Connector coordination surface — Exchange Online's Inbound and Outbound Connectors (the partner-relay paths this page documents) introduce per-Connector SPF coordination surfaces where the partner's egress IPs may need to be added to the operator's apex SPF record (or to a delegated subdomain SPF record) to align SPF for any partner-relayed mail that re-egresses through the operator's domain identifiers. Read the SPF-for- Microsoft-365 spoke when this hybrid deployment page's SPF section narrows the SPF-coordination decision to "publish the canonical M365 include token + the on-prem path's IP coverage" — the spoke is the authoritative Microsoft-365-tenant-side reference for the include-token expansion + the on-prem-IP-coverage decision the hybrid topology requires.
• Reverse DNS / PTR / FCrDNS - the HYBRID-TOPOLOGY-DUAL-EGRESS-DUAL- PTR-PUBLICATION-OPERATOR-DISCIPLINE companion to this hybrid Exchange deployment reference. Where THIS page documents the dual-transport-path Exchange-on-prem + Exchange-Online topology where mail egresses via TWO distinct MTA paths (the on-prem Edge Transport / Mailbox servers AND the Exchange Online Protection relay), the reverse-DNS / PTR / FCrDNS spoke documents the IP-ROUTING-LAYER sender- legitimacy DNS-record DISCIPLINE the hybrid topology requires on the ON-PREM path specifically: (i) Exchange Online egress IPs publish FCrDNS-passing PTR records under Microsoft-managed *.outbound.protection.outlook.com zones — the M365 tenant operator does NOT control these PTR records (they are managed by Microsoft's EOP infrastructure and uniformly pass FCrDNS at every major receiver), (ii) on-prem Edge Transport / Mailbox server egress IPs require operator- managed PTR records — every outbound IP on the on-prem MTA path MUST have a PTR record published in the operator's reverse-DNS authority (typically managed by the operator's ISP / colocation provider via a $GENERATE directive in the <reverse-octets>.in-addr.arpa zone) that resolves to a hostname whose forward A/AAAA record resolves BACK to the original IP (the FCrDNS round-trip verification), (iii) operator- side PTR misconfiguration is the single most common HYBRID-SPECIFIC deliverability failure that does NOT surface in DMARC aggregate reports — the receiver-side FCrDNS check fires at IP-acceptance time (BEFORE the receiver runs SPF / DKIM / DMARC evaluation), so failed-FCrDNS on-prem mail is REJECTED at the SMTP layer with a 5xx without ever producing a DMARC failure-report row in the operator's aggregate feed — making the on-prem-FCrDNS-broken deliverability gap INVISIBLE to the DMARC-monitoring KPIs the operator is most likely to observe; the diagnostic surface is the on-prem MTA's deferred-queue + bounced- message logs at the 5.7.1 Client host rejected: cannot find your hostname or 5.7.25 Reverse DNS for this IP address does not resolve response, (iv) the hybrid topology's PTR record DUAL-PUBLICATION coordination challenge — the operator must ensure that EVERY on-prem outbound IP the hybrid deployment uses (including any DR / failover IPs and any IPs added during a capacity-expansion event) publishes FCrDNS-passing PTR records coordinated with the operator's ISP BEFORE the IP enters production egress rotation; the Microsoft-managed cloud- only path has no such coordination requirement because the PTR records are managed by EOP. Read the reverse-DNS / PTR / FCrDNS spoke when the hybrid topology's dual-egress deliverability observability surfaces an on-prem-path- specific deliverability drop that does NOT correspond to a DMARC failure-rate increase in the aggregate feed — the PTR / FCrDNS spoke documents the IP-layer sender-legitimacy gate the on-prem path must pass BEFORE the receiver examines any of the SPF / DKIM / DMARC posture this page documents.
• DKIM explained - signer / verifier mechanics, canonicalisation, key rotation, and the body-hash invariant. Essential context for understanding the dual-signer problem.
• DKIM best practices — the HYBRID-EXCHANGE-DUAL-SIGNER-15-PER- SELECTOR-DKIM-AUTHORING-RULES companion to this hybrid Exchange deployment reference. Where THIS page documents the DUAL-EGRESS topology (on-prem Exchange Transport with operator-controlled DKIM signing key + Exchange Online cloud signer with tenant- managed key custody) and the per-path signing-domain-identity coordination the hybrid tenant must execute, the DKIM-best- practices spoke documents the 15 UPSTREAM per-selector DKIM-authoring rules whose per-rule UNIFORM compliance across BOTH egress paths is the LOAD-BEARING UPSTREAM PREREQUISITE every hybrid-tenant dual-signer DKIM-aligned-pass evaluation THIS page documents structurally depends on. The HYBRID-EXCHANGE-DUAL-SIGNER-15-PER-SELECTOR- DKIM-AUTHORING-RULES cross-reference establishes FOUR structurally-distinct per- best-practice-rule-to-hybrid-dual-signer- path coupling dimensions: (i) 2048-bit RSA minimum + dual k=rsa / k=ed25519 publication per RFC 8301 §3 + RFC 8463 as UNIFORM-PER-EGRESS-PATH cryptographic-key-strength compliance discipline — the hybrid topology's on-prem Exchange Transport agent signer and the Exchange Online cloud signer MUST both publish keys meeting the RFC 8301 §3 RSA-2048 floor; a hybrid tenant inheriting a pre-2018 1024-bit RSA key on the on-prem signer while the EOP cloud signer publishes a 2048-bit Microsoft-managed key produces the canonical per-egress-path divergent dkim=fail (insufficient key strength) at on-prem path / dkim=pass at cloud path pattern in modern receiver-side Authentication-Results; the best-practices spoke documents Rule 1 (2048-bit RSA minimum) and Rule 2 (dual- publish k=rsa + k=ed25519) as the UNIFORM-PER-EGRESS-PATH compliance discipline whose hybrid-tenant enforcement is structurally required to prevent the per-egress-path divergent verdict pattern; (ii) annual rotation cadence with the 7-day-dual-selector-overlap + 30-day-in- flight-drain + 30-day-empty-p=- retention discipline as DUAL-SIGNER ROTATION CADENCE COORDINATION load-bearing input — the hybrid topology's on-prem and cloud signers MUST coordinate per-selector rotation cadence such that the on-prem Exchange Transport agent's annual key- rotation event does NOT straddle the Exchange Online cloud signer's tenant-managed rotation event (the OUT-OF-PHASE rotation cadence the dual-signer-rotation spoke documents); the best-practices spoke documents Rule 4 (annual cadence with the 7-day-dual-selector-overlap + 30-day-in- flight-drain + 30-day-empty-p=- retention discipline) as the UNIFORM rotation-cadence target both egress-path signers MUST converge on to prevent the OUT-OF-PHASE rotation-cadence-induced Pattern 3 alignment failures at hybrid steady-state; (iii) c=relaxed/ relaxed canonicalization per RFC 6376 §3.4.4 + §3.4.5 as UNIFORM-PER-EGRESS- PATH canonicalization-mode compliance discipline — the hybrid topology's on-prem Exchange Transport signer and the EOP cloud signer MUST both publish c=relaxed/relaxed canonicalization in the per-selector signature-header construction; a hybrid tenant with the on- prem signer publishing c=simple/simple while the EOP cloud signer publishes c=relaxed/relaxed produces a per-egress-path divergent body-hash-mismatch rate at every receiver-side forwarder / mailing-list / in-transit relay performing whitespace-normalisation on the message body — the on-prem path collapses to dkim=fail (body hash did not verify) at every whitespace-normalised forwarder hop while the EOP cloud path survives the same forwarder hop with dkim=pass; the best-practices spoke documents Rule 5 (c=relaxed/relaxed) as the UNIFORM canonicalization-mode compliance target both egress-path signers MUST converge on; (iv) STRICT prohibition of stale t=y testing-flag past the 24-72h burn-in window as UNIFORM-PER-EGRESS- PATH burn-in cleanup discipline — the hybrid topology's on-prem and cloud signers MUST both clean up the t=y testing flag after the burn-in window completes; a hybrid tenant with stale t=y on the on-prem signer produces the DECEPTIVELY-SILENT per-egress- path divergent DMARC-via-DKIM evaluation pattern where the on-prem-signed messages produce dkim=pass in Authentication-Results but DMARC evaluation SILENTLY ignores the verdict per RFC 6376 §3.6.1, while the EOP-signed messages produce dkim=pass + DMARC=pass through the same receiver — a per-egress- path divergent DMARC verdict the hybrid- tenant RUA aggregate stream surfaces as cohort-divergent DMARC-pass-rate distribution rows; the best-practices spoke documents Rule 9 (t=y burn-in cap of 24-72h then REMOVE) as the UNIFORM-PER- EGRESS-PATH burn-in cleanup discipline both egress-path signers MUST converge on to prevent this DECEPTIVELY-SILENT per-egress- path divergent DMARC verdict pattern. Read THIS hybrid Exchange deployment reference WITH the DKIM-best-practices spoke when the per-egress-path DKIM-signer configuration step arrives at the hybrid tenant's queue: the hybrid page documents the DUAL-EGRESS SIGNER-COORDINATION DESIGN, the best- practices spoke documents the 15 PER- SELECTOR PUBLISHING RULES every per-egress- path signer's per-selector publication MUST UNIFORMLY satisfy to prevent the per-egress- path divergent DKIM-aligned-pass-rate cohort-distribution rows the hybrid-tenant RUA aggregate stream surfaces.
• DKIM key rotation playbook - the HYBRID-EXCHANGE-DUAL-SIGNER-DKIM- KEY-ROTATION-CADENCE-COORDINATION companion to this hybrid-Exchange DMARC deployment reference. Where THIS page documents the DUAL-EGRESS topology (on-prem Exchange Transport with operator-controlled DKIM signing key + Exchange Online cloud signer with tenant-managed key custody) and the per-egress alignment posture each signer must satisfy, the key-rotation spoke documents the dual-selector zero-downtime ROTATION PROCEDURE each of those two signers must execute on its own cadence: the on-prem Exchange Transport Agent rotates via operator-issued PowerShell (New-DkimSigningConfig, Set-DkimSigningConfig -RotateOnDate, operator-published TXT records at selector1._domainkey and selector2._domainkey); the Exchange Online cloud signer rotates via the Microsoft 365 Defender portal's Rotate-DKIM-keys affordance (which auto- publishes the rotation under Microsoft's onmicrosoft.com-anchored CNAME-delegated selector pair). The four DUAL-SIGNER-ROTATION-COORDINATION axes: (i) per-egress rotation CADENCE drift — the on-prem rotation runs on the operator's quarterly playbook while the Exchange Online tenant rotation runs on Microsoft's annual Defender-portal prompt, creating off-by-one rotation windows where one egress signs with the new key while the other still signs with the old; (ii) per-egress TTL-bounded overlap-window coordination — the on-prem operator controls the TTL on the apex-published TXT record while the Exchange Online CNAME-delegated record inherits Microsoft's TTL, producing asymmetric receiver-cache ageing windows; (iii) per-egress d=-tag alignment under DMARC organisational-domain rule — the on-prem signer's d=<domain> aligns directly; the Exchange Online cloud signer's d=<domain> also aligns BUT only after the operator replaces the default onmicrosoft.com signing identity with the custom-domain selector; (iv) per-egress monitoring observability — rotation windows on each egress surface as per-week dkim=fail verdict-rate spikes in the aggregate reports the hybrid-Exchange tenant consumes. Operators landing here for the hybrid-Exchange DMARC deployment need the key-rotation spoke's dual-selector zero-downtime procedure to execute per-egress rotations safely without an enforcement-window regression.
• DKIM cryptography basics - the HYBRID-EXCHANGE-DUAL-EGRESS-DKIM- PRIVATE-KEY-CUSTODY-RESOLVES-TO- CRYPTOGRAPHIC-KEY-INFRASTRUCTURE- COORDINATION companion documenting the RSA-2048 / Ed25519 / SHA-256 cryptographic- primitive byte-anatomy whose per-egress private-key custody + public-key publication discipline the hybrid Exchange dual-signer topology this page documents structurally requires at the on-prem-Exchange + Exchange-Online authority-boundary crossing. Where THIS page documents the operational dual- signer pattern (per-egress separate DKIM signing infrastructure, dual selector1._domainkey + selector2._domainkey publication, key-rotation cadence coordination across both egress paths), the cryptography-basics spoke is the BYTE-ANATOMY REFERENCE documenting the actual cryptographic-primitive construction the on-prem and cloud signers each apply independently. The four-axis HYBRID-DUAL-EGRESS-VS- CRYPTOGRAPHIC-KEY-INFRASTRUCTURE mapping exposes the structurally- distinct dual-egress-to-cryptographic- primitive coordination resolutions: (i) on-prem Exchange RSA-2048 private-key custody → HSM / file- system / certificate-store custody boundary — the on-prem- Exchange signer's RSA-2048 private-key custody is the operator's responsibility at on-prem-infrastructure security boundary; the cryptography-basics spoke documents the per-modulus 2048-bit private-exponent byte-anatomy, the per-OS private-key storage discipline (Windows Certificate Store under LocalMachine\Personal, Linux PKCS#11 HSM token, file-system DKIM signer configuration directory), the FIPS-140- 2 compliance pathway operators must follow for regulated industries (financial / healthcare / federal on-prem deployment patterns), and the per-key compromise-recovery rotation cadence the hybrid topology requires when the on-prem private key's custody boundary is breached without coordination with the cloud signer; (ii) Exchange Online cloud- managed cryptographic-key-custody → Microsoft-managed RSA-2048 + automated rotation byte-anatomy — the Exchange Online signer's RSA-2048 private key is Microsoft-managed at the cloud-service boundary; the cryptography- basics spoke documents the cloud-managed key-rotation cadence (typical 30-day automated rotation per Microsoft default, configurable via PowerShell Set-DkimSigningConfig at the tenant level), the per-tenant cryptographic-key-publication-zone infrastructure (selector1-customer-domain-com._domainkey.customer-domain.onmicrosoft.com as the canonical canonical-name target the customer's apex DNS CNAMEs into), and the structural reason the cloud- managed key custody removes the compromised-on-prem-private-key-affects- cloud-egress risk class (the cloud key is independently rotated by Microsoft); (iii) dual-selector public-key publication discipline → per-egress independent DNS publication byte-anatomy coordination — the hybrid topology's dual-selector pattern (selector1._domainkey.customer.com for cloud egress published as CNAME into Microsoft zone, onprem._domainkey.customer.com for on-prem egress published as direct TXT-record holding the on-prem signer's SubjectPublicKeyInfo blob) requires coordination of the two independent public-key publications; the cryptography- basics spoke documents the DER/PEM- encoded SubjectPublicKeyInfo blob byte- anatomy each publication carries, the per-egress independent key-rotation cadence coordination, and the operator- side responsibility to publish both selectors without DNS-publication-zone TTL drift that would expose either egress path to dkim=permerror during the rotation window; (iv) algorithm-migration dual-egress coordination → per-egress independent RSA-to-Ed25519 algorithm- migration cadence — when the hybrid operator initiates the k=rsa → k=ed25519 RFC 8463 post-quantum algorithm migration, the cryptography-basics spoke documents the per-egress independent migration cadence coordination: Exchange Online's algorithm-migration is controlled by Microsoft's cloud-service deployment cadence (per-tenant rollout windows Microsoft announces independently), the on-prem signer's algorithm-migration is controlled by the on-prem operator's own rollout cadence (per-version Exchange transport-agent or third-party DKIM signer support windows), and the coordination challenge whereby the two egress paths may publish different algorithms during the migration window (cloud-side already on k=ed25519, on-prem still on k=rsa) requires the operator to publish dual-algorithm selectors at both per-egress paths to maintain the DKIM-aligned alignment-domain invariant every hybrid topology depends on per the alignment section above. Read the cryptography-basics spoke when the hybrid topology's dual-egress signing infrastructure needs to coordinate the per-egress cryptographic-primitive custody-and-publication discipline — the spoke is the canonical reference for the RSA-2048 private-key-custody boundary the on-prem signer crosses against the cloud-managed key custody Microsoft provides, the per-egress independent key-rotation cadence the hybrid operator coordinates, and the RSA-to-Ed25519 algorithm-migration coordination discipline every hybrid topology will face during the upcoming post-quantum cryptography migration window.
• DKIM canonicalization - the HYBRID-EXCHANGE-DUAL-EGRESS- UNIFORM-CANONICALIZATION-MODE-COMPLIANCE companion to this hybrid Exchange DMARC operator-reference. Where THIS page documents the per-tenant hybrid Exchange DMARC publication discipline against Centralized-Mail-Transport vs Classic- Hybrid vs Split-domain vs Edge-Transport routing topologies, the DKIM- canonicalization spoke documents the RFC 6376 §3.4 four-combination algorithm catalogue whose UNIFORM per-egress-path compliance is the load-bearing cross-egress DKIM-aligned-pass parity primitive every hybrid tenant must enforce. Three concrete hybrid-vs- canonicalization coupling points: (i) uniform c=relaxed/ relaxed across both egress paths — the canonical hybrid best-practice is to publish c=relaxed/relaxed on BOTH the on-prem Exchange Transport agent signer AND the Exchange Online cloud signer; a divergent canonicalization- mode posture (on-prem c=simple/simple + cloud c=relaxed/relaxed) produces per-egress-path DKIM-pass-rate divergence in the RUA aggregate stream that masks per-egress-path operational regressions; the DKIM-canonicalization spoke documents the per-algorithm-pair byte-level whitespace-tolerance rules the uniform-mode compliance posture requires; (ii) Centralized-Mail- Transport per-message canonicalization survival from on-prem signer through Exchange Online relay — under Centralized-Mail-Transport routing, per-message body+header mutations by the Exchange Online relay (Subject rewriting, Content-Type re-folding, SP/CRLF normalisation) must survive the on-prem signer's canonicalization- algorithm choice; the DKIM- canonicalization spoke documents which mutations c=relaxed/relaxed tolerates vs which c=simple/ simple rejects, the load-bearing determinant of whether the on-prem signature survives the Exchange Online relay hop; (iii) per-egress DKIM-fail-rate root-cause discrimination in the hybrid RUA stream — when the hybrid-tenant RUA aggregate stream surfaces per-egress DKIM-fail rows, the operator must discriminate canonicalization-axis root-cause (per- egress c=-tag divergence OR a per-egress signer applying a canonicalization mode the other egress cannot tolerate after relay) from key- rotation-axis root-cause from selector- publication-axis root-cause; the DKIM- canonicalization spoke documents the per-algorithm-pair failure-signature catalogue the hybrid Exchange triage matrix consumes. Read the DKIM- canonicalization spoke ALONGSIDE this hybrid Exchange DMARC reference whenever the dual-signer topology is first stood up, when the per-egress DKIM-pass-rate parity diverges, or when scoping the per-egress canonicalization-mode compliance audit the hybrid tenant must execute against BOTH signers.
• DMARC records explained - every DMARC tag (v, p, sp, pct, rua, ruf, adkim, aspf, fo, rf, ri).
• DMARC alignment explained - identifier alignment (the SPF-or-DKIM-domain-matches-From: rule). The single concept that makes hybrid topologies fail until both sides sign under the same custom domain (or until only one side signs).
• DKIM alignment with DMARC — the HYBRID-EXCHANGE-DUAL-EGRESS-PER- PATH-DKIM-SIGNING-DOMAIN-ALIGNMENT- DIVERGENCE-AS-LOAD-BEARING-DEFECT-CLASS companion to this hybrid Exchange deployment guide. Where THIS page documents the DUAL-EGRESS-TOPOLOGY COORDINATION at the complete authentication-stack level (Exchange Online Protection cloud-egress path PLUS the on-prem Edge Transport server egress path, each producing per-egress- path DKIM-Signature header outputs at receiver-side verification), the DKIM- alignment-with-DMARC spoke documents the BYTE-LEVEL ALIGNMENT-EVALUATION DISCIPLINE the per-egress-path DKIM- Signature d=-tag must satisfy at receiver-side per-message DMARC evaluation: (i) the per-egress- path per-message comparison between the DKIM-Signature header's d=-tag signing-domain and the RFC 5322 From: header's organisational-domain — the comparison whose outcome distinguishes per-message dkim=pass protocol verdict from per-message dkim=pass + aligned=true DMARC-aligned verdict under RFC 7489 §6.6.2; (ii) the strict-vs-relaxed alignment mode the hybrid-tenant publisher selects via the adkim=s / adkim=r DMARC-record tag- value — applied uniformly across both the EOP cloud-egress and on-prem Edge-Transport egress paths at receiver-side evaluation regardless of which path produced the per-message DKIM signature; (iii) the canonical hybrid-topology defect class — the on-prem Exchange signing path uses one DKIM-Signature d=<on-prem- signing-domain> tag-value while the EOP cloud-egress signing path uses ANOTHER d=<EOP- managed-onmicrosoft.com-tenant> tag-value, producing per-egress-path divergent dkim=aligned=true vs dkim=aligned=false evidence rows in the hybrid tenant's RUA aggregate stream — a recurring Phase 1 inventory defect for hybrid tenants whose on-prem and cloud DKIM- management responsibilities sit with different operational teams; and (iv) the canonical hybrid-tenant remediation pattern — align both egress paths' DKIM signing under the hybrid-tenant's common author-domain (or under organisationally-aligned subdomains for relaxed alignment) so the per- message DKIM-Signature header's d=-tag value organisationally aligns with the From: header at receiver-side evaluation across BOTH egress paths, restoring per-message dkim=aligned=true uniformly. Read this WITH the hybrid Exchange deployment guide when the operator's Phase 1 RUA sender- inventory step surfaces per-egress- path divergent DKIM-alignment evidence rows: THIS page documents the DUAL-EGRESS-TOPOLOGY DESIGN, the DKIM-alignment-with-DMARC spoke documents the BYTE-LEVEL ALIGNMENT- EVALUATION DISCIPLINE both egress paths' DKIM-Signature outputs must uniformly satisfy.
• DMARC policy rollout - the operational migration from p=none through p=quarantine to p=reject with a worked Week 0 -> Week 26 timeline. Hybrid takes 4-8 weeks at p=none instead of 2-6 weeks because more sender paths surface.
• DMARC deployment checklist — the HYBRID-EXCHANGE-DUAL-OUTBOUND- BOUNDARY-DEPLOYMENT-CHECKLIST-EXECUTION companion to this hybrid-coexistence DMARC deployment reference. Where THIS page documents the hybrid-deployment topology (classic-hybrid HCW-configured / Centralized- Mail-Transport CMT / split-domain coexistence / Edge-Transport Server topologies, the on-prem-to-cloud relay traversal, the dual- signer DKIM resolution, the ARC sealing of the on-prem-to-cloud relay per RFC 8617), the DMARC-deployment-checklist is the CANONICAL GREEN-PATH WORKFLOW hybrid Exchange operators execute ACROSS BOTH OUTBOUND BOUNDARIES with hybrid-coexistence- specific coordination requirements layered on top. Four per-hybrid-checklist- execution-coordination dimensions: (i) PHASE-1-DUAL-OUTBOUND-BOUNDARY-SPF- PREREQUISITE (the checklist's Phase 1 SPF- prerequisite step requires hybrid operators to publish a single apex SPF record authorising BOTH on-prem Edge-Transport egress IP-ranges AND Exchange Online's spf.protection.outlook.com — a structurally-distinct authoring discipline from cloud-only-M365 or on-prem-only- Exchange; the 10-DNS-lookup budget audit must factor BOTH egress paths), (ii) PHASE-1-DUAL-SIGNER-DKIM-PREREQUISITE- DISAMBIGUATION (the checklist's Phase 1 DKIM-prerequisite step requires hybrid operators to resolve the dual-signer ambiguity — cloud-only-signing / on-prem-only-signing / avoid-this-dual- signer-pattern; the checklist's per- boundary DKIM-signing-domain audit is structurally doubled across the hybrid topology), (iii) PHASE-2-RUA-PUBLICATION- AT-DUAL-OUTBOUND-BOUNDARY-AGGREGATION (the checklist's Phase 2 RUA-publication step produces per-boundary Authentication- Results visibility — the per-boundary evidence rows the checklist's audit step uses to verify Phase 1 prerequisites are structurally distinct across the on-prem-relay vs cloud-egress per- boundary attribution and require the per-boundary segmentation discipline memory documents at the operator-side KPI 5 source-set baseline), (iv) PHASE-3- THROUGH-PHASE-5-DUAL-OUTBOUND-BOUNDARY- RAMP-PROGRESSION (the checklist's Phase 3-5 ramp progression requires per-boundary ramp-readiness coordination — premature Phase 4 p=quarantine advancement before BOTH boundaries reach the Phase 3 baseline silently quarantines on-prem-originated PowerShell-scripted- monitoring / DUI-scanner / line-of- business-application-relay mail OR EXO- originated Outlook desktop / mobile OWA / per-mailbox-rule auto-forward mail; the per-boundary ramp-progression coordination is structurally distinct from cloud-only or on-prem-only ramp discipline). Critical when hybrid Exchange operators executing dual-outbound-boundary DMARC deployment need the canonical green-path step-by- step workflow reference layered on top of the hybrid-coexistence topology — the DMARC-deployment-checklist is the operator-facing workflow driver this hybrid Exchange deployment page contextualises per-hybrid-topology- specific dual-boundary coordination.
• DMARC aggregate (RUA) reports - the daily XML stream receivers send back. The data behind every hybrid sender-path inventory decision.
• DMARC troubleshooting - cross-cutting failure diagnosis: 7 canonical DMARC failure patterns each mapped to a root cause and remediation. Read alongside the hybrid-specific troubleshooting section above.
• DMARC monitoring & reporting analysis - meta-KPIs that detect when DMARC coverage drops (e.g. "rua= mailbox is bouncing" recovery, reporter-set coverage). Hybrid environments need sharper monitoring because the sender-path surface is larger.
• DMARC for SaaS senders - the CNAME-delegated subdomain DKIM pattern used by every marketing-automation platform. In hybrid environments these senders often co-exist with both on-prem and cloud Exchange paths.
• DMARC for transactional email - the API-based transactional sender deployment pattern (SendGrid, Mailgun, SES). Common in hybrid for application-driven mail that should not go through Exchange anonymous relay.
• Email authentication glossary - canonical definitions reference for every term-of-art the cluster assumes: DMARC tags, DKIM selectors, alignment, organizational domain, PSL, RFC 5321 vs 5322, ARC chain validation, BIMI Mark Type Indicator, MTA-STS policy modes, TLS-RPT result types, and 60+ more.
• CAA records explained - Certification Authority Authorization (RFC 8659). Hybrid Exchange topologies operate two distinct TLS-certificate issuance pathways under a single organizational domain: (1) the Microsoft-managed pathway issues certificates for tenant-vanity hostnames in protection.outlook.com and any on-mail-flow custom domains served by Exchange Online Protection, typically via Microsoft-internal PKI or commercial CAs Microsoft has provisioned for the tenant; (2) the on-prem pathway issues certificates for Edge Transport / Mailbox role servers receiving inbound SMTP, typically via a commercial CA the operator selects (DigiCert, GlobalSign, Sectigo, Let's Encrypt / ISRG). The apex CAA RR must authorise BOTH CA sets via parallel issue directives (or omit CAA entirely) - a CAA record tightened to ONLY the on-prem CA silently breaks Microsoft-side cert renewal cycles weeks later; a CAA record tightened to ONLY the Microsoft CA silently breaks on-prem inbound TLS continuity. Audit CAA against the FULL union of certs in the hybrid deployment before tightening - the failure surfaces months later at Microsoft's auto-renewal or the on-prem cert's expiry, by which time the operator who tightened CAA may have moved on and the failure appears in a totally-unrelated inbound mail-flow incident.
• DKIM for Microsoft 365 — the HYBRID-EXCHANGE-IN-CLOUD-EGRESS-LEG- PER-M365-TENANT-DKIM-SELECTOR-1-AND- SELECTOR-2-DOMAINKEY-CNAME-PUBLICATION companion to this hybrid-Exchange reference. Where THIS page documents the hybrid Exchange topology (on-prem Exchange + Exchange Online dual-egress coexistence, HCW-provisioned send connectors, transport- rule envelope rewriting at the Edge boundary), the dkim_for_microsoft_365 spoke is the M365-TENANT-DKIM-PUBLICATION canonical reference documenting the FOUR hybrid-in-cloud-leg DKIM-publication-vs- hybrid-dual-egress-coordination dimensions the hybrid-Exchange operator must coordinate across the two-leg dual-egress DKIM-signing topology: (i) M365 selector1/selector2 dual-selector CNAME publication as the in-cloud egress leg DKIM-signature-publication primitive — the per-tenant selector1-<tenant>. _domainkey + selector2-<tenant>. _domainkey CNAMEs publishing to the Microsoft-managed onmicrosoft.com host- names are the IN-CLOUD-LEG DKIM-key- publication primitive whose per-message DKIM-Signature emission via EOP at the Exchange Online egress boundary is the in-cloud-leg counterpart to the on-prem Exchange transport-agent DKIM-signing documented elsewhere in the hybrid topology; (ii) Microsoft 365 Defender portal DKIM-enablement-for- protected-vanity-domain as the hybrid- coordination prerequisite for the adkim-aligned-pass evaluation across the in-cloud egress leg — the M365 default d=<tenant>. onmicrosoft.com emission DEFEATS the adkim-relaxed-mode alignment evaluation against the protected vanity From-author-domain; the hybrid operator MUST execute the Microsoft 365 Defender portal DKIM-enablement workflow for the protected vanity domain BEFORE the Exchange Online egress leg of the hybrid topology produces DKIM-aligned- pass verdicts at downstream receivers; (iii) 2048-bit RSA key-strength Rotate-DkimSigningConfig PowerShell cmdlet orchestration as the hybrid in- cloud-leg cryptographic-foundation upgrade discipline — the M365 legacy default 1024-bit RSA key-strength is deprecated per RFC 8301 §3; the hybrid operator MUST execute the Rotate-DkimSigningConfig -KeySize 2048 PowerShell sequence for each per-tenant signing configuration to upgrade the in- cloud-leg DKIM-signing to the modern cryptographic-foundation discipline BEFORE the receiver-side DKIM-verifier- and-DMARC-aligner produces meaningful per-message DKIM-aligned-pass verdicts on Exchange Online egress mail; (iv) M365 dual-selector rotation cadence coordination with on-prem Exchange transport-agent rotation cadence at the hybrid-topology dual- signer-out-of-phase rotation-window boundary — the hybrid topology produces a DUAL-SIGNER rotation-cadence coordination problem: the on-prem Exchange transport-agent signer + the M365 in-cloud signer rotate INDEPENDENTLY by default, producing out-of-phase rotation windows that introduce per-message DKIM-signature- mismatch alignment-failure surfaces; the hybrid operator MUST synchronise the two rotation cadences (or accept the rotation-window dual-egress alignment- failure surface) — the per-M365-tenant Rotate-DkimSigningConfig orchestration the dkim_for_microsoft_365 spoke documents is one half of the dual- signer rotation coordination this hybrid topology demands. Read the dkim_for_microsoft_365 spoke as the in-cloud egress leg DKIM-publication reference when planning the hybrid- Exchange dual-egress DKIM-signing deployment THIS page documents.
• DKIM failures explained — the HYBRID-TOPOLOGY-DUAL-EGRESS-WRONG-TENANT-SELECTOR-SIGNING companion to this hybrid-Exchange reference — the HYBRID-TOPOLOGY-DUAL-EGRESS-WRONG- TENANT-SELECTOR-SIGNING companion documenting how the hybrid Exchange topology THIS page documents (on-prem Exchange + EOP dual- egress, HCW-provisioned send connectors, transport-rule envelope rewriting at the Edge boundary) produces a structurally- distinct class of DKIM verification failure modes the single-tenant DKIM-failure diagnostic taxonomy does not anticipate. Where THIS page documents the hybrid TOPOLOGY in operational terms (the two egress paths producing policy_evaluated.dkim=fail rows in RUA when a message intended for EOP-signing exits via the on-prem path with no DKIM signature, or when on-prem- originated mail exits via the EOP connector and is signed with the tenant's selector1-<tenant>._domainkey.<onmicrosoft.com> instead of the operator's published organization-domain selector), the failures spoke catalogues the receiver-side Authentication-Results stamp signature each hybrid mis-route produces: dkim=none (no signature applied because the on-prem-egress path bypassed both signing infrastructures), dkim=fail body-hash-mismatch (EOP signed the message on outbound but on-prem-side transport rules rewrote the body en route to the recipient), dkim=pass with policy_evaluated.dkim=fail DMARC-non-aligned (signed with the onmicrosoft.com tenant selector but the From: header is the operator's organization-domain — DKIM verified cryptographically but alignment computation on this page's hybrid topology produces the misalignment), and dkim=temperror (the dual-egress configuration produces a DNS lookup against the wrong selector for the egress path actually taken). Read THIS hybrid-topology page WITH the failures reference when investigating the policy_evaluated.dkim=fail RUA rows that hybrid topology disproportionately produces — the failures spoke names the four diagnostic Authentication-Results signatures that distinguish the four hybrid-specific mis-route failure modes from single-tenant single-egress DKIM failure modes.
• DMARC for shared hosting — the MULTI-EGRESS-PUBLISHER-IDENTITY- ALIGNMENT-COORDINATION-PARALLEL-AT-THE- PROVIDER-OPERATED-OUTBOUND-RELAY-POOL- BOUNDARY companion to this DMARC-for- hybrid-Microsoft-365 reference. Where THIS page documents the hybrid M365 deployment topology (on-prem Exchange Server connected to Exchange Online via the Exchange Hybrid Configuration Wizard publishing per- connector outbound mail flow through TWO DISTINCT egress identities — the on-prem Exchange Server edge transport + the Exchange Online cloud egress IP-pool — each producing per-message DKIM-Signature verdicts that must individually DMARC-align at the receiver), the shared-hosting spoke is the structural-parallel per-deployment- class sibling documenting the SAME multi- egress publisher-identity alignment- coordination discipline at four cross- deployment alignment-coordination dimensions: (i) multi-egress publisher-identity coordination at the provider-operated outbound-relay-pool boundary parallel — hybrid M365 publishes per-message DKIM-Signature verdicts through TWO distinct egress identities (on-prem Exchange Server edge + EXO cloud egress IP-pool) where each egress publisher's per-source-IP DMARC- aligned-pass-rate must be observed independently in the rua aggregate-XML stream; shared-hosting publishes per- message DKIM-Signature verdicts through ONE provider-operated shared-outbound- relay-pool egress identity whose per- source-IP DMARC-aligned-pass-rate is observed across ALL co-tenant publishers sharing the same outbound-relay-pool IP space — both deployment classes face the SAME per-publisher per-source-IP DMARC- aligned-pass-rate-attribution discipline in the rua aggregate-XML stream; (ii) upstream-relay-provider-managed DKIM-signing-key custody parallel — hybrid M365 leaves DKIM signing for EXO-egress messages to the Microsoft- operated DKIM-signing infrastructure (Microsoft holds the per-tenant selector1._domainkey.<tenant-domain> / selector2._domainkey.<tenant- domain> private keys server- side); shared-hosting leaves DKIM signing for shared-relay-pool egress messages to the hosting-provider-operated DKIM-signing infrastructure (cPanel Exim / Plesk Postfix / DirectAdmin Exim holds the per-domain DKIM private keys server-side in /etc/exim.conf.local or the Plesk DKIM-on-zone template) — both deployment classes face the SAME upstream-provider-managed DKIM-signing- key-custody-vs-publisher-side-d-tag- alignment coordination constraint at the per-publisher per-domain DMARC-DKIM- alignment evaluation boundary; (iii) per-publisher SPF authority list coordination across upstream-relay- provider include cascade parallel — hybrid M365 SPF-records must include:spf.protection.outlook.com for EXO-egress + per-on-prem-Exchange- edge ip4:<edge-IP> mechanism for on-prem-egress; shared- hosting SPF-records must include:<provider-spf-host> (e.g. include:spf.bluehost.com / include:<cpanel-host>.com) for shared-relay-pool egress — both deployment classes face the SAME 10- mechanism SPF-lookup-limit ceiling per RFC 7208 §4.6.4 when the per-publisher SPF authority-list cascades through multiple upstream-relay-provider include: token-chains; (iv) per-publisher per-source-IP forensic-investigation attribution discipline at the multi- publisher-share-the-same-egress-IP-pool boundary parallel — hybrid M365 per-source-IP forensic-investigation must distinguish per-tenant on-prem edge IPs from EXO-cloud-egress shared-IP-pool members across the per-source-IP rua-XML record-level evidence row; shared-hosting per-source-IP forensic-investigation must distinguish per-tenant-attribution within the SAME shared-outbound-relay-pool IP space across the per-source-IP rua-XML evidence row — both deployment classes face the SAME per-source-IP-evidence- attribution discipline at the multi- publisher-share-the-same-egress-IP-pool forensic-investigation boundary. Read the shared-hosting spoke ALONGSIDE this hybrid-M365 reference whenever a multi- egress publisher-identity DMARC-alignment coordination discipline question emerges that crosses deployment-class — the cross- deployment-class structural-parallel between hybrid-M365-multi-egress alignment coordination and shared-hosting-multi- tenant alignment coordination is the load- bearing operator-education surface for per-publisher per-source-IP alignment- coordination discipline transfer across deployment-class boundaries.
• Microsoft 365 Defender portal - the operator entry point for DKIM management, Trusted ARC Sealers configuration, and anti-spoof policy.
• Microsoft Learn: Exchange Server hybrid deployments - the canonical primary-source Microsoft documentation for hybrid Exchange topology and HCW.
• Microsoft Learn: Trusted ARC Sealers - the Set-ArcConfig and Defender portal documentation for the feature that makes hybrid ARC work.
• Google: Email sender guidelines - the canonical Feb 2024 bulk-sender requirements document that applies to every sender regardless of mailbox provider.
• SPF qualifiers explained — the HYBRID-TOPOLOGY-ON-PREM-PLUS- EXCHANGE-ONLINE-DUAL-EGRESS-CUTOVER- SPF-QUALIFIER-CHOICE companion reference. Where THIS page documents the hybrid Exchange + EOP topology (dual MX, dual egress, ARC trust configuration via Set-ArcConfig, transport rule preservation, journal rules, mailflow connectors), the SPF- qualifiers spoke documents the FOUR QUALIFIER PREFIXES (+ Pass / - Fail / ~ SoftFail / ? Neutral) whose VALUE- CHOICE on the all mechanism is the OPERATIONAL LEVER the hybrid cutover playbook tunes. During the cutover window, legitimate mail still flows through BOTH paths — on-prem Edge Transport via v=spf1 ip4:198.51.100.0/24 include:spf.protection.outlook.com ~all covers the on-prem egress IPs and the EOP egress range together, but the inventory is rarely confirmed-complete on day one. The ~all qualifier delivers MONITORING-MODE behaviour during the weeks while the operator validates every cutover-edge sender path via the aggregate report stream — non- authorised IPs produce spf= softfail in Authentication-Results, surfacing in RUA result_type=softfail rows without rejecting legitimate cutover-edge traffic. Once weeks of observation confirm every legitimate sender path is covered by the SPF record (third-party scanners, archiving connectors, legacy line-of- business systems still relaying via the on-prem path), the operator tightens to -all to gain SMTP-time enforcement and shrink the attacker-exploitable softfail- delivery surface. Read the qualifier spoke alongside this page when operating the hybrid cutover transition — the ~all → -all flip is one of the explicit post-cutover hardening steps the topology requires before the organisation can declare the hybrid cutover complete.
• MTA-STS for Microsoft 365 - the HYBRID-TOPOLOGY-MTA-STS-AT- EXCHANGE-ONLINE-RECEIVE-BOUNDARY- FOR-INBOUND-FROM-ON-PREM-PLUS- INTERNET-TLS-ENFORCEMENT-COVERAGE- EQUIVALENCE companion reference. Where THIS page documents the hybrid Exchange + EOP topology (dual MX, dual egress, ARC trust configuration, transport rule preservation, journal rules, mailflow connectors, the ~all → -all SPF qualifier flip), the MTA-STS-for-Microsoft-365 spoke documents the M365-tenant MTA-STS publication mechanics that must deliver TLS-enforcement coverage EQUIVALENT across the hybrid topology's TWO inbound MX paths. A hybrid topology publishes BOTH the Exchange Online inbound MX (contoso-com.mail.protection.outlook.com) AND the on-prem inbound MX (mail.contoso.com) — the MTA-STS policy file's mx: allow-list MUST enumerate BOTH (or use a *.contoso.com wildcard covering both) so the enforced TLS- policy applies to inbound mail arriving via EITHER receive path. A common hybrid-cutover misconfiguration is to publish an MTA-STS policy whose mx: list covers only the EOP MX, leaving on-prem-routed inbound traffic outside the MTA-STS enforcement window — sending MTAs respecting the policy will refuse to deliver to the on-prem MX (its FQDN is not in the policy allow-list), causing a deliverability failure mode entirely caused by the MTA-STS publication discipline. Read the M365 MTA-STS spoke alongside this page when scoping the hybrid topology's MTA-STS deployment — the policy file's mx: list MUST match the hybrid topology's full dual-receive MX inventory to guarantee TLS-enforcement-coverage equivalence across both inbound paths.
• MTA-STS for Google Workspace - the HYBRID-TOPOLOGY-M365-OUTBOUND- VIA-EXCHANGE-ONLINE-CONNECTOR-MUST- RESPECT-WORKSPACE-RECEIVERS-MTA-STS- POLICY-FOR-MAIL-TO-GMAIL-AND-G-SUITE- TENANTS companion reference. Where THIS page documents the hybrid Exchange + EOP topology from the SENDER and PROTECTED- DOMAIN perspectives (dual MX inbound, dual egress, ARC trust, transport-rule preservation, mailflow connectors), the MTA-STS-for-Google-Workspace spoke documents the Workspace-RECEIVER-side MTA-STS publication mechanics whose enforced-mode policy the hybrid topology's M365-OUTBOUND path (Exchange Online connector → gmail.com / Workspace-tenant MX endpoints) must honor at TLS-policy enforcement time. A common hybrid-cross-tenant deliverability incident: M365 organisation sending mail to Workspace recipients (vendors / partners / consumers on gmail.com or hosted on Workspace tenants) via the Exchange Online outbound connector — Exchange Online's outbound MTA implementation honours the recipient's MTA-STS policy at send time, so a Workspace-tenant publishing mode: enforce with a mx: allow-list specifying the Workspace MX inventory (aspmx.l.google.com, alt1.aspmx.l.google.com, alt2.aspmx.l.google.com, alt3.aspmx.l.google.com, alt4.aspmx.l.google.com) is the policy the M365 OUTBOUND connector must comply with — if the connector's destination-DNS lookup resolves an MX hostname NOT in the Workspace recipient's policy mx: list (typical cause: an in-flight Workspace MX-inventory change the recipient's _mta-sts.<domain> TXT-record id=-keyed cache hasn't yet refreshed), the outbound connector queues or DSN- bounces the message. Read the Workspace MTA-STS spoke alongside this page when investigating hybrid-tenant outbound TLS-policy compliance to Workspace receivers — the policy-file mx: list + max_age: propagation window from the recipient's perspective is what governs whether the hybrid M365 outbound connector successfully delivers, both during steady-state and during recipient MX-inventory rollovers.
• MTA-STS vs DANE — the HYBRID-TOPOLOGY-DUAL-EGRESS-DUAL- INBOUND-TRANSPORT-SECURITY-PROTOCOL-CHOICE companion reference. Where THIS page documents the hybrid Exchange + EOP topology in operational terms (FIVE distinct mail-flow paths, dual-egress identifier-misalignment scenarios, ARC trust preservation, transport-rule boundary mechanics, Send / Receive connector configuration), the MTA-STS-vs-DANE spoke documents the TRANSPORT-LAYER protocol-choice decision-tree the hybrid-Exchange operator MUST resolve at deployment time across FOUR hybrid-specific constraints the dual-egress + dual-inbound topology imposes on the protocol choice: (1) DNSSEC coverage constraint — DANE STRUCTURALLY requires DNSSEC on the protected-domain's parent zone AND on the MX hostnames' parent zones (typically protection.outlook.com for the EOP receive-side AND the on- prem-MX hostname's parent zone); Microsoft does NOT DNSSEC-sign the protection.outlook.com zone as of 2026, which STRUCTURALLY rules out DANE for the EOP-receive path and forces MTA-STS as the only viable transport-security protocol for the hybrid topology's EOP-inbound MX; (2) dual-receive policy-file mx: list constraint — the hybrid topology's MTA-STS policy file at /.well-known/mta-sts.txt MUST list BOTH the EOP inbound MX (*.mail.protection.outlook.com) AND the on-prem inbound MX hostnames simultaneously to deliver TLS-enforcement coverage equivalence across both inbound paths (the MTA-STS-for-Microsoft-365 spoke documents the byte-shape of this dual- MX policy file in detail); (3) dual-egress MTA-STS-policy-respect constraint — both the Exchange Online outbound connector AND the on-prem Edge Transport outbound MTA must respect the recipient's MTA-STS policy at send time, which means BOTH outbound paths must implement the RFC 8461 §4.3 policy-fetch-and-cache algorithm (Exchange Online does this natively; the on-prem Edge Transport requires Exchange 2019 CU13+ or third-party transport-rule instrumentation); (4) TLS-RPT publication scope — the hybrid topology must publish a single TLS-RPT record at _smtp._tls.<domain> that captures TLS failures from BOTH inbound paths (the report aggregation mechanics for dual-MX hybrid topologies require the TLS-RPT-for-hybrid-Exchange operator to reconcile per-MX-host failure-type rows). Read the MTA-STS-vs-DANE spoke when scoping the hybrid topology's transport-security protocol choice — the spoke is the authoritative reference for resolving the DNSSEC-coverage and dual-MX publication constraints the hybrid topology imposes on the binary protocol choice between MTA-STS and DANE.
• MTA-STS policy syntax — the HYBRID-TOPOLOGY-DUAL-MX-MTA-STS- POLICY-FILE-BODY-LINE-GRAMMAR-AUTHORING- DISCIPLINE companion reference. Where THIS page documents the hybrid Exchange + EOP topology in OPERATIONAL terms (FIVE distinct mail-flow paths, dual-egress identifier- misalignment scenarios, ARC trust preservation, transport-rule boundary mechanics, Send / Receive connector configuration, the ~all → -all SPF qualifier flip), the MTA-STS-policy-syntax spoke is the BYTE-SHAPE-OF-THE-POLICY-FILE- BODY reference documenting the RFC 8461 §3.2 line-grammar (version: STSv1 as the literal first line, mode: testing|enforce|none as the publication-stage line, one or more mx: <hostname-pattern> lines enumerating the receive-MX allow-list with optional left-most-label *-wildcards, max_age: <seconds> as the sending-MTA cache-TTL line) the hybrid-topology operator MUST instantiate at https://mta-sts.<domain>/.well-known/mta-sts.txt to deliver TLS-enforcement coverage equivalence across both inbound paths. Four hybrid-policy-body-authoring dimensions the spoke addresses: (1) per-MX-hostname-pattern enumeration — the dual-MX hybrid topology requires the policy file's mx: allow-list to enumerate BOTH the Exchange Online inbound MX (typically a glob-wildcard mx: *.mail.protection.outlook.com covering the EOP receive-side per-tenant FQDN) AND the on-prem inbound MX hostnames (typically a literal mx: mail.contoso.com covering the on-prem receive-side) as TWO separate mx: lines per RFC 8461 §3.2 — omitting either line leaves THAT inbound path outside the MTA-STS enforcement window and creates the deliverability failure mode the MTA-STS-for-Microsoft-365 spoke warns about; (2) mode progression discipline — the hybrid topology's deployment cadence STRUCTURALLY requires mode: testing for the first 2-4 weeks of policy publication (so the TLS-RPT aggregate-evidence stream surfaces per-receiver per-day failures against the dual-MX allow-list WITHOUT blocking delivery), followed by mode: enforce after the TLS-RPT failure rate falls below the operator's risk threshold — the spoke documents the per-mode behaviour difference at sender-MTA enforcement time; (3) max_age cache-TTL choice — the hybrid topology's MX-inventory-rollover cadence (adding a new on-prem Edge Transport receive-MX, decommissioning a legacy on-prem MX, rolling forward the EOP tenant after a cross-tenant migration) determines the max_age: seconds value the operator publishes — too-long (max_age: 31557600) means sending-MTA caches retain stale allow-lists during rollovers; too-short (max_age: 86400) means sending-MTAs re-fetch the policy daily, increasing the policy-host bandwidth consumption — the spoke documents the cache-TTL discipline RFC 8461 §3.2 bounds-check imposes; (4) _mta-sts.<domain> TXT-record id= versioning — the policy file body changes (a new mx: hostname added during on-prem Edge Transport rollout, a mode: flip from testing to enforce, a max_age: tightening) must be paired with an id= bump in the _mta-sts.<domain> TXT-record so sending-MTAs respecting the policy detect the change and invalidate their cached copy at next-fetch opportunity — the spoke documents the id=-keyed cache-invalidation contract sending-MTAs implement against the policy file body. Read the MTA-STS-policy-syntax spoke alongside this page when authoring the hybrid topology's mta-sts.txt policy file body — the per-MX-hostname- pattern enumeration + mode progression + max_age cache-TTL + id=-keyed versioning decisions are the load-bearing byte-shape choices the hybrid topology imposes on the policy file body grammar before TLS-enforcement coverage equivalence across both inbound paths can be declared operational.
• TLS-RPT explained — the HYBRID-TOPOLOGY-DUAL-RECEIVE-PATH- TRANSPORT-FAILURE-OBSERVABILITY companion reference. Where THIS page enumerates the FIVE distinct hybrid mail-flow paths (Centralized Mail Transport / Classic Hybrid / Split-domain / Edge Transport / Direct Send) each presenting a DISTINCT DMARC-evaluation surface to receivers, the TLS-RPT-explained spoke is the TRANSPORT- LAYER-OBSERVABILITY-PROTOCOL-CHARTER reference documenting the RFC 8460 per-receiver per-day aggregate evidence stream operators inherit when publishing _smtp._tls.<domain> — the evidence stream a hybrid-topology operator structurally consumes to distinguish Exchange-Online-MX TLS-outcome from on-prem-MX TLS-outcome under the SAME organisational domain at the receiver- side per-day aggregation boundary. FOUR structurally-distinct HYBRID-TOPOLOGY- TLS-RPT-PROTOCOL-CONSUMER dimensions the TLS-RPT charter defines that this hybrid deployment-mode page structurally consumes for dual-receive-path transport-observability framing: (i) per-receive-path per- day TLS-pass-rate divergence detection AS THE DIAGNOSTIC-PRIMITIVE for Exchange- Online-MX vs on-prem-MX TLS-outcome attribution under shared organisational domain — the protocol-overview spoke documents the RFC 8460 §2 per-day- per-domain aggregation cadence whose per-receiver granularity allows the hybrid operator to compute per-receive-path TLS-pass-rate divergence (the per-day TLS-pass-rate at Exchange-Online-MX *.mail.protection.outlook.com minus the per-day TLS-pass-rate at the on-prem MX); a sustained >5pp divergence is the canonical diagnostic signal of an on-prem-MX-specific TLS- configuration regression (expired intermediate-CA chain, weak DH parameters, TLS 1.0/1.1 deprecation cliff) the per-receive-path attribution the protocol-overview's per-receiver granularity makes mechanically possible; (ii) per-receive-path per-day STARTTLS-not-supported result-type attribution as the diagnostic for on-prem- MX cleartext-cliff regression under shared organisational domain — the protocol-overview spoke documents the per-receiver result-type vocabulary (defined in RFC 8460 §4 but referenced from the protocol charter at §1-§2 as the per-day evidence the protocol delivers) including starttls-not-supported / certificate-not-trusted / certificate-host-mismatch / certificate-expired; in the hybrid topology, the OPERATOR diagnoses which receive-path (Exchange-Online-MX vs on-prem-MX) emitted the result-type entries — Exchange-Online-MX rows on *.mail.protection.outlook.com SHOULD NEVER show starttls-not-supported at any per-day cadence (Microsoft mandates STARTTLS at the receive boundary); a non-zero per-day count of starttls-not-supported rows attributable to the on-prem-MX IP/hostname is the canonical regression signal for an on-prem-MX STARTTLS- configuration regression (mis-config, cert expiry, intermediate CA chain breakage); (iii) per-day per- receiver per-domain aggregate-mailbox- subscription model + receiver-population- coverage expectations the protocol charter sets for the hybrid operator's observability program — the protocol-overview spoke documents the RFC 8460 §2 deployment-model (RUA-mailbox TLS-RPT subscription model, per-receiver aggregate-report cadence expectations at major Gmail/Yahoo/Microsoft/Apple populations, per-domain receiver- population coverage expectations for a properly-published TLS-RPT) that the hybrid-topology operator must understand to author the per-receive-path observability program — when authoring TLS-RPT for a hybrid domain, the operator depends on the protocol-overview's receiver-population-coverage expectations (Gmail and Outlook DO emit TLS-RPT aggregates for any RUA-mailbox-subscriber domain; Yahoo emits aggregates per a documented cadence; smaller receivers may not emit at all) to baseline per- domain receiver-coverage expectations; (iv) per-day-per-domain aggregate cardinality boundary AS THE ATTACKER- UNUSABLE-AS-EXFIL-CHANNEL invariant whose privacy guarantees the hybrid operator can present to the organisation's privacy/compliance function — the protocol-overview spoke documents the RFC 8460 §5 privacy- by-design protocol invariant: TLS-RPT aggregates strictly exclude per-message PII (envelope-sender, message-id, recipient) by protocol definition; this invariant is the load-bearing organisational-compliance gate the hybrid operator presents to GDPR / data- protection / privacy review when proposing TLS-RPT publication — without the §5 privacy invariant, the operator's publishing of _smtp._tls.<domain> with an organisational RUA-mailbox would require a Data Protection Impact Assessment justification process THE PROTOCOL OBVIATES BY DESIGN. Read the TLS-RPT-protocol-overview spoke alongside this hybrid deployment-mode page when authoring the TRANSPORT-LAYER section of the hybrid topology's monitoring program — the protocol-overview is the load- bearing CHARTER + DEPLOYMENT-MODEL + RECEIVER-POPULATION-COVERAGE + PRIVACY- INVARIANT reference for the dual-receive- path transport-observability program the hybrid operator runs.
• DMARC forensic reports (RUF) - the HYBRID-EXCHANGE-DUAL-SOURCE-PER- MESSAGE-AFRF-ENVELOPE-FORENSIC-EVIDENCE- STREAM companion to this hybrid deployment reference. Where THIS page enumerates the FIVE distinct hybrid mail-flow paths (Centralized Mail Transport — all outbound through Exchange Online; Classic Hybrid — on-prem mailboxes egress directly via on-prem Edge Transport; Split-domain — per-mailbox routing decision at the on-prem Send Connector; Edge Transport — DMZ-hosted Edge servers proxy on-prem outbound; Direct Send — application-relay bypassing both Exchange Online and on-prem Exchange) each with structurally-DIFFERENT DKIM-signing identity / SPF-source IP / ARC-sealing posture / source-IP attribution, the DMARC forensic-reports (RUF) spoke documents the per-message-envelope EVIDENCE STREAM diagnosing WHICH hybrid path emitted a specific DMARC-failing message in production. The RUF stream is the ONLY diagnostic surface that reveals (i) the Source-IP header in the AFRF envelope identifying whether the offending message egressed from an EOP-allocated IP (40.92.0.0/15, 40.107.0.0/16, 52.100.0.0/14) versus an operator-managed on-prem Edge Transport IP — instantly disambiguating the five paths at the IP-routing layer; (ii) the DKIM-Domain header revealing whether the failed DKIM signature was emitted by the cloud selector1/selector2.<tenant>._domainkey.<org-domain> CNAME-delegated key (cloud-only signing path) versus an on-prem-published selector*.<org-domain> TXT key (on-prem signing path) versus the DAMNING d=<tenant>.onmicrosoft.com unaligned signing identity (the Connector-misconfiguration pathology); (iii) the embedded ARC-Seal: / ARC-Message-Signature: / ARC-Authentication-Results: chain instance counts revealing whether the on-prem-to-cloud relay leg installed an ARC seal preserving the on-prem authentication verdict OR stripped / invalidated DKIM during the inter-hop transit (the Send-Connector pathology that breaks DKIM at the relay boundary); (iv) the Authentication-Results: stamping showing the cloud-side re-evaluation verdict on a message already authenticated on-prem; (v) the embedded Received: header chain reconstructing the precise hop sequence the offending message traversed between on-prem and cloud. Read the DMARC forensic-reports pillar for the per-message AFRF MIME envelope structure (RFC 5965 message/feedback-report outer container + RFC 6591 Auth-Failure feedback-type + embedded message/rfc822 message-headers part + optional embedded original-message part), the fo= failure-reporting-options tag governing RUF emission volume (fo=1 on ANY mechanism failure is the operational baseline for hybrid troubleshooting because it surfaces both DKIM and SPF independent failures the Classic-Hybrid Send-Connector pathology triggers), the still-active forensic receivers (Yahoo / AOL / Mail.ru — Microsoft DEPRECATED RUF emission years ago, which means M365-egressed messages to M365-hosted recipients NEVER generate RUF and you must rely on RUF from Yahoo / AOL recipients to diagnose hybrid pathologies), and the GDPR / CCPA / Schrems II privacy analysis governing operator-side ingestion of RUF envelopes containing third-party PII in the embedded message/rfc822 part — especially load-bearing for hybrid topologies where European recipient PII flows across the on-prem-to-cloud relay boundary subject to GDPR Art 28 processor-agreement scrutiny.
• DKIM troubleshooting — the HYBRID-EXCHANGE-DUAL-EGRESS- PER-MESSAGE-DKIM-FAIL-VS-DKIM-PERMERROR- SYMPTOM-DRIVEN-ROOT-CAUSE-ATTRIBUTION- PLAYBOOK companion to this hybrid Exchange deployment reference. Where THIS page documents the hybrid Exchange dual-egress-path DMARC posture (the on-prem Exchange + Exchange Online dual- signer DKIM model, the CMT-vs-classic- hybrid outbound-boundary decision, the ARC-sealer Trusted-ARC-Sealers boundary, the Default Frontend Connector DKIM- strip and Send-Connector relay-loop failure modes), the DKIM-troubleshooting spoke is the PER-MESSAGE-DIAGNOSTIC- WALKTHROUGH companion documenting the operator-facing symptom-to-action sequence run AGAINST the per-message Authentication-Results stamp the hybrid topology produces at the receiver. Concretely, the spoke documents FOUR hybrid-egress-path- specific DKIM-symptom dimensions: (i) on-prem signer path dkim=permerror NXDOMAIN symptom — when on-prem Exchange Transport Agent signs with a selector*.<org-domain> selector the operator never published as a TXT record at <selector>._domainkey.<org-domain>, the receiver-side DNS lookup returns NXDOMAIN and the troubleshooting page's canonical dig TXT <selector>._domainkey.<d-domain> symptom-to-action walk from multiple geographic resolvers (Google 8.8.8.8, Cloudflare 1.1.1.1, Quad9 9.9.9.9) pins the missing- TXT root cause to the on-prem-signed egress path; (ii) cloud signer path dkim=fail body-hash- mismatch symptom during dual-selector Defender Rotate-DKIM-keys race — when the cloud signer rotates the selector1/selector2.<tenant>._domainkey.<org-domain> CNAME-delegated keys via the Defender portal Rotate-DKIM-keys affordance and the per-receiver positive-cache TTL window has not aged out, the troubleshooting page's compare-the- returned-record-bytes-against-what-the- receiver-fetched diagnostic step surfaces the per-receiver-resolver- cached-old-key root cause against the per-signer-emitted-new-key b=<signature> bytes; (iii) Send-Connector relay- loop path dkim=fail body-hash-mismatch symptom from canonicalization mangle during inter- hop transit — when the Classic-Hybrid Send-Connector loops a cloud-signed message back through the on-prem Edge Transport boundary and a transport rule rewrites whitespace or folds long header lines, the troubleshooting page's c=relaxed/relaxed vs c=simple/simple canonicalization symptom-axis pins the body-hash-mismatch verdict to the Send-Connector boundary rather than to the cloud signer; (iv) tenant- default-domain pathology dkim=pass with policy_evaluated.dkim=fail DMARC-non-aligned symptom — when on-prem mail egresses via the Exchange Online Protection connector and is signed with the tenant's selector1-<tenant>._domainkey.<tenant>.onmicrosoft.com CNAME-delegated default key instead of the operator's published organization- domain selector, the troubleshooting page's identify-which-key-the-signer- used-at-message-sign-time step matches the d=-tag literal against the publisher's org-domain set and names the unaligned-d= signing-identity root cause. Read the DKIM-troubleshooting symptom-driven playbook AFTER consulting THIS hybrid Exchange deployment reference to attribute every per-message dkim=fail / dkim=permerror verdict surfaced in inbound test mail to the specific hybrid egress path responsible.
• DMARC multi-domain strategy — the MULTI-DOMAIN-PUBLICATION- DISCIPLINE companion to this hybrid Exchange deployment reference. Where THIS page documents the SINGLE-org- domain hybrid Exchange dual-egress topology (one on-prem Exchange leg + one Exchange Online leg both emitting under the same Friendly-From-header organisational domain), the multi- domain-strategy spoke is the PER-ORG- DOMAIN COORDINATION REFERENCE documenting how the same hybrid dual-egress topology multiplies across every distinct Friendly-From-header org-domain the tenant emits under. Concretely the spoke documents FOUR hybrid-Exchange-multi-domain coordination dimensions: (i) per-org-domain _dmarc.<org-domain> TXT-RR publication discipline at every Friendly-From-header organisational domain the hybrid tenant emits under — every distinct brand / business-unit / acquired-company Friendly-From-header organisational domain requires its OWN apex _dmarc TXT-RR publication with per-domain p= / pct= / sp= / adkim= / aspf= / rua= / ruf= tag-byte publication, and the per-domain publication-discipline-state must be coordinated across every org-domain the hybrid tenant emits under because DMARC evaluation runs PER-ORG-DOMAIN keyed by <header_from> attribution; (ii) per-tenant tenant.onmicrosoft.com default-domain DKIM-CNAME-delegation coordination gap is itself a MULTI-DOMAIN PHENOMENON — the hybrid tenant operates BOTH the operator-published Friendly-From- header org-domains AND the Microsoft-issued tenant.onmicrosoft.com default domain, and per-message DKIM signing under the unconfigured default-domain CNAME-delegation produces dkim=pass against the WRONG d= domain emitting policy_evaluated.dkim=fail DMARC-non-aligned — the multi-domain- strategy spoke documents the per-org-domain DKIM-CNAME-delegation coordination that closes this gap across every operator-published org-domain the hybrid tenant emits under; (iii) per-subdomain sp=-tag inheritance vs override coordination across every sibling subdomain under every operator-published org-domain — every per-org-domain apex _dmarc TXT-RR publishes a sp=-tag commitment governing the per-subdomain inheritance contract receivers apply when evaluating mail emitted from <sub>.<org-domain> subdomains the hybrid tenant produces (per-business-unit marketing.<org-domain> / support.<org-domain> / noreply.<org-domain> / per-team subdomains), and the multi-domain-strategy spoke documents the per-subdomain publication-discipline gap-closure coordination every hybrid tenant must apply to defeat the parked- subdomain-traversal attacker-bypass class; and (iv) per-org- domain phased-enforcement ramp coordination — the per-org-domain p=none → p=quarantine pct=<n> → p=reject ramp-stage commitment-curve runs INDEPENDENTLY per org-domain — the hybrid Exchange tenant operator coordinating multi-brand DMARC posture MUST sequence each org-domain's per-stage ramp independently because per-org-domain legitimate-sender inventory closure completion depends on per-org-domain aggregate-report evidence convergence — premature advancement on the most-mature org-domain's ramp does NOT permit skipping monitoring stages on the least-mature org-domain's independent ramp. Read the multi- domain-strategy spoke ALONGSIDE this hybrid Exchange deployment reference when authoring the multi-brand hybrid-tenant DMARC posture — the spoke documents the per-org-domain coordination contract every hybrid Exchange tenant emitting under more than one Friendly-From-header organisational domain must apply.
• SPF PermError vs TempError - the PER-HYBRID-TENANT-PER-ORG-DOMAIN- SPF-INCLUDE-CASCADE-LOOKUP-LIMIT- OVERFLOW-CANONICAL-DRIVER-OF-SPF- PERMERROR companion to this hybrid Exchange deployment reference. Where THIS page documents the per-hybrid- tenant per-org-domain DMARC publication discipline at hybrid Exchange topology (per-org-domain on-prem-Exchange + Exchange Online dual-egress-MTA publication discipline, per-org-domain Friendly-From-header cross-egress coordination, per-org-domain hybrid- connector publication discipline, per- org-domain Office-365-tenant SPF/ DKIM/DMARC publication-discipline- stack), the SPF-PermError-vs-TempError spoke documents the per-hybrid-tenant per-org-domain RFC 7208 §4.6.4 SPF- evaluation-failure-class catalogue whose per-hybrid-tenant per-org-domain per-message spf=permerror emergence is the CANONICAL outcome of per-hybrid- tenant per-org-domain SPF-include- cascade-lookup-limit-overflow at the per-org-domain 10-DNS-lookup boundary at FOUR per-hybrid-tenant per-org- domain SPF-include-cascade-permerror- coupling dimensions: (i) per- hybrid-tenant per-org-domain SPF- include-cascade-lookup-limit-overflow per RFC 7208 §4.6.4 as canonical per- message SPF-permerror trigger at hybrid Exchange topology multi-include publication boundary — per- hybrid-tenant per-org-domain SPF- record-publication discipline AT hybrid Exchange topology operationally composes per-org-domain include:spf.protection.outlook.com (Exchange Online per-tenant infrastructure, ~7 DNS lookups) + per-org-domain on-prem-Exchange include:<on-prem-edge-MTA> (per-tenant per-on-prem-edge publication, ~2-3 DNS lookups) + per-org-domain per-3rd-party-ESP include: cascade (per- tenant per-ESP publication, ~1-2 DNS lookups per ESP) — per-hybrid-tenant per-org-domain 10-DNS-lookup-limit- boundary per RFC 7208 §4.6.4 produces per-message spf=permerror verdict- class at receiver-side per-org-domain SPF-evaluation boundary; per-hybrid- tenant per-org-domain SPF-publication- discipline-overflow-driven SPF- permerror-emergence is the per- hybrid-tenant per-org-domain CANONICAL per-message SPF-permerror-class observability surface; (ii) per-hybrid-tenant per-org-domain SPF- permerror-emergence collapsing per- message SPF-aligned-pass-evaluation- path as load-bearing per-hybrid-tenant per-message DKIM-aligned-pass- evaluation-reliance trigger — per-hybrid-tenant per-org-domain per-message spf=permerror verdict- class emergence eliminates per-message SPF-aligned-pass-evaluation path per RFC 7489 §3.1.1 (per-message DMARC- evaluation CANNOT use per-message spf=permerror as load-bearing per- message DMARC-aligned-pass-path); per- hybrid-tenant per-message DMARC- evaluation discipline THIS page documents the per-org-domain publication of STRUCTURALLY-FORCED to rely on per-message DKIM-aligned-pass verdict as LOAD-BEARING per-hybrid- tenant per-message single-surviving- verdict-path — per-hybrid-tenant per- org-domain DKIM-publication discipline (per-org-domain Exchange Online DKIM signing + per-org-domain on-prem- Exchange DKIM signing + per-3rd-party- ESP per-tenant DKIM signing) becomes the LOAD-BEARING per-hybrid-tenant per-org-domain DMARC-aligned-pass- rate stabilizer per-hybrid-tenant per- org-domain SPF-permerror-emergence creates; (iii) per-hybrid- tenant per-org-domain SPF-temperror- emergence at per-receiver DNS- resolution-infrastructure-failure boundary as load-bearing per-receiver per-day per-org-domain SPF-aligned- pass-rate volatility-source amplifying per-hybrid-tenant per-message DKIM- aligned-pass-operational-criticality — per-hybrid-tenant per-org-domain per-message spf=temperror verdict- class (per-receiver DNS-resolution- timeout, per-receiver intermittent- DNS-failure, per-receiver SPF-record- fetch-network-error per RFC 7208 §4.6.4) produces per-receiver per-day per-org-domain per-message-class SPF- aligned-pass-rate volatility — per- hybrid-tenant per-org-domain DKIM- aligned-pass discipline becomes per- hybrid-tenant per-receiver per-day per- org-domain SPF-temperror-driven SPF- aligned-pass-rate volatility-absorbing per-message DMARC-aligned-pass-rate stabilizer the per-hybrid-tenant per- org-domain DMARC publication discipline THIS page documents the per-org-domain publication of consumes; (iv) per-hybrid-tenant per-org- domain SPF-include-cascade-publication- discipline-audit as load-bearing per- hybrid-tenant per-org-domain SPF- permerror-prevention discipline — per-hybrid-tenant per-org-domain operations team responsible for per- org-domain SPF-publication discipline THIS page documents the per-org-domain publication of must per-org-domain audit per-org-domain SPF-include- cascade-lookup-count discipline (typically: 7 lookups for Exchange Online include + 2-3 lookups for on- prem-Exchange include + ≥1 lookup per per-3rd-party-ESP include — per- hybrid-tenant per-org-domain pattern rapidly approaches per-org-domain 10- DNS-lookup-limit boundary) — per- hybrid-tenant per-org-domain SPF- flattening / per-org-domain SPF- macro-substitution / per-org-domain per-include source-elimination per- publisher per-org-domain per-message SPF-permerror-prevention disciplines the per-hybrid-tenant per-org-domain SPF-publication-discipline audit consumes. Read the SPF-PermError-vs- TempError spoke alongside this hybrid Exchange deployment reference when planning per-hybrid-tenant per-org- domain SPF-publication-discipline at per-hybrid-tenant per-org-domain topology whose per-org-domain SPF- include-cascade-lookup-count discipline approaches per-org-domain 10-DNS- lookup-limit boundary per RFC 7208 §4.6.4, and when investigating per- hybrid-tenant per-org-domain per- message DMARC-aligned-pass-rate regression whose upstream root-cause is per-hybrid-tenant per-org-domain SPF-permerror-emergence at hybrid Exchange topology multi-include publication boundary the per-hybrid- tenant per-org-domain DMARC publication discipline THIS page documents the per-org-domain publication of consumes.
• SPF 10-DNS-lookup limit — the canonical publisher-side remediation-strategy reference documenting how the RFC 7208 §4.6.4 ten-DNS-lookup ceiling (counted recursively across include:, a, mx, ptr, exists:, and redirect= mechanisms during the receiver-side recursive SPF evaluation) is THE canonical hard blocker hybrid Exchange operators routinely overflow at the per-org- domain SPF-publication boundary — the MANDATORY include:spf.protection.outlook.com for Exchange-Online-Protection egress alone is RFC 7208 §4.6.4-counted as 2 lookups (the include + its recursive sub-include for the per-region MX IP-CIDR sub-policy at spf-a.outlook.com / spf-b.outlook.com / regional siblings), the per-on-prem- Exchange edge-transport-relay include: for the on-premises egress path adds at least 1 more, and each per-third-party-ESP include: (Mailchimp, SendGrid, Marketo, Salesforce Marketing Cloud, etc.) adds 1-3 more each — a hybrid topology routinely publishes 8-12 lookups at the per-org-domain apex SPF record, triggering the per-org-domain spf= permerror verdict the SPF-PermError- vs-TempError sibling entry above catalogues as the canonical hybrid Exchange failure mode. Read the SPF-lookup-limit spoke ALONGSIDE this hybrid Exchange deployment reference when planning the per-org-domain SPF publication discipline — the spoke documents the four canonical remediation strategies (envelope-domain split via per-mail-stream subdomain delegation, third-party-include flattening via static IP/CIDR publication harvested from the third-party SPF record at a point-in-time snapshot, SPF-record macro consolidation to collapse per-region sub-includes, and the redirect=-as-single-lookup- replacement pattern for tenants with a single delegated SPF authority) that hybrid Exchange publishers apply at the per-org-domain ten-lookup-overflow boundary to restore spf=pass to the per-message DMARC-aligned-pass- evaluation path the hybrid Exchange deployment discipline THIS page documents depends on.
• DMARC for cPanel - the SELF-MANAGED-CPANEL-VS-HYBRID- EXCHANGE-EGRESS-TOPOLOGY-COMPARISON companion to this hybrid Exchange deployment reference. Where THIS page documents the dual-egress hybrid Exchange topology (on-prem Edge Transport + Exchange Online Protection per-tenant per-domain SPF / DKIM / DMARC publication discipline with the EOP-managed selector1 / selector2 CNAME chains and the on-prem Edge Transport DKIM signer), the cPanel deployment guide documents the contrasting per-cPanel- tenant single-egress topology (the per-cPanel-server outbound mail relay with per-tenant per-domain SPF authorisation of the cPanel-server outbound IP, the cPanel-managed default._domainkey selector emitted by the WHM/cPanel Email Deliverability UI, the per- tenant per-domain DMARC publication workflow surfaced through the cPanel Email Deliverability control panel). Read the cPanel deployment guide ALONGSIDE this hybrid Exchange reference when EVALUATING per-tenant per-domain DMARC deployment migration between self-managed cPanel egress and managed Microsoft hybrid egress — the deployment-topology choice STRUCTURALLY DETERMINES the per- tenant per-domain per-selector DKIM publication model, the per-tenant SPF authorisation scope, and the per- tenant DMARC-aligned-pass-rate floor every per-tenant per-domain DMARC enforcement ramp STRUCTURALLY DEPENDS on.
• 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 live SPF lookup count (critical for hybrid SPF), the published DKIM selectors, and the DMARC policy state.
• DNS Record Generator - SPF / DKIM / DMARC / TLS-RPT / MTA-STS / CAA / BIMI record wizards.
• DMARC Analyzer Dashboard - ingests aggregate reports from every receiver via includes/DmarcParser.php and surfaces the per-sender / per-IP / per-day breakdown needed to drive hybrid sender-path inventory.
• BIMI explained — the PER-PUBLISHER-PER-DOMAIN-BIMI-LOGO- RENDERING-DISCIPLINE-AS-LOAD-BEARING- DOWNSTREAM-CONSUMER-OF-JOINT-ON-PREM-AND- CLOUD-DMARC-ENFORCEMENT-COVERAGE companion to this hybrid Exchange / Exchange Online DMARC-deployment reference. Where THIS page documents the dual-topology hybrid sender-path inventory discipline (the on- prem Exchange Hub Transport vs cloud Exchange Online egress paths, the joint per-path SPF mechanism coverage ip4:<on-prem-edge> + include:spf.protection.outlook.com, the joint per-path DKIM signing posture with selector1/selector2 on the cloud side + on-prem Exchange signing agent on the on-prem side, the joint per-path DMARC p=none → p=quarantine → p=reject rollout cadence), the BIMI spoke documents the FOUR PER-PUBLISHER-PER-DOMAIN-HYBRID- BIMI-LOGO-RENDERING DIMENSIONS the per- publisher hybrid-tenant operator MUST coordinate to extract per-receiver per- message BIMI-rendering eligibility from BOTH on-prem and cloud sender-path egress: (i) per-publisher per-domain hybrid-tenant BIMI-rendering ELIGIBILITY GATED on JOINT on-prem-Exchange + cloud- EXO DMARC p=quarantine / p=reject publication — the receiver-side BIMI-rendering decision requires per-domain DMARC p=quarantine or p=reject enforcement; a per-domain DMARC p=none publication state during the hybrid- rollout-cadence prep window DEFEATS BIMI- rendering eligibility across BOTH on-prem and cloud sender-path egress until the joint per-path advancement to p=quarantine clears; (ii) per-publisher per-domain hybrid- tenant BIMI-rendering-rate FLOOR driven by joint on-prem + cloud per-receiver per-day DKIM-aligned-pass-rate floor — the per-publisher per-domain hybrid- tenant per-receiver per-day BIMI-rendering- rate is structurally bounded by the JOINT on-prem-Exchange-signing-agent DKIM- aligned-pass-rate floor AND the cloud-EXO selector1/selector2 DKIM-aligned-pass- rate floor; per-receiver per-day per- domain BIMI-rendering-rate optimisation REDUCES TO joint per-path DKIM-aligned- pass-rate floor maintenance across BOTH sender-path egress sources; (iii) per-publisher per-domain hybrid- tenant BIMI VMC certificate-binding cryptographic-attestation CASCADE coordination across joint on-prem + cloud DKIM publication topologies — the per-publisher per-domain hybrid- tenant BIMI VMC (Verified Mark Certificate) cryptographic-binding attestation chain MUST sustain a per-receiver per-message DKIM-aligned-pass verdict regardless of whether the per-message egress path was on-prem Exchange (signing-agent-managed selector) or cloud EXO (selector1/ selector2 CNAME delegation) — the joint per-path DKIM-aligned-pass parity discipline is the load-bearing cryptographic-attestation precondition; (iv) per-publisher per-domain hybrid-tenant per-day per-receiver per-source-IP BIMI-rendering-rate ATTRIBUTION via joint per-path rua= aggregate-report observability primitive — the per-publisher per-domain hybrid-tenant operator reads the per-day per-receiver per-source-IP per-policy_evaluated row- by-row distribution in the rua= aggregate-report block as the SINGLE observability surface for attributing per-publisher per-receiver per-day per-domain BIMI-rendering-rate deviations to the SPECIFIC on-prem-vs- cloud sender-path egress source whose per-message authentication posture caused the per-message BIMI-rendering- ineligibility — closing the per-publisher per-domain hybrid-tenant BIMI-rendering- rate optimisation feedback loop. Read the BIMI spoke ALONGSIDE this hybrid Exchange / Exchange Online DMARC- deployment reference whenever the per- publisher hybrid-tenant operator EVALUATES the per-domain BIMI-logo-rendering publication investment as a downstream consumer of the JOINT on-prem-and-cloud DMARC enforcement coverage THIS page's hybrid sender-path inventory discipline directly drives.
• DKIM DNS-record byte syntax — the HYBRID-DKIM-DUAL-SELECTOR-DNS- PUBLICATION-DISCIPLINE companion to this hybrid Exchange / Exchange Online DMARC deployment reference. Where THIS page documents the JOINT on-prem-and-cloud sender-path enforcement workflow (the per-publisher hybrid-tenant operator publishing BOTH the EOP-managed selector1._domainkey and selector2._domainkey CNAME chains AND maintaining the on-prem Exchange Edge Transport DKIM signer configuration), the DKIM DNS-syntax spoke documents the RFC 6376 §3.6.1 per-tag byte-grammar reference every receiver-side DKIM verifier consumes when validating EITHER sender-path's signed outbound message — the v=DKIM1 version tag, the k=rsa key-type tag, the p=<base64-pubkey> public-key bytes, the optional h= hash-algorithm constraint, the s=email service-type tag, the t= flags tag, and the 255-octet character-string-fragmentation rule. Pair this hybrid deployment guide with the DKIM-DNS-syntax spoke when verifying that the M365-managed CNAME chains at BOTH selector1._domainkey AND selector2._domainkey resolve to Microsoft-published TXT records whose byte grammar matches the RFC 6376 §3.6.1 contract — the per- tenant per-selector CNAME-chain terminal TXT-record byte-grammar compliance is the STRUCTURAL receiver- side verification PREREQUISITE every EOP-signed outbound message depends on for the dkim=pass verdict that gates the per-message per-receiver DMARC-aligned-pass-rate floor this hybrid deployment guide's JOINT on-prem- and-cloud DMARC enforcement coverage STRUCTURALLY DEPENDS on.
• DMARC reporting pipeline — the HYBRID-DUAL-EGRESS-AGGREGATE- REPORT-PUBLISHER-SIDE-CONSOLIDATION companion to this hybrid Exchange deployment reference. Where THIS page documents the per-publisher per-domain per-tenant hybrid Exchange dual-egress mailflow topology (on-prem Exchange edge-server outbound SMTP egress + cloud Exchange Online EOP outbound SMTP egress from the same per-tenant per-domain organisational-domain identifier, with each per-EGRESS-PATH source-IP attribution emitting an independent per- receiver per-day per-publisher per-day aggregate-report row), the DMARC- reporting-pipeline spoke is the PUBLISHER-SIDE-AGGREGATE-REPORT- INGESTION-AND-CONSOLIDATION DOWNSTREAM- CONSUMER documenting how the per- publisher per-domain per-EGRESS-PATH per-receiver per-day per-publisher per- day aggregate-report rows MUST flow THROUGH the per-publisher per-domain RUA + RUF reporting pipeline at FOUR per-pipeline-stage per-hybrid-egress- attribution dimensions: (i) per- EGRESS-PATH per-receiver per-day per- publisher per-day aggregate-report ingestion deduplication-by-report_id- plus-org_name discipline — the per-publisher per-domain RUA-pipeline- side ingestion-deduplication contract per RFC 7489 §7.2 report_id + org_name compound-key deduplication that prevents per- receiver per-day per-publisher per-day per-EGRESS-PATH aggregate-report double-counting when the same per- publisher per-domain RUA mailbox receives the same per-receiver-emitted aggregate-report through multiple per- publisher per-domain MX-fallback paths (a recurring per-publisher per-domain hybrid-tenant per-receiver-emitted aggregate-report ingestion pattern when the per-publisher per-domain MX-record list spans on-prem Exchange edge MX + cloud Exchange Online MX); (ii) per-EGRESS-PATH source-IP attribution per-receiver per-day per- publisher per-day per-source-IP SPF-pass-rate / DKIM-pass-rate / DMARC- aligned-pass-rate-floor segmentation — the per-publisher per-domain RUA- pipeline-side per-EGRESS-PATH source-IP attribution discipline that surfaces per-EGRESS-PATH (on-prem Exchange edge IP range vs Exchange Online EOP IP range) per-day per-publisher per-day DMARC-aligned-pass-rate floors SEPARATELY so the per-publisher per- domain hybrid-tenant operator can independently track per-EGRESS-PATH publication-discipline-completeness; (iii) per-message forensic- report ARF dispatch per-EGRESS-PATH per-failure-message diagnostic block attribution — the per- publisher per-domain RUF-pipeline-side per-failure-message per-EGRESS-PATH forensic-diagnostic-block attribution that lets the per-publisher per-domain hybrid-tenant operator pinpoint which per-EGRESS-PATH (on-prem Exchange edge vs cloud Exchange Online EOP) emitted each per-failure-message DKIM-aligned- fail / SPF-aligned-fail verdict at the per-receiver-side authentication evaluation boundary; and (iv) per-publisher per-domain per- EGRESS-PATH DMARC-aligned-pass-rate- floor regression alerting cadence — the per-publisher per-domain RUA- pipeline-side per-EGRESS-PATH per-day per-publisher per-day DMARC-aligned- pass-rate-floor regression alerting cadence that EMITS per-EGRESS-PATH- SEGMENTED alerts when the on-prem Exchange edge per-day per-publisher per-day DMARC-aligned-pass-rate floor regresses INDEPENDENTLY from the cloud Exchange Online EOP per-day per- publisher per-day DMARC-aligned-pass- rate floor (which the per-publisher per-domain hybrid-tenant operator MUST diagnose against per-EGRESS-PATH publication-discipline drift). Pair this hybrid Exchange deployment guide with the DMARC-reporting-pipeline spoke when CONSOLIDATING per-receiver per-day per-publisher per-day per- EGRESS-PATH aggregate-report rows from the dual-egress hybrid topology — the DMARC-reporting-pipeline spoke is the PUBLISHER-SIDE-AGGREGATE-REPORT- CONSOLIDATION REFERENCE whose per- publisher per-domain per-EGRESS-PATH per-receiver per-day per-publisher per- day aggregate-report deduplication- and-attribution discipline the per- publisher per-domain hybrid-tenant operator structurally depends on to produce the per-EGRESS-PATH DMARC- enforcement-coverage observability THIS page's JOINT on-prem-and-cloud DMARC- enforcement-coverage architecture materially requires.
• SPF mechanism tokens: include vs ip4 vs a vs mx — the HYBRID-EXCHANGE-DUAL-EGRESS- SPF-MECHANISM-TOKEN-CHOICE-MATRIX companion to this hybrid Exchange deployment reference. Where THIS page documents the per-publisher per-domain hybrid Exchange dual-egress mailflow topology (on-prem Exchange edge-server outbound SMTP egress + cloud Exchange Online EOP outbound SMTP egress from the same per-tenant per-domain organisational-domain identifier, with each per-EGRESS-PATH demanding its own per-publisher per-domain SPF authorisation footprint), the SPF- mechanism-token-choice spoke is the PER-MECHANISM-TOKEN-AUTHORING-DISCIPLINE companion documenting the per-publisher per-domain per-EGRESS-PATH per-mechanism- token authoring decision-matrix the per- publisher per-domain hybrid-Exchange- tenant operator MUST compose at FOUR per-EGRESS-PATH per-mechanism-token- choice dimensions: (i) per- publisher per-domain hybrid Exchange on-prem edge-server outbound SMTP egress per-mechanism-token authoring discipline — the per-publisher per-domain hybrid-tenant operator MUST author per-publisher per-domain SPF record mechanism tokens ip4:<on-prem-exchange-edge- public-ip-range> or ip6:<on-prem-exchange-edge- public-ipv6-range> per RFC 7208 §5.6 to authorise the per- publisher per-domain hybrid on-prem Exchange edge-server outbound SMTP egress source-IP range that the per- receiver-side per-message SPF- evaluation per RFC 7208 §5 mechanism- evaluation discipline consumes to emit the per-message SPF-aligned-pass verdict the per-receiver per-message DMARC verdict materially depends on; (ii) per-publisher per-domain hybrid Exchange Online EOP cloud outbound SMTP egress per-mechanism- token authoring discipline — the per-publisher per-domain hybrid- tenant operator MUST author per- publisher per-domain SPF record mechanism token include:spf.protection.outlook.com per RFC 7208 §5.2 to authorise the Microsoft-published Exchange Online EOP outbound SMTP egress source-IP macro that the per-receiver-side per- message SPF-evaluation consumes to emit the per-message SPF-aligned-pass verdict for the cloud-egress half of the per-publisher per-domain hybrid- Exchange dual-egress mailflow; (iii) per-publisher per-domain hybrid Exchange dual-egress SPF 10-DNS-lookup-budget per RFC 7208 §4.6.4 mechanism-token-choice- discipline — the per-publisher per-domain hybrid-tenant operator MUST compose the per-publisher per-domain SPF record mechanism-token portfolio within the RFC 7208 §4.6.4 ten-DNS- lookup-budget that include: / a: / mx: mechanisms each consume, FAVOURING the per-publisher per-domain on-prem Exchange edge ip4: / ip6: tokens that consume ZERO DNS-lookups against the include:-tokens that consume one-DNS-lookup PLUS the recursive DNS-lookup-budget of the included macro to avoid per-publisher per-domain SPF-permerror verdict-emission at the per-receiver- side per-message SPF-evaluation boundary; and (iv) per- publisher per-domain hybrid Exchange per-EGRESS-PATH per-day per-publisher per-day per-source-IP DMARC-aligned- pass-rate-floor monitoring as per- mechanism-token-choice readiness- verification observability — the per-publisher per-domain hybrid- tenant operator MUST track per- receiver per-day per-publisher per- day per-EGRESS-PATH per-source-IP SPF-aligned-pass-rate-floor as the empirical-observability proxy for the per-publisher per-domain per-mechanism- token-choice authoring-discipline correctness across both per-EGRESS- PATH (on-prem Exchange edge ip4:-authorised egress + cloud Exchange Online EOP include:-authorised egress) before ramping per-publisher per-domain DMARC policy to p=quarantine / p=reject enforcement. Pair this hybrid Exchange deployment guide with the SPF-mechanism-token spoke when AUTHORING the per- publisher per-domain hybrid-tenant per-EGRESS-PATH SPF record mechanism- token portfolio — the SPF-mechanism- token spoke is the PER-MECHANISM- TOKEN-AUTHORING-DISCIPLINE REFERENCE whose per-publisher per-domain per- mechanism-token-choice decision matrix the per-publisher per-domain hybrid-Exchange-tenant operator structurally depends on to compose the per-EGRESS-PATH SPF authorisation footprint THIS page's JOINT on-prem- and-cloud DMARC enforcement-coverage architecture materially requires.
• Phishing protection — the HYBRID-EXCHANGE-DUAL-EGRESS- DMARC-AS-LOAD-BEARING-ANTI-PHISHING- PRIMITIVE companion reference. Where THIS page documents the hybrid Exchange + EOP topology (FIVE distinct mail-flow paths, dual-egress identifier- misalignment scenarios, ARC trust preservation, transport-rule preservation, mailflow connectors), the phishing-protection spoke is the PER- HYBRID-PUBLISHER-PER-ORG-DOMAIN- PHISHING-ATTACK-THREAT-MODEL companion whose per-hybrid-tenant per-org-domain anti-phishing posture the dual-egress DMARC-aligned-pass publication discipline directly supports. Four hybrid-egress anti-phishing coupling dimensions the spoke addresses: (1) hybrid-tenant per-org-domain display- name spoofing deterrence — attackers forge the RFC 5322 From: display-name to read "CFO <attacker@evil.tld>" impersonating the per-hybrid-tenant executive — the JOINT on-prem-Edge- Transport-DKIM-signed + Exchange- Online-EOP-DKIM-signed dual-egress DMARC-aligned-pass evidence at the receiver-side cryptographically distinguishes legitimate hybrid-tenant per-org-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 across BOTH egress paths; (2) hybrid-tenant per- org-domain lookalike-domain registration deterrence — attackers register contos0.com (zero in place of "o"), contoso.co (truncated TLD), or registrar-typosquats imitating the per-hybrid-tenant org- domain — the per-org-domain JOINT dual-egress DMARC-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 regardless of which hybrid egress path emitted the legitimate traffic; (3) hybrid-tenant per-org- domain subdomain-takeover deterrence — attackers exploit abandoned per-org- domain subdomains (decommissioned marketing-microsite subdomain, decommissioned per-subsidiary-domain subdomain, dangling DNS-record subdomain) to send subdomain-takeover- attack mail under the publisher's organisational umbrella — the per- hybrid-tenant per-org-domain sp=-tag subdomain-policy publication discipline (subdomain- policy enforcement across the per- hybrid-tenant per-org-domain subdomain space) the dual-egress hybrid Exchange deployment establishes is the per- publisher per-subdomain anti-takeover primitive defeating subdomain- takeover-attack-class spoofing; (4) per-publisher per-domain per-source-IP per-day DMARC-aligned-fail-rate spike as empirical-detection signal — the per-hybrid-tenant per-org-domain DMARC RUA aggregate-report stream (dual- egress) 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-org-domain spoofing-attack-campaigns; the per- message RUF ARF diagnostic-block stream from per-org-domain ruf= publication enables per-attack-campaign forensic-evidence- collection for SOC incident-response with full hybrid-egress-path attribution. Read the phishing- protection spoke when MOTIVATING the per-hybrid-tenant per-org-domain dual-egress DMARC 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 across both hybrid egress paths.
• BIMI Verified Mark Certificates (VMC and CMC) - the PER-HYBRID-TENANT-PER-CUSTOM-DOMAIN- BIMI-VMC-CMC-LOGO-AUTHENTICATION-DISCIPLINE companion to this hybrid Exchange Online DMARC deployment reference. Where THIS page documents the per-hybrid-tenant dual-egress (on-prem Edge Transport + Exchange Online) DMARC publication discipline whose p=quarantine → p=reject enforcement floor is the per-hybrid-tenant per-custom-domain cryptographic-anti-phishing posture, the BIMI VMC certificates spoke documents the BIMI-PROTOCOL-LAYER LOGO-AUTHENTICATION extension whose per-hybrid-tenant per- custom-domain VMC or CMC procurement workflow STRUCTURALLY DEPENDS on the per-domain DMARC enforcement floor THIS page's hybrid topology deploys, at FOUR per-hybrid-tenant per-custom-domain BIMI- coupling dimensions: (i) per- hybrid-tenant per-custom-domain p=quarantine or p=reject DMARC-enforcement- floor as MANDATORY BIMI-evaluator-gating precondition - Gmail / Apple Mail / Yahoo / Fastmail receiver-side BIMI evaluators refuse to render the per- custom-domain VMC-asserted logo until the per-domain DMARC TXT publication declares p=quarantine or p=reject AND sp=quarantine / sp=reject AND the per- receiver per-publisher per-day DMARC- aligned-pass-rate threshold sustains a sustained-high baseline (RFC-9091 np=reject additionally recommended); (ii) per-hybrid- tenant per-custom-domain VMC-procurement- workflow trademark-registry-pre-validation as load-bearing per-domain prerequisite independent of the DMARC publication layer - the per-hybrid-tenant operator must coordinate per-custom-domain per-jurisdiction trademark-registry (USPTO/EUIPO/UK-IPO/JPO/CIPO) registered logo presence BEFORE engaging DigiCert or Entrust for VMC issuance (CMC is the Common-Mark cousin allowing in-use marks without a registered trademark but with a different receiver-side acceptance profile - Gmail accepts CMC since 2024, Apple Mail still gates on VMC only); (iii) per-hybrid-tenant per-custom-domain SVG-Tiny-PS asset canonicalisation + per-VMC X.509 cert SHA-256 hash binding + per-asset HTTPS serving discipline as per-publisher per-domain cryptographic- evidence-of-logo-authenticity primitive the hybrid-tenant operator publishes on its own customer-domain HTTPS infrastructure - the per-domain default._bimi.<custom-domain> TXT-record's l= SVG asset URL and a= PEM cert URL must both serve over HTTPS with the published certificate-chain validating against the public-CA root, AND the SVG bytes' SHA-256 must match the SubjectAltName-embedded hash in the VMC cert (a hash-binding contract Gmail and Apple Mail enforce per-message at the per-receiver evaluation moment); and (iv) per-hybrid-tenant per- custom-domain VMC 1-year renewal calendar coordination as per-publisher per-domain logo-display-availability- continuity primitive parallel to per- custom-domain DKIM key-rotation cadence - VMCs issue with a 1-year validity, and the per-hybrid- tenant operator must coordinate per- custom-domain VMC renewal AT LEAST 30 days before expiry to avoid receiver- side BIMI-display fallback to the generic-monogram default, with the renewal coordination cadence paralleling the per-tenant per-custom-domain DKIM key-rotation cadence the hybrid topology already manages at the Exchange Online DKIM signing-key publication layer. Pair THIS hybrid Exchange Online DMARC deployment reference with the BIMI VMC certificates spoke when the per-hybrid- tenant operator advances the per-custom- domain DMARC ramp to p=quarantine or p=reject and engages the BIMI logo-display-publication phase as the per-publisher per-custom-domain cryptographic-anti-spoofing posture's end-user-visible reinforcement layer.
• DKIM replay attacks explained (RFC 6376 §8.6 + RFC 8617 ARC) — the DKIM-replay-attacks spoke documents the RFC 6376 §8.6 DKIM-replay threat-class whose attacker-captures- legitimately-signed-message-and-re-sends- to-arbitrary-recipients mechanic STRUCTURALLY EVADES every per-custom-domain DMARC p= tag value the per-hybrid- tenant publishes through the on-prem Exchange + Exchange Online dual-egress topology THIS page documents. Four PER- HYBRID-TENANT-DUAL-EGRESS-DKIM-REPLAY- DEFENSE coupling axes the replay-attacks spoke documents: (i) per-hybrid- tenant per-custom-domain on-prem Exchange signing-MTA per-selector DKIM private-key custody is STRUCTURALLY DIFFERENT from the Exchange Online CNAME-delegated-key custody and the dual-key-custody surface STRUCTURALLY DOUBLES the per-custom- domain DKIM-replay attack surface — on-prem Exchange admins manage the per-tenant per-custom-domain private key in the on-prem Active Directory + Edge Transport boundary while Exchange Online manages the CNAME-delegated key under onmicrosoft.com at the Microsoft- managed key-custody boundary; the per-hybrid- tenant per-custom-domain anti-replay-key- custody operator-discipline must cover BOTH custody boundaries to prevent per-key compromise becoming a per-tenant per-domain replay-window-opening event; (ii) per- hybrid-tenant per-custom-domain per-egress- path key-lifetime discipline (90–180-day rotation cadence with 7-day overlap window at the on-prem boundary, 30-day Microsoft- managed auto-rotation at the Exchange Online boundary) is the LOAD-BEARING dual-egress operator-discipline floor whose regression extends the per-egress-path per-key replay window from 30–180 days to indefinite at the on-prem boundary — per-tenant per-custom-domain on-prem-egress key-lifetime regression operates the per- tenant on-prem DKIM key at indefinite replay window, structurally violating the per-key bounded-replay-window primitive the replay-attacks spoke catalogues; (iii) per-hybrid-tenant per-custom-domain per-egress-path per-message x= expiration-tag publication is the LOAD- BEARING per-message-granularity anti-replay control whose per-egress-path enablement divergence (on-prem Exchange Edge Transport default-OFF vs Exchange Online Microsoft- managed default-OFF) leaves per-tenant per-custom-domain DKIM-signed messages replayable indefinitely after origination across BOTH egress paths — the per-hybrid-tenant operator must explicitly enable per-egress-path per- message x= expiration-tag publication through the on-prem Edge Transport DKIM agent configuration AND confirm Exchange Online Microsoft-managed per-message expiration-tag emission to achieve dual-egress per-message-granularity anti-replay bounding; (iv) per- hybrid-tenant per-custom-domain Trusted ARC Sealer (RFC 8617) registration at BOTH the on-prem boundary AND the Exchange Online boundary is the LOAD-BEARING per-tenant per-domain trusted-intermediary-rescue + anti-replay-cascade defense whose dual- boundary registration discipline the per- hybrid-tenant operator must coordinate across BOTH egress paths — per-tenant per-custom-domain Trusted ARC Sealer publication preserves the per- publisher per-domain DMARC verdict across mailing-list + auto-forwarder + threading- rescue intermediary chains AT BOTH egress paths and STRUCTURALLY CONSTRAINS the per- message DKIM-replay attack-chain at the per-tenant trusted-intermediary-rescue + anti-replay-evidence-cascade boundary. Read THIS page when AUTHORING the per-hybrid- tenant per-custom-domain DMARC ramp through the on-prem Exchange + Exchange Online dual-egress topology; read the replay- attacks spoke when AUDITING the per-tenant per-custom-domain per-egress-path per- selector DKIM private-key custody, key- lifetime, per-message x= expiration-tag, and Trusted ARC Sealer operator-discipline at the per-tenant per- custom-domain dual-egress anti-replay control-surface boundary.
• DKIM for Google Workspace — the CROSS-MAJOR-PROVIDER-PER- WORKSPACE-TENANT-DKIM-SIGNING- DISCIPLINE-AS-STRUCTURAL-PEER companion to this M365-hybrid per-tenant per- custom-domain DMARC deployment reference. Where THIS page documents the per-M365-tenant per-custom-domain DMARC deployment workflow for the Exchange-hybrid topology (per-tenant per-custom-domain DKIM-signing configuration via Exchange Admin Center > mail-flow > DKIM, per-tenant per-custom-domain selector1 / selector2 rotation under selector1._domainkey.<d> + selector2._domainkey.<d> per-tenant published CNAME records, per-tenant Centralized vs Decentralized Mail Transport hybrid-relay verdict- preservation patterns), the DKIM-for- Workspace spoke documents the PARALLEL per-Workspace-tenant per-custom-domain DKIM-signing deployment workflow (Workspace Admin Console > Apps > Google Workspace > Gmail > Authenticate email; per-tenant per- custom-domain DKIM key generation at 2048-bit RSA modulus; per-selector TXT-record publication under google._domainkey.<domain> in the per-tenant authoritative DNS zone; per-tenant Authenticate-email Start toggle) whose per-Workspace- tenant cryptographic-publication discipline is the cross-major-mailbox- provider structural-peer per-tenant per-custom-domain DKIM-signing discipline operators of a Workspace ↔ M365-hybrid portfolio deploy in parallel. The M365-HYBRID-VS- WORKSPACE-DKIM cross-reference establishes FOUR structurally-distinct cross-major-mailbox-provider per- tenant per-custom-domain DKIM-signing coupling dimensions: (i) BOTH major-mailbox-provider hosts publish the per-tenant per-custom-domain public key under provider-specific per-tenant selector publication conventions (M365: per-tenant selector1._domainkey.<d> + selector2._domainkey.<d> published as per-tenant CNAME pointers to per-tenant provider-managed selector1-<tenantId>._domainkey.<onmicrosoft-tenant>; Workspace: per-tenant google._domainkey.<d> published as per-tenant TXT record with provider-managed per-tenant public key) — the per-major- mailbox-provider per-tenant per- custom-domain DKIM-publication substrate is identical in shape but differs in per-provider per-selector naming + per-provider per-tenant key- management ownership convention; (ii) operators of a Workspace ↔ M365-hybrid cross-major-mailbox- provider per-tenant per-portfolio deployment must complete the per- provider per-tenant per-custom-domain DKIM-signing deployment in BOTH provider admin consoles BEFORE progressing the per-publisher per- portfolio DMARC ramp — the per-portfolio DMARC p=quarantine / p=reject ramp produces 100% per-message dkim=fail verdicts at the receiver-side for the per- provider per-tenant per-custom-domain leg where the per-provider per- tenant DKIM-signing posture is absent; (iii) per-Workspace- tenant Authenticate-email Rotate Key operator-discipline and per-M365- tenant selector1 / selector2 rotation operator-discipline share the per- publisher per-portfolio per-provider rotation cadence pattern — both require per-tenant per-custom-domain provider-side rotation execution + per-tenant authoritative-DNS-zone propagation-aware overlap windows during rotation — the operator-side per-portfolio per- provider per-tenant rotation discipline transfers between the two major- mailbox-providers; (iv) per- Workspace-tenant per-custom-domain Authenticate-email-Start activation and per-M365-tenant per-custom-domain DKIM-Enable activation in the Exchange Admin Center are the canonical per-major-mailbox-provider per-tenant cryptographic-publication prerequisites without which the per- portfolio DMARC ramp produces a 100% per-message DKIM-aligned-fail receiver-side verdict for the respective per-major-provider per- tenant per-custom-domain leg — the per-major-mailbox-provider per- tenant per-custom-domain DKIM-toggle activation is the load-bearing per- provider cryptographic-authentication- publication primitive every per- portfolio per-tenant per-custom- domain DMARC ramp depends on. Read this M365-hybrid reference when DEPLOYING the per-M365-tenant per- custom-domain DKIM-signing posture for the Exchange-hybrid topology; read the DKIM-for-Workspace spoke when DEPLOYING the structural-peer per-Workspace-tenant per-custom- domain DKIM-signing posture operators of a Workspace ↔ M365- hybrid cross-major-mailbox-provider per-publisher per-portfolio deployment publish in parallel.
• DKIM-Signature header explained (RFC 6376 §3.5 byte-by-byte tag anatomy: v= a= c= d= s= h= b= bh= i= q= l= t= x= z=) — the per-message sender-side DKIM-Signature header reference companion to this hybrid Exchange dual-egress DMARC deployment guide. Where THIS page documents the dual-outbound- boundary hybrid topology (on-prem Edge Transport / Exchange-Online tenant-egress, per-boundary DKIM-signing posture, per- boundary SPF authorization, the per-tenant per-custom-domain DMARC ramp coordination), the DKIM-Signature spoke documents the per-message DKIM-Signature: header anatomy operators inspect at the Auth-Results stage to diagnose WHICH hybrid leg (cloud EXO or on-prem Edge Transport) signed each message. The hybrid- Exchange-VS-DKIM-Signature cross-reference establishes FOUR coupling dimensions: (i) the d= (signing-domain) tag is the per-message evidence operators use to attribute a DMARC-aggregate-report row to the correct hybrid leg — EXO-signed messages carry d=<tenant>.onmicrosoft.com when the customer domain DKIM-Enable is absent, vs d=<custom-domain> when CNAME-delegation is active; on-prem Edge Transport with OpenDKIM publishes its own d= selector tree; the spoke documents the d= tag evaluation semantics that anchor this per-leg attribution; (ii) the s= (selector) tag partitions hybrid mail-flow by signing infrastructure — EXO publishes s=selector1 / s=selector2 rotation, on-prem Edge Transport publishes operator-chosen selectors — operators trace per- boundary signing-posture regressions through the s= tag distribution in aggregate reports; the spoke documents the per-selector publication discipline this per-boundary attribution depends on; (iii) the b= / bh= tags carry the per-message cryptographic proofs whose mismatch patterns differ structurally by hybrid leg — EXO's relaxed canonicalization survives Exchange-Online's per-message transit rewrites differently than on-prem Edge Transport relaxed canonicalization survives Edge-Server transit; the spoke documents the two-hash design and the per- canonicalization-mode survivability distinction operators need to triage boundary-specific bh= mismatch regressions; (iv) the h= (signed-header list) tag determines which headers each hybrid leg's signer protected — divergence between EXO and on-prem signed-header lists is a common hybrid-coexistence regression cause; the spoke documents the canonical h= inclusion list and the per-boundary coordination invariant. Read the DKIM-Signature-explained spoke when diagnosing hybrid DMARC regressions whose Auth-Results header DKIM-Signature tag values disagree between the two hybrid egress legs.
• MTA-STS explained — the HYBRID-EXCHANGE-DUAL-INBOUND-MX- BOUNDARY-AS-LOAD-BEARING-MTA-STS-POLICY- FILE-MX-ALLOW-LIST-AUTHORING-DISCIPLINE companion to this hybrid Exchange DMARC deployment reference. Where THIS page documents the cloud EXO + on-prem Edge Transport dual-egress + dual-inbound hybrid topology with the per-tenant DMARC publication discipline at the per-domain _dmarc.<tenant- domain> TXT-RR boundary, the MTA-STS-explained pillar documents the transport-layer TLS-enforcement-policy pillar whose per-tenant mta-sts. <tenant-domain> HTTPS policy-host + _mta-sts.< tenant-domain> TXT-RR publication discipline coordinates across the hybrid dual-inbound boundary at four hybrid-Exchange-vs-MTA-STS coupling dimensions: (i) per- tenant mx: allow-list authoring at hybrid dual-inbound boundary — the policy-file body must enumerate BOTH the EOP- inbound MX *.mail.protection. outlook.com wildcard pattern AND the on-prem Edge Transport inbound MX hostname simultaneously; partial enumeration (omitting either side) produces sending-MTA rejection of legitimate inbound mail to the omitted leg, creating per-tenant per- domain mail-flow drop that incident response surfaces as MTA-STS misconfig; (ii) per-tenant mode: enforce commitment progression gated on dual-inbound DMARC-aligned- pass-rate floor — the per- tenant mode: testing → mode: enforce ramp must complete on BOTH inbound legs simultaneously; tightening enforcement on EOP while on-prem still produces certificate-host-mismatch TLS-RPT result-types creates per- tenant cross-leg enforcement- divergence the hybrid spoke documents as the canonical hybrid-coexistence regression class; (iii) per- tenant TLS-RPT dual-stream observability at _smtp._tls. <tenant-domain> — the per-tenant v=TLSRPTv1; rua=mailto: publication discipline emits per-receiver per-day JSON-aggregate evidence FROM BOTH sending-MTA-side perspectives (when sending to EOP and when sending to on-prem Edge Transport); per-leg evidence stream consolidation at the per-tenant per-domain aggregation boundary is operationally load- bearing for hybrid-topology TLS- delivery-integrity monitoring; and (iv) per-tenant max_age: caching-budget coordination with hybrid migration-cutover window — the per-tenant max_age: directive bounds the sending-MTA-side policy-cache window; during hybrid migration cutover (e.g., adding/removing the on-prem inbound MX from the per- tenant mx: allow-list), the per-tenant cache-window discipline determines the propagation delay before sending MTAs honor the new allow-list state. Read the MTA-STS- explained pillar alongside this hybrid Exchange DMARC reference when co- deploying per-tenant transport-layer MTA-STS policy publication and per- tenant application-layer DMARC publication across the hybrid dual- inbound + dual-egress topology boundary.
• Why SPF alone is insufficient — the structural-limitations-of-SPF reference cataloguing the four reasons every per-publisher per-domain email- authentication posture requires additional protocols beyond SPF: (i) RFC 7208 §11.4 forwarding-MAIL-FROM-rewrite breaks SPF at the per-hybrid-tenant on-prem-Exchange-to- EOP relay second-hop boundary; (ii) SPF envelope-MAIL-FROM authorisation does NOT survive the per-hybrid-tenant on-prem Exchange → EOP relay → external-receiver third-hop egress chain without ARC-Seal replay of upstream verdicts; (iii) DMARC- composite alignment requires per-hybrid- tenant DKIM signing at BOTH the on-prem Exchange Transport-Server boundary AND the EOP per-tenant DKIM-signing boundary; (iv) per-major-mailbox-provider per-tenant SPF- only deployment leaves the per-tenant dual-inbound-MX + dual-egress-relay surface structurally exposed to second-hop alias / Outlook-rule-forwarding / shared-mailbox- relay SPF-leg-failure variants. THIS page documents the per-hybrid-tenant on-prem- Exchange-plus-EOP per-custom-domain DMARC composite-policy deployment workflow as the canonical DEFENSE-IN-DEPTH per-publisher per-domain SPF + DKIM + DMARC + ARC dual- leg deployment ramp that structurally closes exactly the four SPF-only structural- limitations the why-SPF-alone-is- insufficient catalogue enumerates — per- hybrid-tenant DKIM signing at the on-prem Exchange Transport-Server boundary closes the message-content cryptographic-integrity gap, per-hybrid-tenant ARC-Seal at the EOP ingress boundary closes the on-prem-to-EOP relay second-hop SPF-leg- failure gap, per-hybrid-tenant DMARC composite-policy publication closes the per-tenant alignment-evidence gap, and per- hybrid-tenant dual-DKIM-signing publication closes the per-major-mailbox-provider per- custom-domain authentication-evidence gap. Read the why-SPF-alone-is-insufficient spoke alongside this hybrid-O365 DMARC deployment reference when scoping the per-hybrid- tenant per-custom-domain defense-in-depth SPF + DKIM + DMARC + ARC dual-leg publication discipline, when authoring the per-hybrid-tenant per-custom-domain DMARC ramp playbook on aligned-DKIM-pass-rate evidence rather than SPF-alone evidence, or when sequencing the per-hybrid-tenant ARC-Seal trust-anchor cohort against the on-prem-Exchange-to-EOP relay second-hop SPF-leg-failure surface.
• MX records explained — the HYBRID-EXCHANGE-DUAL-EGRESS-MX-RR- AS-INBOUND-AND-REPORT-LOOPBACK-PREREQUISITE companion to this hybrid Exchange deployment reference. Where THIS page documents the on-prem-Exchange-plus-Exchange-Online dual- signer DKIM posture, the Centralized Mail Transport vs classic-hybrid outbound-boundary decision, the Trusted ARC Sealers boundary, and the Default Frontend Connector DKIM- strip / Send-Connector relay-loop failure modes, the MX-records spoke is the APEX-MX-RR-PUBLICATION reference hybrid Exchange tenants consult when verifying the apex MX RRset routes inbound mail to the intended Exchange Online tenant (<tenant>.mail.protection.outlook.com preference 0) in cloud-routed-inbound topologies, or to an on-prem Edge / Exchange front-end in on-prem-routed-inbound topologies, AND whose continuous resolvability is the structural precondition for the receiver-generated aggregate (RUA) and forensic (RUF) report cron to deliver DMARC observability back to the publisher mailbox. The MX-RR-byte-syntax-and-preference- ordering cross-reference is structurally load-bearing for hybrid Exchange operators: every Exchange Admin Center MX-record edit that drops the apex MX RRset, mis-orders the preference values between cloud and on-prem hosts, or points the highest- preference MX at a non-resolvable host silently breaks BOTH inbound mail delivery AND the publisher's per-domain DMARC reporting loopback, turning the publisher's rua= / ruf= tags into silently-discarded configurations and dropping the DMARC observability the hybrid Exchange tenant relies on to gate the dual- egress-path p=none → p=quarantine → p=reject ramp.
• RFC 7489 - DMARC
• RFC 7208 - SPF
• RFC 6376 - DKIM
• RFC 8617 - ARC (Authenticated Received Chain) - the protocol behind Trusted ARC Sealers and the hybrid relay verdict preservation pattern.
• RFC 8058 - One-Click List-Unsubscribe - required by the Feb 2024 bulk-sender rules.
• DMARC myths and misconceptions debunked — the canonical educational myth-busting reference whose 18 named DMARC misconceptions are empirically debunked against the per-tenant hybrid Exchange dual-egress publication discipline THIS deployment page documents at four hybrid- deployment-discipline-to-DMARC-myth resolution dimensions: (i) the per-tenant selector1._domainkey + selector2._domainkey CNAME-delegation publication requirement is the canonical empirical counterexample to the "Microsoft 365 handles DMARC automatically for my tenant" misconception — the myth catalogue debunks the assumption that cloud- platform vendors ship DMARC-aligned DKIM out-of-the-box; in reality the per-tenant admin must manually-enable custom-domain DKIM via the Defender portal, publish the dual-selector CNAME records on the per-tenant accepted-domain DNS zone, and reactivate after every Microsoft-side key-rotation event; (ii) the per-tenant include:spf.protection.outlook.com + on-prem-egress ip4:- literal co-publication discipline is the canonical empirical counterexample to the "spf=pass via Microsoft is enough to satisfy DMARC" alignment-fallacy misconception — the myth catalogue explicitly debunks the SPF-alone-is-enough fallacy; on- prem Exchange egress emits messages whose envelope MAIL FROM is on the org's accepted-domain but whose source IP must also be authorised in the apex SPF record for SPF- aligned-pass, otherwise the row emits spf=pass- with-aligned=false (the canonical DMARC-alignment-fallacy defect- class); (iii) the dual-selector CNAME custom-domain DKIM activation discipline is the canonical empirical counterexample to the "the default onmicrosoft.com tenant DKIM signature is fine for my domain" misconception — until the admin enables custom- domain DKIM, outbound messages carry only the d=tenant. onmicrosoft.com DKIM signature whose d=-tag does NOT align with the per- tenant accepted-domain RFC 5322.From organisational domain — every receiver-side Authentication-Results row emits dkim=pass-with- aligned=false the myth catalogue explicitly attributes to this defect-class; (iv) the per-Exchange-Online-Connector message-flow routing discipline is the canonical empirical counterexample to the "Exchange Online Connectors do not affect DMARC alignment" misconception — the myth catalogue debunks the false-assumption that Connector- relayed messages preserve DMARC- alignment unchanged; per-Connector flow choice ("Forward via Office 365" vs "Route only through these smart hosts" vs "Apply to messages that match" certificate-or-IP- match condition) determines whether the Connector-traversed message retains its original DKIM signature, picks up an EOP anti-spam-bypass header rewrite, or is re-signed by EOP under a different d=-tag. Read the myths-and-misconceptions spoke ALONGSIDE this hybrid Exchange deployment reference whenever the per-tenant admin scopes a Phase-0 deployment education curriculum — the deployment-discipline checklist THIS page documents IS the empirical operations-evidence chain that grounds every M365- cloud-assumption-subset entry in the myth catalogue against per- tenant Defender-portal-observed Authentication-Results reality.
• DKIM selectors explained — the PER-HYBRID-TENANT-DUAL-EGRESS- PER-EGRESS-SELECTOR-NAMESPACE- PUBLICATION-PRIMITIVE-REFERENCE companion to this hybrid Exchange deployment-discipline reference. Where THIS page documents the HYBRID- EXCHANGE-AS-TENANT-MANAGED-DUAL-CLOUD- AND-ON-PREM deployment topology and its per-tenant dual-egress SPF / DKIM / DMARC publication discipline, the dkim_selectors_explained spoke documents the DKIM-SELECTOR-NAMESPACE PRIMITIVE the hybrid-tenant operator publishes PER-EGRESS-PATH at the <sel>._domainkey.<tenant-domain> TXT-record level (or CNAME-delegation to Microsoft-managed key zone): the per-egress canonical selector catalogue (Exchange-Online-managed selector1._domainkey + selector2._domainkey via CNAME-delegation to <sel>-<tenant-id>._domainkey.<tenant-onmicrosoft-domain> + on-prem-Exchange-managed per- tenant-configured selector), the dual-selector rotation publishing- window mechanics, and the seven selector-publication failure modes the hybrid-tenant operator must coordinate across BOTH egress paths uniformly. FOUR structurally- distinct PER-HYBRID-TENANT-DUAL- EGRESS-PER-EGRESS-SELECTOR-NAMESPACE- PUBLICATION-COORDINATION dimensions the hybrid-Exchange deployment- discipline checklist THIS page documents operationally consumes: (i) per-hybrid-tenant cloud- leg selector1/selector2 CNAME-delegation publication AS LOAD-BEARING-PER-CLOUD-EGRESS DKIM- SIGNING-AUTHORITY INPUT — the Exchange-Online cloud-leg of the hybrid topology requires the per-tenant zone to publish the Microsoft-managed CNAME-delegation pair (selector1._domainkey IN CNAME selector1-<tenant-id>._domainkey.<tenant-onmicrosoft-domain> + the parallel selector2 pair) the selectors-explained spoke catalogues as the M365 canonical per-tenant selector identity; the cloud-leg DKIM-signing authority depends on the per-tenant zone publishing the per-egress canonical selector at the namespace level the spoke documents; (ii) per-hybrid- tenant on-prem-leg per-tenant- configured-selector TXT-record publication AS LOAD-BEARING-PER- ON-PREM-EGRESS DKIM-SIGNING- AUTHORITY INPUT — the on- prem-Exchange-leg of the hybrid topology requires the per-tenant zone to publish a DISTINCT per- tenant-configured-selector (NOT the cloud-leg selector1 / selector2) at the per- tenant zone TXT-record level carrying the on-prem-Exchange- managed signing-key p=<base64>; the per-tenant operator coordinating the on-prem signing-authority inherits the byte-correct TXT- record publication discipline the selectors-explained spoke documents — without the on-prem-leg per- selector being correctly published the on-prem outbound stream emits dkim=permerror across every Authentication-Results row; (iii) per-hybrid-tenant cross-egress UNIFORM-RFC-8301-2048- BIT-RSA-FLOOR AS LOAD-BEARING-DUAL- EGRESS-CRYPTOGRAPHIC-KEY-STRENGTH- UNIFORMITY INVARIANT — the per-hybrid-tenant cloud-leg selector1 / selector2 per-tenant publication AND the on-prem-leg per-tenant-configured-selector publication MUST UNIFORMLY meet the RFC 8301 2048-bit-RSA floor the selectors-explained spoke documents as the per-selector publication- invariant — a per-egress per- selector key-size divergence (e.g., cloud-leg 2048-bit + on-prem-leg 1024-bit) produces a per-egress per-source-IP per-row dkim=fail verdict- divergence pattern the per-tenant operator must catch at the publication-discipline level the spoke catalogues; (iv) per- hybrid-tenant DKIM-key-rotation cross-egress overlap-window coordination AS LOAD-BEARING-DUAL- EGRESS-DUAL-SELECTOR-PUBLISHING- WINDOW-UNIFORMITY DISCIPLINE — when EITHER egress path rotates its per-egress per-selector signing key, the per-tenant operator must coordinate the per-rotation publishing-window the selectors- explained spoke documents (publish new selector ≥7 days before retiring the old; per-receiver per- egress DKIM-pass-rate monitoring; per-selector retirement zero- traffic confirmation) UNIFORMLY across both egress paths; a per- egress per-rotation timing skew produces a per-egress per-source- IP per-row dkim=permerror verdict-divergence pattern during the per-rotation per-egress publishing-window the per-tenant operator must coordinate via the dual-selector overlap-window discipline the spoke catalogues. Read the dkim_selectors_explained spoke ALONGSIDE this hybrid Exchange deployment reference when authoring the per-hybrid-tenant per-egress DKIM-publication audit- checklist row in the per-tenant Phase-0 deployment-discipline catalogue — the spoke is the canonical PER-HYBRID-TENANT-DUAL- EGRESS-PER-EGRESS-SELECTOR- NAMESPACE-PUBLICATION-PRIMITIVE REFERENCE the hybrid Exchange deployment depends on at the per- tenant zone-publication level across both cloud-leg and on- prem-leg egress paths uniformly.
• SPF for Google Workspace — the CROSS-CLOUD-PROVIDER-PER- WORKSPACE-TENANT-SINGLE-EGRESS-SPF- PUBLICATION-AS-STRUCTURAL-CONTRAST- AND-CROSS-PROVIDER-DELIVERY- COMPANION-TO-PER-HYBRID-EXCHANGE- DUAL-EGRESS-SPF-PUBLICATION companion to this hybrid Exchange dual-egress reference. Where THIS page documents the per-hybrid- Exchange-tenant DUAL-EGRESS SPF- publication discipline (per-org- domain apex SPF record authoring an include:spf.protection.outlook.com Exchange-Online cloud-egress authorization PLUS per-on-prem-Edge- Transport ip4:<CIDR> literals authorization PLUS optional parallel SaaS include: cascade, the canonical 10-DNS- lookup-ceiling-overflow risk from hybrid-dual-egress multi-include stacking, the per-egress-path DKIM-aligned-pass-vs-SPF-aligned- pass-divergence the dual-egress topology produces), the spf_for_ google_workspace spoke documents the structurally-contrasting per- Workspace-tenant SINGLE-EGRESS SPF- publication discipline at FOUR hybrid-dual-egress-vs-Workspace- single-egress SPF-authorization- topology dimensions: (i) per- Workspace-tenant SINGLE-EGRESS include:_spf.google.com SPF-include-cascade publication AS STRUCTURAL CONTRAST TO per-hybrid- Exchange-tenant DUAL-EGRESS include:spf.protection.outlook.com + per-on-prem ip4: literals SPF-include-cascade publication — the Workspace tenant's single canonical Google- managed outbound IP-pool authorization cascade exposes the structural- contrast to the hybrid Exchange tenant's dual cloud-and-on-prem authorization stack; the spf_for_ google_workspace spoke documents the single-egress publication discipline whose architectural simplicity is the canonical reference-point hybrid operators evaluate the dual-egress publication-coordination cost against; (ii) per-Workspace- tenant single-egress RFC 7208 §4.6.4 ten-DNS-lookup ceiling-consumption BUDGET-DISCIPLINE AS STRUCTURAL- CONTRAST TO per-hybrid-Exchange- tenant dual-egress overflow-risk BUDGET-DISCIPLINE THIS page documents — Workspace's per-tenant include:_spf.google.com cascade itself consumes ~3-5 of the ten-DNS-lookup ceiling budget, leaving headroom for per-tenant parallel SaaS-include stacking; the hybrid Exchange tenant's dual-egress stack consumes the Workspace- equivalent budget PLUS the per-on- prem authorization budget, routinely overflowing the ten- lookup ceiling; the spf_for_google_ workspace spoke documents the single-egress budget-discipline whose preservation contrasts with the dual-egress budget-overflow- risk THIS page documents; (iii) per-Workspace-tenant single-egress include:_spf.google.com SPF-aligned-pass-rate INVARIANT AS STRUCTURAL-CONTRAST TO per- hybrid-Exchange-tenant per-egress- path SPF-aligned-pass-RATE- DIVERGENCE between cloud-egress and on-prem-egress paths — the Workspace tenant emits per-org- domain mail from a single canonical Google-managed outbound IP-pool, producing a uniform per-org-domain SPF-aligned-pass rate at receivers; the hybrid Exchange tenant's per- org-domain mail emits from two structurally-distinct egress paths with divergent per-egress-path SPF- aligned-pass rates the dual-egress RUA aggregate stream surfaces; the spf_for_google_workspace spoke documents the single-egress invariant-rate baseline against which the hybrid Exchange tenant's per-egress-path divergence is operationally compared; (iv) per-hybrid-Exchange-tenant OUTBOUND-CONNECTOR-DELIVERS-MAIL- TO-WORKSPACE-RECIPIENT-DOMAIN AS cross-provider DELIVERY-COMPANION boundary where Workspace-published SPF-authorization is consumed for receiver-side per-source-IP- attribution — every hybrid Exchange tenant's outbound mail flow to Workspace-hosted recipient domains (gmail.com or Workspace G Suite tenant) passes through the Workspace receiver's per-org-domain SPF-evaluator; the spf_for_google_workspace spoke documents the per-Workspace-tenant SPF-publication discipline whose per-org-domain authorization the hybrid tenant's outbound-connector receiving-side evaluator consumes for per-source-IP-attribution and per-message DMARC-alignment evaluation. Read the spf_for_ google_workspace spoke alongside this hybrid Exchange dual-egress reference whenever the cross- cloud-provider operator scopes a per-cloud-tenant SPF-authorization- topology-comparison plan — the per- Workspace-tenant single-egress SPF- publication discipline the spoke catalogues IS the cross-cloud- provider structural-contrast reference-point AND the cross- provider delivery-counterparty whose authorization the hybrid tenant's outbound mail to Workspace recipients consumes at the cross- cloud-provider per-cloud-tenant SPF-authorization-topology boundary.
• TLS-RPT report format — the hybrid-Exchange dual-outbound- boundary per-boundary RFC 8460 TLS-RPT JSON-aggregate report as peer transport- layer per-boundary observability primitive companion to this hybrid-Exchange dual- outbound-boundary deployment discipline reference. Where THIS page documents the per-hybrid-tenant on-prem-Exchange-egress vs Exchange-Online-egress dual-outbound- boundary topology (classic-hybrid HCW- configured on-prem-outbound-by-default, Centralized-Mail-Transport CMT cloud- outbound-boundary, split-domain-coexistence, Edge-Transport-server topologies), the TLS-RPT-report-format spoke documents the RFC 8460 JSON-aggregate report schema that is the LOAD-BEARING transport-layer per- boundary observability primitive operators MUST co-ingest from BOTH boundaries to complete the hybrid-tenant per-boundary transport-layer-failure attribution discipline. Four HYBRID-EXCHANGE-DUAL- OUTBOUND-BOUNDARY-VS-TLS-RPT-JSON-AGGREGATE- REPORT cross-correlation axes the TLS-RPT- report-format spoke documents: (i) the per-hybrid-tenant on-prem- Exchange-egress boundary emits per-day TLS-RPT JSON-aggregate rows attributing transport-layer outcomes to on-prem-side SMTP relay infrastructure with failure-details.sending-mta-ip populated from the on-prem Edge-Transport / Hub-Transport server IP-set — operators MUST distinguish per-boundary on-prem-side TLS-failure attribution from cloud-egress TLS-failure attribution to localize per- boundary remediation; (ii) the per-hybrid-tenant Exchange-Online-egress boundary emits per-day TLS-RPT JSON-aggregate rows attributing transport-layer outcomes to cloud-side SMTP infrastructure with failure-details.sending-mta-ip populated from the M365 cloud-egress IP- pool (the *.mail.protection.outlook.com canonical hostname glob's reverse IP range) — operators reading the per-day JSON-aggregate MUST cross-reference per- sending-MTA-IP attribution to the dual- outbound-boundary topology to localize per-boundary transport-layer-failure root cause; (iii) the per- hybrid-tenant Centralized-Mail-Transport (CMT) topology routes all outbound mail through the Exchange-Online-egress boundary AND emits per-day TLS-RPT JSON-aggregate rows ONLY against the cloud-egress IP- pool — operators MUST recognize the CMT- vs-classic-hybrid topology distinction when reading the per-day JSON-aggregate because the per-boundary sending-MTA-IP attribution pattern STRUCTURALLY DIFFERS by hybrid topology choice; (iv) the per-hybrid-tenant cross-protocol-pillar per-boundary investigation discipline requires the per-publisher per-day TLS-RPT JSON-aggregate co-ingested with the per- publisher per-day DMARC RUA aggregate at BOTH boundaries — the JSON-aggregate's per-boundary failure-details rows attribute transport-layer failures per-source-MTA-IP while the RUA aggregate's per-boundary policy_evaluated rows attribute application-layer authentication verdicts per-source-IP — together they form the complete per-boundary hybrid-tenant observability stream. Read THIS page when ARCHITECTING the hybrid dual- outbound-boundary topology; read the TLS- RPT-report-format spoke when DECODING the per-day RFC 8460 JSON-aggregate that completes the per-hybrid-tenant per- boundary cross-protocol-pillar transport- layer-failure attribution discipline.
• DANE explained — the per-hybrid-tenant per-on-prem- MX DANE TLSA transport-layer publication companion at four per-hybrid-tenant per- boundary transport-layer-publication coupling dimensions.
• Email deliverability — (i) the per-EOP-cloud-egress IP pool and the per-on-prem-Edge-Transport outbound IP cohort accrue INDEPENDENT per-receiver reputation in Gmail Postmaster Tools, Outlook SNDS, and Yahoo Sender Hub, so deliverability remediation runs per-cohort, not per- tenant; (ii) the per-hybrid-tenant DKIM-aligned-pass-rate floor is load- bearing upstream of receiver-side inbox-placement gating — when the dual-signer on-prem Transport-agent path diverges from the Exchange Online cloud-signer path, the LOWER cohort establishes the receiver-side inbox- placement floor; (iii) per-receiver complaint-rate and bounce-rate attribution is per-egress-IP-cohort (Gmail's ≤ 0.1% spam complaint rate Sender Guidelines gate independently on the on-prem cohort and the EOP cohort, and Outlook's SNDS green/yellow/red per-IP buckets diverge across the two egress paths); and (iv) the on-prem Edge Transport outbound cohort cannot reach receiver-side inbox without FCrDNS forward-confirmed PTR publication AND per-receiver IP warmup — independent of the cleanest possible per-message DKIM / SPF / DMARC posture. Read the deliverability spoke when investigating per-receiver inbox- placement regression on EITHER egress path of the hybrid topology THIS page coordinates.
• How attackers bypass DMARC
• Business email compromise (the business-fraud outcome an unenforced hybrid tenant stays exposed to) — the dual-egress publication discipline THIS page coordinates exists to reach a per-custom-domain DMARC p=reject across BOTH the Exchange Online and on-premises Edge Transport paths; BEC is the high-value fraud class — CEO-impersonation wire-transfer requests, vendor-invoice redirection — that profits from any tenant whose hybrid alignment gap leaves exact-domain spoofing viable. Until both egress legs produce an aligned DKIM or SPF pass under an enforced policy, the hybrid domain remains a usable BEC sender identity. Read it to anchor the hybrid deployment effort to the concrete impersonation threat it ultimately shuts down.
• 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.

Deploy DMARC for your hybrid Exchange topology now

DMARC Analyzer parses the daily aggregate reports Microsoft, Google, Yahoo, and other receivers send to your rua= mailbox, deduplicates by report_id + org_name, and surfaces the per-sender / per-IP / per-day breakdown needed to drive the hybrid sender-path inventory. Live DNS verification for every SPF / DKIM / DMARC record 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 hybrid Exchange domain