Product
Two mechanisms, because one is never enough.
A signature product that only writes a provider's setting cannot handle aliases. One that only injects at compose time cannot reach a client without an add-in. Layerit does both, and picks per provider.
Plane A · native write
Write into the provider's own setting
Layerit renders the signature and writes it where the provider keeps it. On Google that is the sendAs signature, which now reaches Gmail mobile as well as the web. On Zoho it is the per-user signature object, which administrators set and users cannot quietly change.
- Reaches clients no add-in can instrument
- No per-person OAuth consent
- No employee action, so nobody can forget
- Static per mailbox — the trade-off is dynamism
Plane B · compose injection
Resolve at the moment of sending
Where a compose hook exists, an add-in resolves the signature for the current From identity as the message is written. That is what makes aliases, shared senders, campaigns and per-locale variants possible.
- Per-From, per-campaign and per-locale signatures
- Covers replies and forwards, because it writes the draft
- Reaches Outlook desktop and mobile for Microsoft 365
- Runs only where the add-in is deployed, usually by an admin
Templates
Signatures are content, and content drifts unless it is structured.
The template editor is where bad signature tools give themselves away: upload an image, paste some HTML, and watch it rot the moment someone changes job titles.
Structured content, not HTML blobs
A template is composed of fields bound to directory attributes, not a hand-pasted screenshot. Rendering to HTML happens at write time, so the same template feeds Gmail's HTML signature and an add-in's insertion path.
Brand kit per unit, group or location
Logo, accent colour and legal footer belong to a business unit, a group or a location, not to the whole organisation. A company with several trading names gets each one exactly right, including the registered entity in the footer.
Legal footers that follow the rule
Disclaimers, registered numbers and office addresses are part of the template, so a change in counsel's wording propagates everywhere rather than living in a PDF someone forgets.
Directory sync
The directory owns every field. Employees edit none of it.
Self-service signature editing is where brand control goes to die. Layerit reads names, titles and contact details from the directory that already owns them, so there is no per-field permission system and no approval queue.
- Name and title
- Read from the provider directory and refreshed on a schedule, so a promotion does not wait on someone editing a signature.
- Contact details
- Phone numbers, office location and profile photo, with per-location overrides where the directory is incomplete.
- Administrator overrides
- Where the directory is wrong or silent, an administrator sets the value. Nothing is writable by the person, which removes the approval workflow entirely.
- Departures
- When a mailbox disappears from the directory, its signature is retired rather than left stale in an outbound footer.
Shared senders
When support@ writes, the signature should say support@.
An individual`s signature on a shared sender is a small error that reads as a large one. $Layerit` resolves the signature for the identity the message is actually from.
- Shared mailboxes and delegated inboxes
- Aliases and send-as addresses
- Distribution lists and groups
- Org-attribute rules, such as region or department
Hi Priya — thanks for the call. Short version: the new pricing holds for the whole term.
Best,
Amara Okafor
Head of Partnerships · Acme Group
amara@acme.example+44 20 7946 0521
Acme Group Ltd · 12 Ludgate Square · London EC4M 7AS
sendAs.Hi Priya — thanks for the call. Short version: the new pricing holds for the whole term.
Best,
Amara Okafor
Head of Partnerships · Acme Group
amara@acme.example+44 20 7946 0521
Acme Group Ltd · 12 Ludgate Square · London EC4M 7AS
Reconciliation
The dashboard only helps if it matches the mailbox.
Most providers let a person edit their own signature, and one class of mobile client lets them set one no API can see. Layerit reads each managed mailbox back, compares it against the intended state, and reports the difference with a recommended action.
See the coverage caveatsCoverage
What actually reaches which client.
No buyer should have to take this on trust. The qualifiers in the table are part of the answer, and the notes below it are the parts that do not fit in a cell.
| Client | Google Workspace | Microsoft 365 | Zoho Workplace |
|---|---|---|---|
| Webmail | Covered | Coveredadmin deploy | Covered |
| Desktop app | Covered | Coveredadmin deploy | Not covered |
| Mobile app | Coverednative fallback | Coveredadmin deploy | Not covered |
| Aliases and send-as | Conditionalper alias | Conditionalshared perm | Conditionalunverified |
| Shared mailbox | ConditionalGroups | Conditional1.13 required | Conditionalno signature object |
| Replies and forwards | Conditionalnew mail only | Covered | Conditionalscript dependent |
- CoveredCovered — by the provider's own API
- ConditionalConditional — the qualifier in the cell applies
- Not coveredNot covered
- A device-local mobile signature wins.
- If someone sets a signature inside the Gmail mobile app, no API can detect or clear it. This is the one drift case that cannot be fixed by writing to a mailbox.
- Microsoft needs an admin.
- The add-in is the only cross-client path, and event-based activation only runs automatically for centrally deployed add-ins. Store installs stay inert, which is why onboarding deploys it for you.
- Zoho has no bulk write.
- The native signature API is per-user, so every mailbox is written one request at a time. The signature it writes is applied when composing in Zoho Mail on the web and in the Zoho Mail mobile app.
See the current state of your signatures before changing anything.
Connect a provider and Layerit renders every mailbox's signature state, including the ones that have drifted, without writing a single change.