Security
A small surface, and the honesty to describe it.
Most signature products are asked two questions in a security review: what do you store, and what can you change? The answers here are short, which is the point of the architecture.
What we hold
Enough to render a signature. Nothing more.
- Directory attributes
- Display name, job title, primary address, phone numbers, office location and profile photo, read from the provider directory to render signatures.
- Templates and brand kits
- The signature templates a tenant authors, plus the logos, palettes and legal footers scoped to each domain.
- Reconciliation state
- The signature value read back from each managed mailbox, kept so drift can be shown over time and compared against intent.
- Audit trail
- Who changed a template, a brand kit or a campaign, and when. Enough to answer what happened without keeping a shadow copy of the mailbox.
What we never hold
The list that makes the review shorter.
- Message bodies, subjects or attachments
- Recipients, other than the address being signed as
- Mail flow: Layerit is never a relay, proxy or journaling target
- Employee passwords, tokens or mailbox delegation keys
A relay architecture would make the coverage story simpler and the trust story much worse. We chose the other trade.
Scopes
Least privilege, per provider.
GmailGoogle Workspace
Domain-wide delegation is used to read directory attributes and to patch the sendAs signature. Nothing in the Gmail message scope is requested, which keeps the integration out of message content entirely.
OutlookMicrosoft 365
The integration is an Office add-in plus the minimum Microsoft Graph permissions to read directory attributes. Graph has no signature API, so no mailbox-writing scope is requested because none exists.
Zoho MailZoho Workplace
A per-user signature write through the organisation accounts API, plus directory read.
Isolation
Separated at the database, not in the query.
Tenant isolation
Every organisation's data lives in a database of its own, so a query for one organisation cannot reach another's rows: there is no shared table to filter wrongly.
Credentials
Provider tokens and signing keys are encrypted at rest, scoped to a single tenant, and never exposed to a browser. Writes happen from the server side on your behalf.
Change log
Template, brand kit and campaign changes are recorded with the actor and time. Drift findings keep the state they were found in, so a finding can be reviewed after the fact.
Coverage
What we can reach, and where the limits are.
An organisation that believes a signature is enforced when it is not has a compliance problem, not a branding one. So the limits are published alongside the capabilities.
| 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
Known limitations
- Device-local mobile signatures cannot be detected or cleared.
- A person who sets a signature inside the Gmail mobile app keeps it. This is handled in onboarding guidance and reported as a documented limitation.
- Aliases on Google require domain-wide delegation.
- Without it, non-primary send-as addresses cannot be written, and Layerit reports them as uncovered rather than assuming success.
- Shared senders are provider-specific.
- Microsoft shared mailboxes need a recent add-in requirement version and the right mailbox permission; Google Groups as a sender remains unverified, and is labelled as such.
- Zoho groups and aliases are not signed.
- Zoho's signature API cannot associate a signature with a group or a send-as alias, so group addresses are synced for reporting but never signed.
Google assessment
About the annual Google security assessment.
Reading or writing Gmail data with restricted scopes triggers a third-party security assessment, renewed every twelve months, with a cost that does not scale down for small customers. It is a real constraint on how a product like this can be priced, and it shapes our scope choices: the Google integration is deliberately built to request as little as possible, and the product needs no Marketplace add-on because the native sendAs write already reaches mobile.
We would rather explain that trade than quietly pass a compliance line item into every plan.
Send us your security questionnaire.
We will answer it against the architecture as built: data held, scopes requested, isolation model and the coverage limits above. No sales gate.