Technical Case Study: Resolving Cross-Tenant DMARC/SPF Failures in Google Workspace & O365 Hybrid Setup via Defender ARC Settings

Modified on Tue, 26 May at 5:58 PM

Following up on our previous hybrid routing case study, I am sharing the documentation for the reverse architectural scenario. This scenario applies when Google Workspace serves as the primary MX record (first hop) and relays inbound emails to Microsoft 365 (second hop) where the end mailboxes reside.

This document outlines the root cause of resulting DMARC bounces and the step-by-step resolution using the Microsoft Defender Admin Portal.

Executive Summary

Environment: Hybrid Deployment (tilind.com) — MX points to Google Workspace (smtp.google.com); inbound mail is filtered by Google and then relayed to Microsoft 365 where user mailboxes are active.
The Problem: Inbound emails from external domains with strict DMARC policies (e.g., Yahoo, iCloud) fail authentication checks upon reaching Microsoft 365. This results in emails being marked as unauthenticated, causing them to be quarantined or routed to the Junk folder.
The Resolution: Configured Microsoft 365 Defender to trust Google Workspace as a verified Trusted ARC (Authenticated Received Chain) Sealer.

Detailed Problem Analysis

1. Architectural Flow & The Breakdown

When an external sender (e.g., sender@yahoo.com) emails a Microsoft-hosted user on our domain (user@tilind.com), the flow operates as follows:

Initial Inbound: The email lands on Google Workspace. Google successfully validates Yahoo’s original SPF, DKIM, and DMARC alignment.
Internal Relay: Google Workspace logs the "Pass" status, applies its cryptographic ARC seal, and routes the mail via an outbound routing rule/connector to Exchange Online.
The Security Failure: When Microsoft 365 receives the connection, it evaluates the incoming IP, which belongs to Google's infrastructure rather than Yahoo's.
- SPF Fails: Google's IP addresses are not included in Yahoo's SPF record.
- DMARC Alignment Fails: Because the path SPF checks fail, and if any minor header or formatting modification occurred during the Google-to-Microsoft relay, the original DKIM signature breaks. Microsoft flags the sender as unauthenticated, enforcing strict anti-spam filtering actions (Quarantine/Junk).

Solution Architecture: Authenticated Received Chain (ARC)

To resolve this path authentication failure, we utilize ARC. When Google Workspace relays the message, it inserts cryptographic headers (ARC-Seal, ARC-Message-Signature) stating: "This is Google; we verified Yahoo's authentication metrics at our edge, and they passed."

By explicitly instructing Microsoft Defender to trust Google's ARC signatures, Exchange Online can extract Google's original validation results and override the localized SPF failure.

Implementation Steps (Microsoft Defender Portal)

Unlike the Google Workspace Admin console, this setting is completely accessible via standard tenant Global Admin or Security Administrator roles:

Navigate directly to the Microsoft Defender Portal: security.microsoft.com.
In the left-hand navigation, go to Email & Collaboration > Policies & Rules.
Select Threat policies from the main dashboard.
Under the Rules section, click on Email Authentication Settings.
Switch to the ARC tab at the top of the interface.
Click Add and insert Google's global outbound signing domain:
- google.com
Click Save to apply the configuration.

Alternative Deployment via Exchange Online PowerShell

For faster deployment or scripted rollouts, the same rule can be applied globally via PowerShell:

PowerShell

# Append google.com to the trusted ARC sealers list Set-ArcConfig -Identity Default -ArcTrustedSealers "google.com"

Post-Implementation Validation

Once the configuration replicates across Exchange Online Protection (EOP) nodes, the inbound delivery status updates automatically:

Plaintext

Inbound Hop 1:              Google Workspace (MX) -> SPF/DKIM: Pass (Stamped with ARC-Seal) Inbound Hop 2:              Exchange Online (EOP) -> Evaluates Trusted ARC List Authentication Result:      DMARC Pass (via Trusted Sealer: google.com) Delivery Action:            Successfully Delivered to Inbox ?

Key Architectural Differences to Remember

Direction of Trust: In this scenario, Microsoft is the receiver, meaning the configuration resides entirely within the Microsoft Defender Portal. The previous scenario required changes within the Google Admin panel because Google was the receiver.
The Whitelisted Domain: Ensure that the domain added matches the d= tag inside the inbound ARC-Seal header. For Google Workspace relays, this domain is universally google.com.

Please keep this design pattern on file for any future split-domain migrations utilizing Google Workspace as the primary gateway.