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
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.
The RelayBridge source code is public under the Mozilla Public License 2.0 and available for direct review.
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 source, sender, and mode restrictions. RC1 has no inbound STARTTLS, so device SMTP—including reusable authenticated-mode credentials—must remain on an explicitly trusted private network.
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
RC1 management is bound to local loopback and does not provide LAN web management, remote management, or a cloud management plane.
Secret handling
The released setup flow uses short-lived interactive Microsoft administrator authentication. The long-running service does not retain Microsoft administrator passwords or delegated administrator tokens.
Privileged setup
Temporary privilege, not a runtime credential.
PUBLIC RC STATUS
RelayBridge v1.0.0-rc.1 is available as an unsigned public pre-release. Its official GitHub Release includes checksums, a CycloneDX SBOM, release provenance, and third-party notices. It is not a signed stable release. Review the release status.
The released RC1 flow uses temporary Microsoft administrator authentication only during setup. The long-running RelayBridge service does not retain Microsoft administrator credentials or delegated administrator tokens. See the Microsoft 365 setup documentation for the current candidate, certificate, Entra, Exchange RBAC, verification, and activation sequence.
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.
Windows client scope
RC1 supports Windows 10/11 x64 with one locally interactive administrator. Windows Server, Server Core, RDP-native setup, x86, and Arm64 are not claimed. A signed stable release is not yet available.
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.
Public source and RC
Review the security boundary.
Inspect the public MPL-2.0 source and the evidence accompanying the unsigned v1.0.0-rc.1 evaluation release.