Architecture

Architecture built for controlled Microsoft 365 mail flow

Sigora applies signatures within outbound Microsoft 365 mail flow using mTLS-secured SMTP routing and customer-defined signature rules.

Sigora server-side email signature processing flow between Microsoft 365 and outbound delivery systems.

Mail flow

High-level architecture overview

Sigora sits inline with outbound Microsoft 365 mail flow, applying signatures after messages are routed through the platform and before final delivery.

Microsoft 365 Outbound transport rule selects mail for processing.
mTLS outbound connector
Sigora Render and apply signature
mTLS inbound connector
Microsoft 365 Message continues through approved outbound flow.

Sigora uses mTLS-secured SMTP routing in both directions, allowing Microsoft 365 and Sigora to validate the trusted connector path during message transit.

Processing lifecycle

What happens when a message reaches Sigora

Sigora applies signatures during outbound mail processing before returning the message to Microsoft 365 for final delivery.

  1. 1Message is received from Microsoft 365.
  2. 2Sender is identified and rules are evaluated.
  3. 3Template is rendered and signature is applied.
  4. 4Message is returned to Microsoft 365 for final delivery.

Templates and attributes

Template and attribute resolution

Sigora resolves the most specific applicable signature configuration first, then falls back to broader defaults.

  • Templates can be assigned by user, group, or domain.
  • Add-on templates can support optional campaign or department-specific content.
  • Template variables are populated from Microsoft Graph and configured attributes.

Data handling

Data handling without persistent message storage

Sigora processes message content in memory only for the purpose of signature injection. Message bodies and attachments are not persistently stored.

What is not stored

  • Message bodies.
  • Attachments.
  • Subjects.
  • Recipients or BCC.

What Sigora stores to operate

  • Organization settings.
  • Signature templates.
  • Custom attributes.
  • Portal audit logs for configuration changes.
  • Non-identifying processing logs.

Resilience

Resilient inline processing

Sigora is designed to process mail inline. In HA deployments, traffic can be routed across multiple processing nodes using health-aware routing. If a message cannot be accepted or returned successfully, Sigora responds through SMTP so Microsoft 365 can handle retry or failure behavior according to mail-flow configuration.

Security controls

Security controls built into the architecture

mTLS-secured SMTP routing.

Least-privilege Microsoft Graph permissions.

Per-organization encryption keys.

RBAC for control plane users.

Audit logging without message content exposure.

Pre-registered processing nodes.

No persistent message body or attachment storage.

Review Sigora's architecture in your own mail flow

Validate routing, mTLS, data handling, and deployment fit before broader rollout.

Scroll to Top