Identity meets network reality
A design that works at headquarters can fail across stores, clinics, warehouses, and temporary sites. The mail settings may be identical while each location exits through a different ISP, rotating address, carrier NAT, security service, or port policy.
The branch-office problem
Connector-based SMTP relay sends to the tenant MX endpoint on TCP port 25. Exchange Online must attribute the connection to the organization. Microsoft supports that attribution through a TLS certificate—the recommended approach—or a static public IP address that is not shared with another organization.
At a branch, the printer usually owns neither identity. Its traffic is translated by a firewall or ISP, and its firmware may not be able to present the required accepted-domain certificate. Architecture must therefore be evaluated at the actual public egress boundary, not only on the printer configuration screen.
How Exchange Online connectors identify relay traffic
For IP-based relay, Exchange compares the public source address visible on the connection with the addresses configured on the inbound connector. Private RFC1918 addresses never reach Microsoft and cannot serve as connector identity.
For certificate-based relay, the sending system negotiates TLS and presents a certificate whose Subject or SAN contains an accepted domain. The connector validates that certificate identity instead of relying on the source IP.
Why dynamic IP and CGNAT break IP-based relay
Microsoft explicitly states that dynamic IP addresses are not supported or allowed for IP-based connector relay. When the ISP rotates a branch address, the new connection no longer matches the connector. Microsoft’s troubleshooting guidance associates 5.7.64 TenantAttribution; Relay Access Denied with a changed or mismatched IP or certificate.
Carrier-grade NAT creates another mismatch: multiple customers may share a public address, so the branch does not control an exclusive identity that can safely authorize relay. Cellular failover and some managed SD-WAN or secure-web-gateway paths can also change the egress address independently of the site firewall.
Continuously rewriting a connector whenever a dynamic address changes turns a security identity into a moving target. It also leaves gaps during failover and does not solve shared-address or port-blocking conditions.
Connector relay also depends on outbound port 25
Both connector relay and Direct Send use the tenant MX endpoint on TCP port 25. Microsoft warns that network firewalls and ISPs may block this port. A static IP alone is therefore insufficient; the site must also have a permitted, monitored port 25 path to Exchange Online.
Test from the same egress path used by the device. A headquarters test does not prove branch reachability, and a successful DNS lookup does not prove TCP access. Document behavior during primary-WAN failure as well as normal operation.
Port 587 is different: it is the recommended client-submission port and the HVE port. Switching a connector design from 25 to 587 is not a port-only change; it selects a different Exchange Online service and authentication model.
Certificate-based connectors are the documented alternative
It is inaccurate to say every Exchange Online connector requires a static IP. Microsoft recommends certificate-based connector authentication and allows the certificate Subject or SAN to contain an accepted domain. This avoids using the public source IP as the connector identity.
The alternative still has material requirements:
- The sending system must present and protect a suitable certificate.
- The certificate identity must match the connector and an accepted domain.
- The system must support TLS 1.2 or TLS 1.3.
- Outbound TCP port 25 must remain available.
- The device or server needs SMTP retry and operational logging.
A full mail server or capable centralized relay can meet those requirements. Many printers cannot, which is why the distinction between “device” and “site relay” matters.
Why Direct Send is not the same workaround
Direct Send also targets the tenant MX endpoint on port 25, but it does not use an inbound connector and cannot deliver to external recipients. Microsoft recommends a static public IP for SPF and expects correct SPF, DKIM, and DMARC for the accepted-domain sender.
For internal-only notifications, Direct Send may be viable when the site can operate the sender like an internet mail server. It does not address an ISP port 25 block, and it does not provide external relay.
Viable architecture patterns
Centralize connector relay
Route branch devices to a managed corporate mail server or relay that owns the certificate or stable IP, queueing, logs, and port 25 path. Secure the site-to-center transport and never expose an open relay.
Use native OAuth client submission
A capable device or application can use smtp.office365.com on port 587 with OAuth and XOAUTH2. It can send externally and does not depend on a static public IP.
Use HVE for internal high-volume mail
HVE uses port 587 and a dedicated account with credentials or OAuth, but recipients must be internal and the service has its own billing and message constraints.
Place a compatibility bridge at the site
A local bridge can accept the narrow SMTP capability already present, then own modern authentication, TLS, queueing, and retry upstream. Its local listener must be explicitly constrained.
How RelayBridge fits at a branch
RelayBridge v1.0 is designed to run inside administrator-controlled local infrastructure. Printers and applications submit to its restricted local listener; RelayBridge durably persists accepted messages and sends directly to Exchange Online using OAuth, XOAUTH2, TLS, and outbound port 587.
This upstream path does not use a source-IP connector, so it does not require a static public IP or an outbound port 25 exception. Certificate-based application identity and scoped Exchange Application RBAC are intended to constrain the configured sender.
The tradeoff is explicit: inbound STARTTLS is not currently available. The device-to-RelayBridge hop must remain on a trusted private network, limited to configured sources and senders. RelayBridge is pre-release; review the security boundary and release status before treating this as an available deployment pattern.
Branch-site assessment checklist
- 01
Record public egress
Is it static, exclusive, dynamic, shared through CGNAT, or changed by failover and security services?
- 02
Test ports per site
Verify 25 and 587 from the real device path on primary and backup WAN connections.
- 03
Inventory identity capability
Can the device use OAuth/XOAUTH2 or present an accepted-domain TLS certificate?
- 04
Define recipients and senders
Separate internal-only notifications from external delivery and document every permitted sender address.
- 05
Assign operational ownership
Decide who monitors queues, rotates certificates, reviews failures, patches the relay, and tests WAN failover.
Frequently asked questions
Can an IP-based Exchange Online connector use a dynamic public IP?
No. Microsoft explicitly states that dynamic IP addresses are not supported or allowed for the IP-based connector method.
Do all SMTP relay connectors require a static IP?
No. Microsoft recommends certificate-based connector authentication as an alternative, but it still requires a suitable certificate, modern TLS, and port 25.
Will Direct Send solve a dynamic-IP branch problem?
It removes connector identity but still uses port 25, is internal-recipient only, and benefits from a static IP for SPF and reputation.
Does port 587 work with an MX connector?
No. Port 587 is used by client SMTP submission and HVE. Connector relay to the tenant MX endpoint uses port 25.
Does RelayBridge require a static public IP?
The intended Exchange Online path uses authenticated submission over port 587, not source-IP connector identity, so no static public IP is required.
Official Microsoft references
- Microsoft Learn — Set up a multifunction device or application to send email using Microsoft 365
- Microsoft Learn — Fix issues with printers, scanners, and LOB applications
- Microsoft Learn — Fix 550 5.7.64 TenantAttribution errors
- Microsoft Learn — Exchange Online integration for outbound application email