---
summary: ScaiLine puts a correct, centrally managed signature under every email your
  organisation sends, whatever client wrote it.
order: 2
title: Overview
path: overview
status: published
---

# Overview

ScaiLine is ScaiLabs' centralised email-signature service. It puts a correct, centrally managed
signature under every email an organisation sends, whichever client was used to write it: a
desktop mail client, webmail, a phone, or an application. Signatures are built from identity
data you already keep in your directory and from templates you design once in the ScaiLine
console. It replaces tools such as Exclaimer and CodeTwo, runs in the EU and, if you want,
entirely on your own mail server.

## Why it exists

Signatures are the most-read piece of corporate identity and the least controlled one: every
client has its own, every user edits theirs, legal footers drift, phone numbers go stale and a
campaign banner takes a week to roll out. Server-side signature tools solve that, but the
established ones require your mail to leave your platform and be stored on the vendor's side.
ScaiLine never stores mail.

## How it works, in one paragraph

Signatures are **rendered when something changes** (a directory attribute, a template, a rule),
not when a message is sent. The result is a compiled signature per user. On the mail path,
ScaiLine only looks that up and inserts it into the message: the HTML and plain-text signature go
in the right place (above the quoted text of a reply, never inside it), one `X-ScaiLine` header
records what happened, and every other byte of the message, attachments included, stays exactly
as it was. Every step fails open: when in doubt, the message continues unmodified. A missing
signature is a bug; a lost or delayed message would be an incident, and ScaiLine is built so that
the second does not happen.

## Where it runs

| Your mail platform | ScaiLine component | Where the message is processed | Status |
|---|---|---|---|
| Postfix-based: grommunio, Mailcow, your own Postfix | `scailine-milter` | On your own mail server; the message never leaves it | Available |
| Microsoft 365 | Hosted relay (SMTP proxy, no queue on disk) | ScaiLabs relay tier in the EU, in memory only | Preview, being validated with a pilot tenant |
| ScaiSend | Native stage inside ScaiSend | Inside ScaiSend's delivery worker | Built, awaiting release in ScaiSend |
| Outlook (add-in in the compose window) | `scailine-outlook-addin` | In Outlook while you write | In development |
| La Suite Messages | milter or native integration | | Planned |

See [Postfix and the milter](operating/postfix-milter) and
[Microsoft 365](operating/microsoft-365) for how each path is set up.

## What you manage in the console

* **Domains** you send from, verified with a DNS record.
* **Directory sources** that provide names, titles, phone numbers and addresses
  ([Attributes](concepts/attributes)).
* **Templates** built in a visual designer, with brand kits, conditional blocks and images
  that can travel inside the message ([Templates](concepts/templates)).
* **Rules** that decide which template applies to whom ([Rules](concepts/rules)).
* **Legal entities** and **campaign banners** that templates can include.
* **Mail-flow connections**: milter nodes for Postfix, the Microsoft 365 connection.

## Who it is for

Tenant admins who own brand and compliance, IT teams running a self-hosted Postfix stack or
Microsoft 365, and partners managing several organisations. End users only see a correct
signature, and can look at their own under **My signature**.

## Next

* [Quickstart](quickstart): from zero to a stamped message on a Postfix server.
* [Architecture](concepts/architecture): the principles and the components.
* [API reference](reference/api) and the [`X-ScaiLine` header](reference/x-scailine-header).