Exchange Hybrid Mail Flow with Proofpoint: Using Transport Rules Instead of Connector Modifications

If your organization is running Exchange hybrid configurations and need to route outbound email through third-party security solutions like Proofpoint while maintaining their hybrid configuration. The common misconception is that you need to modify the Exchange on-premises send connector to point directly at Proofpoint instead of Exchange Online Protection (EOP).

⚠️ DO NOT Modify the Hybrid Connector

This approach is wrong and will cause ongoing maintenance headaches.

Why Modifying Connectors Fails

When you run the Hybrid Configuration Wizard (HCW), it automatically creates and manages send connectors between your on-premises Exchange and Exchange Online Protection. If you manually modify these connectors to point to Proofpoint, the HCW will reset them back to EOP every time you:

• Update certificates
• Modify hybrid features
• Run the wizard for any configuration changes

This creates a frustrating cycle where your mail flow breaks after routine maintenance, requiring manual intervention to restore Proofpoint routing.

Critical Authentication Differences

Exchange Online (EOP) Authentication

• Uses port 25 with TLS certificate authentication
• No username/password (SMTP AUTH) required
• Mutual TLS with certificate validation
• Certificates must match specific criteria for the hybrid trust

Proofpoint Authentication

• Typically uses port 25 with IP-based authentication
• May support username/password (SMTP AUTH)
• Often doesn't require certificate authentication
• Some configurations use API keys or IP allowlisting

The Hidden Complexity of Modifying Connectors

If you ignore this advice and modify the hybrid send connector anyway, you'll face a significant technical challenges:

The Certificate Authentication Problem

Note : I do not recommend you follow this section, it simply exists to explain why it’s a bad idea!

The HCW-created connector uses certificate authentication (TlsAuthLevel) which cannot be modified through the Exchange Admin Center GUI. You must use PowerShell:

# DO NOT DO THIS - Example of what would be required (but shouldn't be done)
# This shows the complexity you're introducing by fighting the HCW

# View current connector authentication settings
Get-SendConnector "Outbound to Office 365" | Format-List Name,TlsAuthLevel,TlsCertificateName,RequireTls

# You would need to modify authentication from certificate-based to none
# THIS WILL BE RESET BY HCW - Don't actually do this!
Set-SendConnector "Outbound to Office 365" -TlsAuthLevel None -RequireTls $false

# Then point to Proofpoint
Set-SendConnector "Outbound to Office 365" -SmartHosts "<proofpoint-POD-name>"

Every time you run HCW, it will reset these settings:

• TlsAuthLevel back to DomainValidation or CertificateValidation
• SmartHosts back to *.mail.protection.outlook.com
• TlsCertificateName back to your hybrid certificate
• RequireTls back to $true

This means you'd need to:

1. Document these PowerShell commands
2. Remember to run them after every HCW execution
3. Deal with mail flow outages until you notice and fix the reset
4. Train other administrators on this non-standard configuration

The Correct Solution: Transport Rules

Instead of fighting the HCW, work with it. Use Exchange Online transport rules to redirect mail to Proofpoint after it reaches Exchange Online. This approach preserves the hybrid configuration while achieving your security requirements.

Mail Flow Architecture

Your mail flow will follow this path:

Exchange On-Premises → EOP (Certificate Auth) → Exchange Online → Transport Rule → Proofpoint (IP Auth) → Recipients

Step-by-Step Implementation

Prerequisites

• Working Exchange hybrid configuration
• Proofpoint configured to accept mail from Exchange Online
• Appropriate licenses (Exchange Online or EOP licenses for on-premises mailboxes)

Step 1: Verify Current Hybrid Configuration

First, ensure your hybrid mail flow is working correctly without Proofpoint:

# On-premises Exchange Management Shell
Get-SendConnector | Where {$_.Name -like "*Office 365*"} | Format-List Name,AddressSpaces,SmartHosts,TlsAuthLevel,TlsCertificateName

This connector should show:

• SmartHosts pointing to your tenant's EOP endpoint (*.mail.protection.outlook.com)
• TlsAuthLevel set to DomainValidation or CertificateValidation
• TlsCertificateName matching your hybrid certificate

Do not modify this connector.

Step 2: Create Transport Rule in Exchange Online

1. Sign in to the Exchange Admin Center (https://admin.exchange.microsoft.com)
2. Navigate to Mail flow > Rules
3. Click Add a rule > Create a new rule
4. Configure the rule:

Name: Proofpoint Outbound

Apply this rule if:

• The sender domain is → croucher.cloud
• AND
• The recipient → is External

Do the following:

• Redirect the message to → [Your Proofpoint smart host]

Properties:

• Priority: 0 (highest)
• Mode: Enforce

5. Click Save

Step 3: Configure Proofpoint to Accept Mail

In your Proofpoint administration portal:

1. Add croucher.cloud as an authorized sending domain
2. Authorize Exchange Online IP ranges:
   • Add Exchange Online outbound IPs to your Proofpoint allowed senders
   • These IPs are documented in Microsoft's Office 365 IP and URL list
3. Configure SPF records to include Proofpoint:

   v=spf1 include:spf.protection.outlook.com include:_spf.proofpoint.com -all
   

4. Ensure Proofpoint is configured to:
   • Accept mail without certificate authentication from Exchange Online IPs
   • Deliver mail to final recipients

Step 4: Test Mail Flow

Send test emails from an on-premises mailbox to external recipients and verify the headers show:

1. Message originates from on-premises Exchange
2. Routes through EOP using certificate authentication
3. Processes through Exchange Online
4. Redirects to Proofpoint (no certificate auth required)
5. Delivers to final recipient

Use Message Header Analyzer to verify:

• TLS is used between on-premises and EOP
• Authentication shows as "Internal" in Exchange Online
• Proofpoint receives the message from Exchange Online IPs

Step 5: Monitor and Validate

Check mail flow using Exchange Online reports:

1. Go to Reports > Mail flow > Message trace
2. Search for messages from croucher.cloud
3. Verify they show "Redirected" status to Proofpoint

Understanding Authentication in the Flow

On-Premises to EOP

Authentication: Certificate-based mutual TLS
Port: 25
Validation: TlsCertificateName must match hybrid certificate
Result: Messages marked as "Internal" and bypass spam filtering

Exchange Online to Proofpoint

Authentication: IP-based or SMTP AUTH (configured in Proofpoint)
Port: 25
Validation: Source IP must be in Proofpoint's allowed list
Result: Proofpoint accepts and processes the message

Centralized Mail Transport Note

This configuration assumes you're not using Centralized Mail Transport. If you enable CMT in the HCW, all cloud mailbox outbound mail will route through on-premises first, which may affect your Proofpoint routing strategy.

Troubleshooting Common Issues

Mail Not Routing to Proofpoint

1. Check transport rule priority - it should be at or near the top
2. Verify rule conditions match your messages
3. Use message trace to see if rules are being applied
4. Confirm Proofpoint is configured to accept mail from Exchange Online IPs

Authentication Failures

• To EOP: Check certificate validity and TlsCertificateName configuration
• To Proofpoint: Verify Exchange Online IPs are allowlisted in Proofpoint

Certificate Warnings

• Between on-premises and EOP: Managed by HCW, check hybrid certificate
• Between Exchange Online and Proofpoint: Not applicable as Proofpoint uses IP authentication

SPF Failures

Update SPF records to include both Exchange Online and Proofpoint:

v=spf1 include:spf.protection.outlook.com include:_spf.proofpoint.com -all

The PowerShell Trap to Avoid

If you're tempted to modify the connector directly, remember:

• GUI doesn't show or allow modification of TlsAuthLevel
• PowerShell changes will be overwritten by HCW
• You're creating undocumented technical debt
• Future administrators won't understand why mail flow breaks after HCW runs

Conclusion

Don't modify Exchange hybrid connectors to accommodate third-party mail security solutions. The authentication complexity alone (certificate-based to IP-based) makes this approach unsustainable. Instead, use Exchange Online transport rules to redirect mail after it reaches the cloud. This approach maintains the integrity of your hybrid configuration, preserves proper authentication methods, and achieves your security objectives.

Remember:

• The Hybrid Configuration Wizard is authoritative the hybrid connectors
• Certificate authentication cannot be modified via GUI
• Transport rules are the correct solution for custom routing needs
• Let each system use its native authentication method