Customer PlaybooksZimbra — Signature Deployment Setup

Zimbra Email Signature Deployment Setup

Zimbra email signature deployment — set each user's signature via the Zimbra Admin SOAP API with a server URL and admin auth token

How to push your AdtoSign-managed email signatures into your Zimbra users' mailboxes. AdtoSign sets each user's zimbra email signature for them via the Zimbra Admin SOAP API, using a server URL + admin auth token connection to your Zimbra server.

Audience: Zimbra global admin (or a delegated admin with account rights). Your employees must already be synced into AdtoSign (Directory) and assigned a master signature (Signatures → master signature → assign users).

How it works

Zimbra uses a single, server-direct mode: AdtoSign authenticates to your Zimbra Admin SOAP endpoint (/service/admin/soap/) with an admin auth token, then uses delegated auth (DelegateAuthRequest) to act inside each user's mailbox — no per-user passwords or OAuth consent screens.

Per user, AdtoSign:

  1. Obtains a delegated user token via DelegateAuthRequest.
  2. Lists the user's signatures (GetSignatures) and looks for the managed slot named "AdtoSign - Managed Signature".
  3. Creates it (CreateSignature) or updates it in place (ModifySignature).
  4. Points the account's signature preferences at the managed slot (ModifyPrefs):
    • zimbraPrefDefaultSignatureId — new mail
    • zimbraPrefForwardReplySignatureId — replies and forwards
    • zimbraPrefMailSignatureStyle = outlook — placed above quoted text

The signature uses hosted image URLs (small HTML), so banner swaps propagate with no re-push. Your users' other personal signatures are left untouched.

Replies covered by API: unlike Gmail and Zoho, Zimbra's SOAP API can write the forward/reply signature preference — so AdtoSign guarantees the signature appears on replies and forwards without any per-user toggle.

Setup

  1. Get your admin auth token. Send a urn:zimbraAdmin AuthRequest (admin username + password) to the admin SOAP endpoint and copy the returned authToken value — the connection page shows a helper for this. The token is stored AES-256-encrypted and never exposed in API responses.

  2. Connect. In AdtoSign, open Directory → Connections → Zimbra and enter:

    • Server URL — your Zimbra host, e.g. https://mail.example.com:7071 (admin port on-prem) or :443 (Zimbra Cloud). The URL is normalized to its origin; the admin SOAP path is appended automatically.
    • Admin Auth Token — the token from step 1.
    • Allow self-signed certificate — enable only if your on-prem admin port uses a self-signed TLS cert.

  3. Test Connection. AdtoSign runs the same AuthRequest path it will use at deploy time. Common failures:

    ErrorCause
    TIMEOUTAdmin port not reachable from the public internet (firewall / internal-only 7071)
    TLS_ERRORSelf-signed or expired cert — enable the self-signed option or install a trusted cert
    DNS_ERRORHostname doesn't resolve — check the URL
    CONNECTION_REFUSEDPort closed — confirm 7071 (on-prem) / 443 (cloud) is open

    Firewall note: the admin SOAP endpoint must be reachable from AdtoSign's servers. An internal-only 7071 behind a firewall cannot be reached — either publish the port to AdtoSign's egress IPs or use the mail-flow gateway instead (signatures applied server-side in transit).

  4. Sync your directory (if not already) so AdtoSign knows your users, and assign each user a master signature.

  5. Deploy. Open Signatures → Deployment → Zimbra and click Deploy now (or wait for the next scheduled run). Per-user success/failure appears in Deployment → Logs.

Test first (recommended): deploy to a single pilot mailbox before rolling out to the whole org.

How it runs

  • AdtoSign fans out per user with automatic retries and re-syncs on a schedule to repair drift — a user who manually changed or deleted the managed signature is restored on the next run. Per-user status appears in Deployment → Logs.
  • A preference-write failure (signature written but reply/forward pref failed) is logged as a soft error — the new-mail signature is still deployed.

Deployment modes

Like the other native mailbox providers, Zimbra supports two modes per connection (signatureDeploymentMethod):

  • Visible wrapper — the managed signature slot described above. Users can see (and edit) it in their Zimbra preferences; drift re-sync restores it.
  • Tamper-proof (invisible) wrapper — a server-side stub stamped in transit by the AdtoSign relay; nothing user-editable is left in the mailbox. Requires an active mail-flow gateway — requests without one are rejected (TAMPER_PROOF_GATE_OFF). See the mail-flow setup guide for the Zimbra MTA trust step (zimbraMtaMyNetworks / dedicated :587 listener).

Limitations

  • Reachability: the admin SOAP endpoint must be publicly reachable (or use the mail-flow gateway path, which needs no inbound admin access).
  • Token expiry: the admin auth token has a server-side lifetime — when it expires, re-run the AuthRequest and paste a fresh token.
  • Not tamper-proof in visible mode: the managed slot is user-editable between drift re-syncs. For guaranteed signing use the tamper-proof mode (relay-gated) or the mail-flow gateway.
  • Admin SOAP only: deployment uses the admin endpoint (/service/admin/soap/), not the user-facing /service/soap/ — delegated auth is what lets the admin token act inside each mailbox.
  • Overwrite scope: only the managed slot is created/updated; unrelated personal signatures are left alone.
Was this page helpful?