---
summary: The principles ScaiLine is built on and the components that implement them.
order: 1
title: Architecture
path: concepts/architecture
status: published
---

# Architecture

## Four principles

**Never store the mail.** The hosted relay is an SMTP proxy without a queue: a message lives in
memory for one SMTP transaction and nowhere else. If you want even that avoided, the same
signing engine runs on your own server as a milter next to your Postfix.

**Never break or lose the mail.** Signing fails open per message. Any error, timeout, unknown
structure or oversized message passes through unmodified. On Postfix,
`milter_default_action = accept` means Postfix itself guarantees this even when the milter is
gone.

**Render when something changes, not when mail is sent.** Signatures are compiled per user when
directory data, templates, rules or campaigns change. On the mail path there is only a lookup and
an insertion; no database query and no rendering sits between a user and their outgoing mail.

**Standalone first, ecosystem-native second.** Every ScaiLabs product you add (ScaiKey,
ScaiSend, ScaiVault, ScaiLog, ScaiDNS, ScaiControl) makes ScaiLine better; the mail-flow
components do not depend on them at send time.

## Components

| Component | Role | Where it runs |
|---|---|---|
| `scailine-stamp` | The signing engine: analyses the message structure, decides whether to skip, inserts the HTML and text signature, and changes nothing else. The only code that ever modifies a message. | Inside every mail-flow component below |
| `scailine-milter` | Milter for Postfix, with a signed local copy of the organisation's signatures. | Next to your Postfix |
| `scailine-relay` | Hosted SMTP proxy for Microsoft 365. No queue, in memory only. | ScaiLabs relay tier, EU |
| ScaiSend stage | The same engine inside ScaiSend's delivery worker. | ScaiSend |
| `scailine-api` | Control plane: organisations, domains, directory sources, templates, rules, campaigns, legal entities, roles, mail-flow connections. | ScaiLabs, EU |
| `scailine-worker` | Directory sync, compilation, publishing, relay certificates, Microsoft 365 address ranges, statistics. | ScaiLabs, EU |
| Console | Administration, template designer with preview, *My signature*. | Browser |
| `scailine-outlook-addin` | Signature in the Outlook compose window, so Sent Items show it too. | Outlook (in development) |

## The mail path

1. **Guard.** A size cap (25 MB) and a per-message deadline (1.5 s). Exceeding either means the
   message passes unmodified.
2. **Scan.** A map of the message's parts is built without decoding any content.
3. **Skip.** Signed or encrypted mail (S/MIME, PGP, Microsoft Purview), TNEF, calendar
   traffic, automatic replies and delivery reports, messages already carrying a valid
   `X-ScaiLine` header, unknown senders and tenant skip rules are deliberately left alone.
4. **Locate.** The plain-text and HTML body parts are found in the usual structures. Anything
   unrecognised means pass-through; attached messages are never entered.
5. **Classify.** New message or reply, and internal or external recipients.
6. **Select.** The matching compiled variant: `external.new`, `external.reply`, `internal.new`
   or `internal.reply`. If the Outlook add-in already inserted the signature, only the remaining
   parts (legal footer, banner) are applied.
7. **Insert.** The HTML is inserted at the right position, above the quoted text in replies,
   without re-writing the rest of the HTML. Only the modified parts are re-encoded; every other
   byte, attachments included, stays identical.
8. **Images.** Images the template marks as *inside the message* are added as related parts
   next to the HTML, so they display without the recipient allowing downloads
   ([Templates](concepts/templates)).
9. **Header.** One `X-ScaiLine` header records what happened
   ([reference](reference/x-scailine-header)).

The markers that identify quoted text per mail client are data inside the compiled signatures,
so a new client quirk is fixed by publishing new data, not by upgrading servers.

## Getting compiled signatures to the mail path

The worker compiles a signature per user and publishes it. The hosted relay keeps an in-memory
cache and keeps serving from it if its store is briefly unreachable. The milter pulls a signed
snapshot of the organisation (Ed25519) over HTTPS, verifies it and keeps the last good one on
disk, so it keeps signing mail through control-plane outages for as long as they last.

## Microsoft 365 attribution

On the hosted relay a message is attributed to an organisation only when all three hold:

* it arrives over TLS from Microsoft's mail servers (Exchange Online Protection), whose address
  ranges ScaiLine takes from Microsoft's published list and refreshes daily;
* the sender's domain is verified for that organisation;
* the `X-MS-Exchange-CrossTenant-Id` header matches the organisation's registered Microsoft 365
  tenant.

A failure is rejected with a 5xx and never passed through. This is the one deliberate exception
to failing open: nobody else's Microsoft 365 tenant may route mail through your signature
configuration. Signed mail goes back to your tenant over a connection that presents a
certificate unique to your organisation, as Microsoft requires. See
[Microsoft 365](operating/microsoft-365).

## Shadow mode (hosted relay)

For a Microsoft 365 connection, shadow mode runs the full pipeline and records outcome and
variant (metadata only) while the original message is delivered. Pilots start there. The milter
has no shadow mode; pilot it by limiting a rule to a small group ([Rules](concepts/rules)).