Resolving Split Delivery Failures (M365 & Google)

When running a split delivery configuration between Google Workspace and Microsoft 365, emails routed downstream often bounce or vanish due to rigid perimeter defenses. This architecture breaks down when the receiving platform blocks Google’s relays as unauthenticated traffic or rejects the recipient lookup entirely. Resolving these split-delivery failures requires aligning the inbound connectors in M365 to accept Google’s smart host IP ranges and ensuring your internal domains are categorized correctly to support shared address spaces.

Fast-Fix: The 45-Second Solution

To fix split delivery failures, add Google’s outbound relay IP ranges to your Microsoft 365 Inbound Partner Connector and set your accepted domain status to Internal Relay. This prevents M365 from dropping forwarded messages or triggering hard authentication blocks. Risk: High (Partial Outbound Outage).

Quick Risk Snapshot

• Severity: High
• Safe to Send?: Partially (Internal Google mail works; cross-platform routing bounces)
• Primary Cause: Missing or misconfigured Inbound Partner Connector in Microsoft 365.
• Rare Cause: SPF hardfail evaluation on the M365 gateway caused by a lack of an exchange routing rule.

Low Risk vs. High Risk Paths

If delivery fails exclusively for a few newly provisioned users on the secondary environment, you are on a low-risk path. This is typically a directory synchronization delay where the downstream system simply doesn’t recognize the alias or mailbox entry yet.

If every single message routed from Google to M365 bounces back with an access restriction error (like 550 5.7.1 Service unavailable or 550 5.4.1 Recipient address rejected), you are on a high-risk path. Your downstream partner connector is either entirely missing, disabled, or configured with the wrong IP validation constraints, halting cross-platform production traffic immediately.

How Split Delivery Handshakes Break

Split delivery divides your domain’s incoming mail stream across two separate server infrastructures. Google Workspace handles your primary MX records, processes the incoming handshakes from the internet, and delivers messages to its local mailboxes. If an address doesn’t exist locally, or matches an explicit routing rule, Google acts as an inbound proxy and forwards that exact email payload downstream to Microsoft 365.

This transition is where the breakdown occurs. Microsoft 365 receives an email originating from an external sender (e.g., sender@customer.com), but the physical server knocking on its door belongs to Google. Without explicit instruction, M365’s integrated security filters see this as a spoofing attempt. Because the sending server’s IP address (Google’s relay) does not match the original sender’s public DNS SPF records, the Microsoft platform drops or bounces the message immediately.

Split Delivery Routing Architecture

The graphic below maps the path an inbound email follows through a split delivery system, highlighting how a primary mail system evaluates local mailboxes before handing traffic off to a secondary environment.

Probability Breakdown

• Missing or Misconfigured M365 Inbound Partner Connector: 60%
• M365 Domain Set to Authoritative Instead of Internal Relay: 25%
• Google Workspace Routing Rule Target Host Typos: 10%
• Directory Synchronization Failures (Missing Cloud Aliases): 5%

What Increases the Risk

• Enforcing Strict DMARC p=reject Policies: If your organization uses an aggressive DMARC profile without configuring an authenticated partner connector, downstream servers will enforce strict alignment rules and automatically drop routed payloads.
• Changing Outbound Gateways: Tweaking internal routing rules within the Google Admin Console without validating whether the downstream Exchange environment is explicitly watching those specific smart-host IP addresses.

Consequence Timeline

• 24 Hours: Immediate delivery failures across environments; users assigned to M365 miss critical client communications while Google logs continue to stack up retry attempts.
• 1 Week: Disjointed cross-platform tracking data complicates auditing; automated senders interpret recurring blocks as dead addresses and strip your users from external distribution databases.
• 1 Month: Severe degradation of synchronization workflows; administrative teams are forced to dismantle the split-delivery environment and speed up mailbox migrations prematurely.

What This Is Confused With

A split delivery failure is frequently confused with an email loop, which carries a separate footprint. If you are experiencing a looping state where traffic bounces indefinitely between platforms, see How to Fix “Email Loop Detected” in Routing.

It is also distinct from 550 5.1.1 account errors caused by a permanently decommissioned profile. Split delivery blocks occur midway through active transit paths because of architectural gateway policies, not because a user account was completely deleted from the organization.

What To Do Right Now

Log in to your Microsoft 365 Admin Center and open the Exchange Admin Center (EAC). Navigate to Mail flow > Connectors and verify if an Inbound Connector of type “Partner” exists for your domain. If it does not, or if it is turned off, this is your breaking point. Google cannot hand off mail to your Microsoft tenant until this trusted inbound path is live and active.

Hard-Stop Triggers

• Stop modifying individual user address configurations if you see 550 5.7.606 Access denied, banned sending IP. This message indicates a platform-level IP block at the Microsoft gateway. Further changes inside Google Workspace will have zero effect until you resolve the tenant block inside the M365 Security & Compliance console.

What an Admin Will Check

• M365 Accepted Domain Configuration: Under Mail flow > Accepted domains, the primary shared domain must be explicitly flagged as Internal Relay. If it is set to Authoritative, M365 will instantly reject any incoming mail for users it does not already have recorded in its local Azure Active Directory.
• Google Host Smart-Host Settings: In the Google Admin Console under Apps > Google Workspace > Gmail > Hosts, the target destination for your M365 routing rule must point directly to your tenant’s MX endpoint (e.g., yourdomain-com.mail.protection.outlook.com) using port 25.
• Connector IP Lockdowns: Ensure that your M365 Inbound Partner Connector is configured to identify Google by its IP addresses rather than by certificate matching, as Google’s shared relay outbound certificates use generic pool names that change over time.

Typical Effort Range

• Minor (20–45 minutes): Adjusting the accepted domain status from Authoritative to Internal Relay and enabling an existing, misconfigured connector profile.
• Moderate (1–2 hours): Collecting current outbound Google Workspace IP blocks, manually building out a fresh Inbound Partner Connector in M365, and allowing cloud edge nodes to sync the updated rules.

Related System Escalators

If your environment requires custom user conversions or specific address translation tables alongside standard split delivery rules, see Troubleshooting “Default Routing” vs. “Address Mapping”. For issues specifically tied to migration environments and dual-delivery delay patterns, reference Troubleshooting “Dual Delivery” Lag in Migrations.

Workspace Assessment

To stabilize your split delivery setup, update your shared domain type to Internal Relay inside Microsoft 365 and anchor it with an Inbound Partner Connector linked directly to Google’s public routing ranges. This tells the Microsoft gateway to skip standard external spoofing checks for traffic flowing through Google’s relays. Once these options are applied, cross-platform traffic will flow seamlessly without drops or bounces.