Control plane
- Organization and Microsoft tenant settings.
- Published Base Templates and Modules.
- User, group, and domain assignments.
- Configured attributes and approved images.
- Roles and audit history for administrative changes.
How it works
Server-side signatures, with Microsoft 365 still in control of delivery
Sigora receives selected outbound messages from Microsoft 365 over an mTLS-secured connector path, resolves and applies the appropriate signature, then returns the message to Microsoft 365 for final delivery.
Message path
One deliberate processing sequence
Microsoft 365 remains the mail system of record. Sigora performs the signature step inline and returns the message to the approved Microsoft 365 flow.
1. Microsoft 365
An outbound transport rule selects the message for Sigora processing.
mTLS outbound connector
2. Sigora
Identify the sender, evaluate assignments, resolve attributes, render the published content, and apply the signature.
mTLS inbound connector
3. Microsoft 365
The message continues through the configured outbound delivery process.
Why this matters: signature behavior is independent of the sender's Outlook installation or device, while Microsoft 365 continues to control message selection and final delivery.
Configuration and processing
Administrative control stays separate from message processing
Administrators manage approved configuration centrally. Processing nodes use that configuration when a message arrives.
Processing path
- Accept a selected message from Microsoft 365.
- Resolve the effective published signature configuration.
- Render and apply the signature in memory.
- Return the message to Microsoft 365.
- Report processing outcome without ordinary message-content logging.
For exact assignment priority, Modules, attributes, and preview behavior, see the Organization Control guides.
Data handling
Message content is processed, not retained
During normal processing, Sigora handles the message in memory for signature injection. Message bodies and attachments are not persistently stored.
Not persistently stored during normal processing
- Message bodies and attachments.
- Subjects.
- Recipient and BCC values.
Stored to operate Sigora
- Organization and tenant configuration.
- Signature templates, Modules, images, and custom attributes.
- Administrative audit history.
- Non-identifying processing logs.
Diagnostic exception: authorized administrators can enable time-limited sensitive diagnostics for troubleshooting. Identifiable logs or full message dumps may then contain sensitive content. These controls are disabled by default, require an expiry, and are recorded in the audit log.
Security controls
Controls matched to each part of the architecture
mTLS-secured SMTP routing between Microsoft 365 and Sigora.
Least-privilege Microsoft Graph permissions.
Per-organization encryption keys.
Role-based access control for control-plane users.
Administrative audit logging without ordinary message-content exposure.
Pre-registered processing nodes and protected Controller communication.
No persistent message body or attachment storage during normal processing.
Resilience
Designed for inline processing and explicit failure behavior
Multiple processing nodes can support capacity and resilience. If a message cannot be accepted or returned successfully, Sigora uses SMTP responses so Microsoft 365 can apply the retry or failure behavior configured for the mail flow.
Controller high availability, node count, load balancing, and recovery design are deployment-specific. They should be validated for the selected Sigora release and licensed deployment rather than assumed from a generic topology.
Compare deployment responsibilityNeed to map Sigora to your mail flow?
Ask us about routing, mTLS, data handling, deployment boundaries, or a deeper technical evaluation.