Local data path
A message moves from the submitting device to the administrator-controlled RelayBridge instance, then directly to Microsoft 365. RelayBridge does not operate an intermediary cloud relay.
Current Microsoft 365 security model
Trust starts with
a visible boundary.
This current Microsoft 365 security model shows administrators where mail goes, which identity RelayBridge uses, what is stored locally, and which limitations still matter.
MAIL PATHDevice → RelayBridge → Microsoft 365
IDENTITYLocal certificate, no client secret
PRODUCT CLOUDNone in the delivery path
CURRENT MICROSOFT 365 SECURITY BOUNDARY
LANTrusted private LANDevice intake boundary
LOCALRelayBridge local boundaryAdministrator-controlled host
IDENTITYLocal certificate identityPrivate key remains local
SCOPEExchange Application RBACAuthorized sender scope
M365Exchange OnlineNo RelayBridge-operated cloud relay
Security philosophy
Minimize hidden trust.
RelayBridge exists to modernize a narrow boundary without creating a new hosted mail dependency. The security model favors local control, a publicly documented architecture, constrained Microsoft authorization, durable state, and accurate delivery semantics.
01
Keep the path direct
Mail moves from infrastructure you control to Microsoft 365.
02
Use modern identity
Certificates and OAuth replace a stored Microsoft password or client secret.
03
Say what success means
SMTP acceptance by Microsoft 365 is not a claim of inbox placement.
Architecture and controls
Public security model
Microsoft identity
The architecture uses a dedicated Entra application, a certificate-based client credential, an Exchange resource OAuth token, XOAUTH2, and mandatory outbound TLS. It does not use a permanent client secret.
Certificate and private key
The certificate private key remains local to the RelayBridge system. Microsoft receives the public certificate material needed to verify application identity—not the private key. Administrators remain responsible for securing and rotating local key material.
Microsoft authorization
Exchange Application RBAC is used with Application SMTP.SendAsApp, scoped to the configured sender. The goal is sender-specific SMTP authorization rather than broad tenant mailbox access; the effective boundary still depends on correct Exchange configuration.
Device intake restrictions
A device is allowed to submit only under configured restrictions. Because inbound STARTTLS is not currently available, authenticated device intake requires an explicitly trusted private-network address in the current design.
Queue and durability
The message payload and its queue metadata are retained locally. RelayBridge considers a message locally accepted only after the durable persistence boundary. Temporary failures retry, and queued work can recover after an unexpected restart.
Management interface
Normal local management is designed to remain loopback-only in the current architecture. RelayBridge does not claim LAN web management or a cloud management plane.
Secret handling
The long-running service is designed not to retain Microsoft administrator passwords or delegated administrator tokens. Native Microsoft setup behavior is under final development and security validation for v1.0.
Privileged setup
Temporary privilege, not a runtime credential.
DEVELOPMENT STATUS
Native Microsoft setup is under final development and security validation for v1.0.
The planned model uses temporary Microsoft administrator authentication only during setup. The long-running RelayBridge service is not intended to retain Microsoft administrator credentials or delegated administrator tokens. Final public setup documentation will be published after the implementation and privilege boundaries are frozen.
Known limitations
Current boundaries to plan for
No inbound STARTTLS today
Printer-to-RelayBridge SMTP is not currently TLS protected. Device intake must be placed on an explicitly trusted private network. RelayBridge-to-Microsoft 365 remains TLS protected.
Platform support is not frozen
RelayBridge is being developed primarily for Windows. The final compatibility matrix and packaging are not yet published.
Microsoft acceptance is not inbox delivery
A successful final SMTP response establishes acceptance by Microsoft 365. Filtering, policy, routing, and inbox placement happen after that boundary.
Explicit non-goals
RelayBridge does not
- operate a cloud mail relay;
- store Microsoft administrator passwords;
- use a permanent client secret;
- upload the certificate private key to Microsoft;
- use Microsoft Graph as the mail-delivery transport;
- intentionally request broad Graph mail permissions for normal SMTP delivery; or
- claim an SMTP 250 response means inbox delivery.
Responsible disclosure
Report security concerns privately.
Please do not publish suspected vulnerabilities in an open issue. Until a dedicated security contact is confirmed, use the general project contact: info@getrelaybridge.com.
Open development
Inspect the project as it develops.
RelayBridge is preparing for v1.0. Follow the organization for source, releases, and documentation updates.