Signature Stamping — Manual Failover Guide (Gmail / Zoho / Zimbra)

Audience: customer mail admins on Google Workspace, Zoho Mail, or Zimbra. Microsoft 365 customers — your failover is automatic and you don't need this guide. See your Regional Failover toggle in the AdtoSign dashboard instead. Last updated: May 23, 2026.

What this is for

AdtoSign processes your outgoing mail through a signature gateway (a dedicated address like sgw-bom.adtosign.com). Your mail server is configured to forward outbound mail to this hostname.

Most outages are invisible to you — the gateway runs on dedicated regional VMs behind Cloudflare with health-checked failover. But in the rare case where the entire gateway for your region is unreachable, your mail server will start seeing temporary 4xx deferrals from us, and Google / Zoho / Zimbra will queue your mail and retry.

If we let you know an outage is going to last more than ~30 minutes, you have two options:

1. Wait it out — your mail keeps queuing in your platform's outbound queue (up to ~3 days for Gmail / Zoho / Zimbra default settings), and gets delivered automatically when we recover. Recommended for most cases.
2. Manually swap to a different region's gateway hostname — your mail keeps flowing in real time, but transits through a different region (US ↔ EU ↔ India ↔ APAC). Required if you have data-residency obligations or strict SLAs.

This guide covers Option 2.

⚠️ Before you begin

• Get the swap target hostname from AdtoSign super-admin support. We will tell you which region is currently healthy. Do not pick a region yourself — we know which app is down and which has spare capacity.
• Data residency check. If your home region is bom (India) and we recommend swapping to sin (Singapore), confirm this is acceptable under your DPDP / contractual obligations. If not — wait it out.
• Note the original hostname. You will revert to it after recovery. Take a screenshot.

The 4 gateway hostnames (any will work for any customer; egress IPs are pre-trusted across all four):

Google Workspace (Gmail)

Where the routing lives

Google Admin Console → Apps → Google Workspace → Gmail → Routing → Outbound gateway.

Swap procedure

1. Open https://admin.google.com → Apps → Gmail → Routing.
2. Locate the rule named "AdtoSign gateway" (or similar — the one with smart-host pointing to sgw-<region>.adtosign.com:587).
3. Click Edit.
4. Change the smart-host hostname from the old region to the new one (e.g., sgw-iad.adtosign.com → sgw-ams.adtosign.com). Keep port 587.
5. Save. Changes propagate in Google Workspace within ~5 minutes.
6. Send a test email from a Google Workspace mailbox to an external recipient. Verify your AdtoSign signature still appears.

Revert procedure (when AdtoSign confirms recovery)

Same as above, but change the hostname back to the original one. Propagation again ~5 min.

Verifying mail routing after swap

Google Admin → Reports → Email Log Search → search for any sender → Status column should be "Delivered"

If you see "Deferred" or "Bounced" for >10 min after swap, contact AdtoSign super-admin support immediately.

Zoho Mail

Where the routing lives

Zoho Mail Admin Console → Mail Administration → Outbound Gateway (or Smart Host Configuration depending on version).

Swap procedure

1. Open https://mailadmin.zoho.com → Mail Administration.
2. Find the entry for AdtoSign Outbound Gateway.
3. Edit the SMTP server hostname from the old region to the new one (e.g., sgw-bom.adtosign.com → sgw-sin.adtosign.com). Port stays 587. Authentication credentials do not change — they're tied to your account, not the region.
4. Save. Changes apply in Zoho within a few minutes.
5. Send a test email from a Zoho mailbox to an external recipient. Verify the AdtoSign signature.

Revert procedure

Reverse the change. Same propagation time.

Verifying mail routing

Zoho Mail Admin → Reports → Email Tracking

Your sent mail should show Delivered status; if Failed for > 10 min after swap, contact support.

Zimbra

Zimbra deployments vary widely — these instructions are for Zimbra 9.x with the standard zmprov tool. Adjust paths for your environment.

Where the routing lives

/opt/zimbra/conf/postfix_relayhost (or in Zimbra's admin UI: Configure → Global Settings → MTA → Relay MTA).

Swap procedure

# As zimbra user
zmprov modifyServer <your-mta-host> zimbraMtaRelayHost sgw-ams.adtosign.com:587

# Restart MTA
zmcontrol restart  # or zmmtactl restart

Or via UI:

1. Zimbra Admin Console → Configure → Global Settings → MTA.
2. Change Relay MTA from sgw-iad.adtosign.com:587 to e.g. sgw-ams.adtosign.com:587.
3. Save and restart the MTA service.

Authentication credentials (in /opt/zimbra/conf/relay_password) do not change.

Revert procedure

Reverse the zmprov command + restart MTA.

Verifying mail routing

# Tail the postfix log
tail -F /var/log/zimbra.log | grep relay

Look for relay=sgw-ams.adtosign.com and status=sent. If status=deferred for >10 min, contact AdtoSign support.

What if I get this wrong?

Symptom: mail starts bouncing immediately after the swap

You probably typed the hostname wrong. Revert immediately. Hostnames are case-sensitive in some platforms; copy/paste from this doc.

Symptom: signature stops appearing on outbound mail

The swap target is unreachable too (a wider AdtoSign outage). Revert and wait it out — Option 1 above. Your platform will keep queuing for hours or days.

Symptom: SPF authentication failures on the recipient side

Your SPF record at <yourdomain> should include:spf.adtosign.com. We maintain that record on our side and it lists the egress IPs from all four gateway regions, so the swap doesn't break SPF. If you didn't include our SPF record (you bypassed setup), do that now.

yourdomain.com  TXT  "v=spf1 include:spf.adtosign.com ~all"

(Or if you have other includes, just add include:spf.adtosign.com to the existing record.)

FAQ

Q: Why isn't this automated like Microsoft 365? For M365 we have programmatic access to your tenant's Exchange Online connectors via the Microsoft Graph API. For Gmail / Zoho / Zimbra, the routing config lives in your admin console and the platform vendors don't expose an API for partners to mutate it. So the swap is your call.

Q: Will I lose mail during the swap? No. Your platform queues outbound mail in-memory for the few seconds the change takes to propagate, then continues. Mail is never dropped.

Q: How long can I run with the swap in place? Indefinitely — there's no time limit. But your data path goes through a non-home region, so revert as soon as we confirm recovery to keep things clean.

Q: Will it look different to recipients? The egress IP changes (e.g., from a US-region IP to an EU-region IP). DKIM and DMARC continue to validate because:

• DKIM is signed by your domain's keys, not the gateway's
• SPF includes all four region IPs via spf.adtosign.com
• DMARC alignment is unaffected

Q: Can I pre-stage two routing rules and just toggle priority? Some admins do this. We don't recommend it because:

• Some platforms (Google, Zoho) only allow a single outbound gateway, not priority lists
• During an outage you don't want to touch the rules of multiple things at once

Q: What about latency? Your mail typically adds ~80-150 ms transit time when going to a non-home region. Customer recipients won't notice; the queue/delivery time on their side is dominated by their own platform.

Need help?

• AdtoSign super-admin support: see your contract for the on-call email / Slack channel
• Status page: https://status.adtosign.com (if configured)
• Self-check: load /app/deployment/mail-flow in your AdtoSign dashboard — the gateway host is shown under "Gateway" → look for "Status: active"

Related docs

• mail-flow-processor-setup.md — initial Signature Stamping setup
• ../support/mail-flow-troubleshooting.md — broader troubleshooting