For years, Microsoft has allowed the use of IP-based connectors in Exchange Online to authenticate mail flow. However, as more organizations move toward shared infrastructure, multiple MTA (Mail Transfer Agent) systems, or shared public IP addresses, IP-based authentication has proven to be increasingly unreliable.
To address these challenges and ensure secure, accurate mail routing, Microsoft is moving toward Certificate-Based Connectors (CBC).
The Problem: Tenant Attribution Errors
When using traditional IP-based connectors behind a shared MTA or a security gateway, Exchange Online often struggles to identify the correct destination tenant. If multiple Microsoft 365 tenants share the same source IP, traffic may be routed through the wrong tenant environment.
The consequences are as varied as they are disruptive:
- SPF Failures: Legitimate emails are flagged as spoofed.
- Relay Denied Errors: Outbound mail is blocked because the tenant cannot be verified.
- Misrouted Traffic: Emails might be processed according to the policies of a completely different organization.
- Logs in the wrong tenant: As traffic might be directed towards another tenant, logs might not visible for the affected customer.
The Solution: Identification via SN and SAN
To resolve this, Microsoft now identifies the specific connector—and thus the correct MS365 tenant—using the Subject Name (SN) or the Subject Alternative Name (SAN) field of a TLS certificate.
By implementing certificate-based connectors, you ensure that Microsoft can perfectly isolate and attribute traffic to the correct tenant, regardless of the source IP address.
The certificates used for CBC must fulfil the following requirements:
•The certificate must not have expired or been revoked.
•The Subject Name (CN) or Subject Alternative Name (SAN) must match the public hostname of the SEPPmail Secure Email Gateway.
•The revocation status must be verifiable (CRL or OCSP).
•The certificate must be signed by a trusted certification authority.
Implementation with SEPPmail
For environments using a SEPPmail appliance, the configuration must be adjusted to address for this domain-specific certificate to be presented for each tenant or domain. Please keep the following key points in mind:
- Granular Configuration: You must configure one certificate-based connector per Microsoft 365 tenant, not per domain.
- Chain of Trust: It is critical that the entire certificate chain—including all root and intermediate certificates—is correctly installed and trusted on the SEPPmail appliance.
- Documentation: SEPPmail provides a detailed manual on how to execute this configuration effectively.
SEPPMail already has a manual on how to configure this.
Troubleshooting: Relay Access Denied
If the certificate chain is incomplete or the connector is misconfigured, Exchange Online will reject the connection. Typically, you will encounter the following SMTP error in your logs:
my-ms365-tenant.mail.protection.outlook.com [52.0.0.0] said: 550 5.7.64 TenantAttribution; Relay Access Denied
If you see this message, the first step should always be verifying the certificate deployment on your gateway and ensuring the SN/SAN matches the settings in the Exchange Admin Center (EAC).
Update the SEPPMail Rules and Connectors in MS 365 EXO
If you encounter any continuing issues when moving the connectors and transport rules to CBC in MS365, we generally recommend recreating them according to the SEPPMail manual using the SEPPMail365 PowerShell plugin.
