Email Signature Cloud is a brand-governance surface. A marketing or IT operator authors signature templates, attaches rules and campaigns, and tawqi3 applies the resulting signature on outbound mail. This article covers the moving parts at a level useful for a buyer or an administrator.
How it works in one paragraph
A connector keeps your directory in sync with tawqi3, so every employee has an up-to-date set of attributes (name, title, team, location). The template engine renders an inline-styled HTML signature plus a plain-text alternative. The signature is then placed on outbound mail either by a small add-in in your mail client or by a server-side rule inside your mail platform. Either way, the signature is applied consistently, branded the way you want, and updated centrally whenever you change a template.
Authoring
Templates are authored in the template studio. Each template can carry:
- Variant blocks (per-locale or per-brand subsidiaries).
- Field bindings to directory attributes such as display name, title, or office.
- Asset references for logos and social icons, served from tawqi3 via short-lived signed URLs so they always render correctly.
Templates are sanitised on save, so a template author cannot smuggle in scripts or unsafe markup.
Rules and campaigns
A rule lets you apply different templates to different audiences, for example, one signature for the sales team and another for support. A campaign layers on a time window and an audience, so you can run a seasonal promotion or a product launch banner without manually editing each template. Campaigns are evaluated first, then rules.
Two delivery modes
| Mode | Where the signature is applied | Setup cost |
|---|---|---|
| Add-in | Inside the mail client compose window | Per-user install through your workplace app marketplace |
| Server-side | Inside your mail platform, on every outbound message | One-time administrator configuration |
The add-in path lets users see exactly what will be sent before they hit send. The server-side path is invisible to the user but catches every message, including those produced by automation.
Privacy
Signatures are rendered on tawqi3 infrastructure, but message bodies never leave your boundary. The applier sees only the placeholder, the sender identity, and the destination mailbox. Audit logs record that a signature was applied; they do not store the recipient list or the message contents.
title: Email Signature Cloud overview description: How tawqi3 governs centrally-controlled email signatures across Microsoft 365 and Google Workspace. category: Products updated: 2026-05-15 readMinutes: 6 order: 1
Email Signature Cloud is a brand-governance surface: a marketing or IT operator authors signature templates, attaches rules and campaigns, and tawqi3 applies the resulting signature on outbound mail. This article covers the moving parts at a level useful for a buyer or integrator.
Architecture in one paragraph
A connector syncs your directory (Microsoft Graph delta or Google Admin SDK) into tawqi3’s per-tenant principal store. The template engine renders an inline-CSS, sanitised HTML signature plus a plain-text alternative. The applier injects the rendered signature into a {{tawqi3_signature}} placeholder OR via a server-side transport rule that posts the message to our endpoint and inlines the result before it leaves your boundary. A dedup header (X-Tawqi3-Sig-Applied) prevents double-injection during retries.
Authoring
Templates are authored in the template studio (studio.tawqi3.com). Each template carries:
- Variant blocks (per-locale or per-brand subsidiaries).
- Field bindings to directory attributes (
{{principal.display_name}},{{principal.title}}, etc.). - Asset references (logos, social icons) served from SeaweedFS via a signed, short-lived URL the renderer resolves at applier time.
Output is run through bluemonday (HTML sanitiser) before persistence so a malicious template author cannot inject <script>.
Rules and campaigns
A rule is a cascade evaluator: subject the message to a sequence of attribute-and-attribute-value matches (e.g. principal.group == 'sales') and apply the first matching template. A campaign layers on a window (starts_at, ends_at) and an audience expression. The resolver evaluates campaigns first, then falls through to rules; both share the same template targets.
Two delivery modes
| Mode | Where the inject happens | Setup cost |
|---|---|---|
| Add-in | Client-side (Outlook Office Add-in 1.17 or Gmail Apps Script) | Per-user install via Microsoft 365 / Google Workspace marketplace |
| Server-side connector | Inside Exchange or Workspace via a transport-rule webhook | One-time admin configuration documented in our deployment guide |
The add-in path renders instantly in the compose window so users see what will be sent. The server-side path is invisible to the user but catches every message including those sent by automation that bypasses the client.
Privacy
Signatures are rendered on tawqi3 infrastructure, but message bodies never are. The applier sees only the placeholder, the principal id, and the destination mailbox; the original message stays in your tenant. Logs of “signature applied” events carry the principal id and a UTC timestamp, no recipient list, no message contents.