Customer-Hosted vs Vendor-Hosted Email Signature Processing: What Actually Happens to Your Mail

Server-side email signature management has become standard practice for organisations running Microsoft 365. Instead of hoping that every device and Outlook profile applies the right signature, a central service applies it consistently as mail leaves the tenant. What is discussed less often is what that architecture means for the path your email travels — and which questions a security review should ask before the first connector is created.

What happens when Microsoft 365 routes mail through a signature service

For a server-side service to modify a message, the message has to reach that service. In Microsoft 365 this is typically implemented with transport rules and connectors: outbound mail matching defined conditions is redirected from Exchange Online to the processing service, and a second connector accepts the modified message back for final delivery. Microsoft documents this pattern as the standard way to integrate an email add-on service.

While the message is with the processing service, it is handled as a complete MIME message. That includes:

• sender and recipient addresses and the full header set
• the subject line and the message body, in every format the message carries
• attachments and embedded content, because they are part of the MIME structure
• whatever the service itself injects, such as signatures, disclaimers or campaign banners

The service parses that structure, inserts or rewrites the signature HTML, reassembles the message and hands it back to Microsoft 365 for delivery. When the vendor hosts this processing plane, every outbound message in scope passes through the vendor's infrastructure — briefly, but completely.

Transient access is still access

Many hosted vendors state, credibly, that they do not retain message content. That is a meaningful control and worth verifying. It is not, however, the same thing as no access. A no-retention policy limits how long data stays; it does not change the fact that the vendor's systems receive and process the full message in transit, or that the vendor's staff, tooling and update pipeline sit inside that path.

This is not an accusation of wrongdoing, and it does not make hosted services unsafe. It is simply an accurate description of the architecture, and it is the description a security review should start from. A hosted signature service can be well secured and still constitute an additional trust boundary.

What a security review should cover

• Trust boundary. A new operator — with its own systems, support processes and privileged administrators — is added alongside Microsoft 365. Who can reach the processing plane, and under what controls?
• Supply chain. The service sits in the path of every outbound message in scope. An incident, a faulty update or an operational failure at the vendor can affect many tenants at once. NIST guidance treats technology providers as part of cybersecurity supply-chain risk management, and due diligence should be proportionate to that position.
• Availability and mail flow. Outbound deliverability now depends on the relay's uptime, its certificates and correct connector configuration. What happens when the service is unreachable — does mail queue, bypass the service or fail?
• Message authentication. Modifying messages in transit can affect DKIM validity and requires careful connector, TLS and, depending on the flow, ARC configuration.
• Identity and permissions. Which tenant-wide consents and application permissions does the service require, and is each one justified by a specific function?
• Logging and forensics. Which metadata is logged, where, for how long, and who controls access to those logs?

What customer-hosted (BYOC) processing changes

In a customer-hosted model — SignaGrid Private is designed as exactly this deployment option — the processing plane runs in the customer's own cloud environment. The vendor's infrastructure is removed from the email path: messages are redirected to a relay the customer operates, in a region the customer chooses, secured with keys and secrets the customer controls.

That changes the answers to several review questions:

• message content stays within an environment governed by the customer's own security policies
• logs and their retention remain in the customer's environment
• the customer decides update windows and can gate support access to the runtime
• there is no shared processing runtime, so an operational issue affecting another organisation does not run on your infrastructure

What BYOC does not remove

Customer-hosted processing is an architectural shift of responsibility, not an automatic security upgrade. The customer now owns concerns the vendor previously absorbed:

• Securing the relay. Hosts, network segmentation, secrets, certificates and access to the processing environment are the customer's to harden and monitor.
• Mail-flow design. Connectors, routing scope, failure behaviour and emergency bypass procedures still have to be designed, documented and tested.
• Deliverability. SPF, DKIM, DMARC and, where relevant, ARC still matter. A private relay that modifies messages participates in the same authentication chain as any other relay, and misconfiguration harms deliverability just as effectively.
• Operations. Capacity, monitoring, patching and a tested upgrade path become part of the customer's operational estate.

A poorly operated private relay can be weaker in practice than a competently run hosted service. The value of BYOC is not that it is automatically secure; it is that the trust boundary, the data path and the operational controls are yours to govern and to verify.

Choosing between the models

Neither model is universally right. A managed cloud service such as SignaGrid Cloud suits organisations that accept an external processor in exchange for lower operational effort — provided the vendor is transparent about the data flow and can evidence its controls. A customer-hosted deployment such as SignaGrid Private suits organisations whose regulatory, contractual or internal risk requirements rule out an external party in the email path, and which are prepared to operate the relay properly.

The useful question is not which model is safer in the abstract. It is which trust boundaries your organisation is willing to accept, and which ones it needs to own.