> For the complete documentation index, see [llms.txt](https://docs.adtosign.com/llms.txt). > Use it to discover all available pages before exploring further. # Signature Stamping — Transport Rules Reference For Exchange Online Administrators · Read time: 10-15 min · Last updated: May 25, 2026 — priority-zero placement is now the default. > **For Exchange Online Administrators** · Read time: 10-15 min · Last updated: May 25, 2026 — priority-zero placement is now the default. This document explains what AdtoSign creates in your Exchange Online tenant, why each piece exists, what is safe to modify, and how to interpret the drift alerts that arrive when something changes unexpectedly. If you're looking for **how to install** Signature Stamping, see [Signature Stamping Setup Guide](./mail-flow-processor-setup.md). This document is for after setup is complete. --- ## TL;DR — Don't break these things | AdtoSign object | What it does | Safe to modify? | |---|---|---| | **Outbound Connector** `AdtoSign Mail Flow Outbound` | Routes mail to gateway | ❌ No — managed by AdtoSign | | **Inbound Connector** `AdtoSign Mail Flow Inbound` | Accepts processed mail back | ❌ No — managed by AdtoSign | | **Transport Rule** `AdtoSign Route Through Mobile Mail Processor` | Routes outbound mail through gateway | ❌ No — managed by AdtoSign | | **Transport Rules** `AdtoSign-{name}` / `AdtoSign - {DG name}` | Tier 2 fallback HTML signatures | ❌ No — managed by AdtoSign | | **Distribution Group** `AdtoSign-Enabled-Users` (if used) | Defines which users get processed | ⚠️ Membership changes OK, don't delete | | **Your DLP / encryption / archive rules** | Customer-side compliance | ✅ Yes — fully under your control | | **Mimecast / Proofpoint / IronPort routing rules** | Customer-side security gateway | ✅ Yes — fully under your control | If you delete or disable any of the AdtoSign-managed objects, drift detection will alert you within 4 hours and offer one-click repair. --- ## What AdtoSign creates in Exchange Online After Signature Stamping setup runs, your tenant has these new objects: ### 1. `AdtoSign Mail Flow Outbound` (Outbound Connector) Routes mail to the AdtoSign signature gateway nearest to your tenant region. ``` Smart hosts: sgw-{region}.adtosign.com (FQDN) (failover) TLS: Required (TLS 1.2+, certificate validated) Connector type: PartnerOrganization (preserves DKIM) ``` **Why this matters**: When the routing rule fires, mail leaves your tenant via this connector. The IP is published in `spf.adtosign.com` so failover paths still pass SPF. ### 2. `AdtoSign Mail Flow Inbound` (Inbound Connector) Accepts processed mail back from the gateway. ``` SenderIPAddresses: All known relay egress IPs (US, India, EU, APAC) Connector type: PartnerOrganization CloudServicesMailEnabled: $true (re-evaluates transport rules on return) ``` **Why this matters**: When the gateway sends processed mail back, this connector treats it as authenticated outbound (not inbound) so transport rules fire again — letting your customer-side security gateway scan the now-signed mail. ### 3. `AdtoSign Route Through Mobile Mail Processor` (Transport Rule) The **Signature Stamping route rule**. Sits at **priority 0 (top of your priority list)** so AdtoSign intercepts outbound mail FIRST. Customer rules (DLP, encryption, gateway) act on the **signed return-pass** mail. ``` Priority: 0 (top, fires first) Conditions: FromScope = "InOrganization" ExceptIf X-AdtoSign-Processed = true (loop prevention) Actions: RouteMessageOutboundConnector = AdtoSign Mail Flow Outbound SetHeader X-AdtoSign-Signed = true (suppresses Direct HTML fallbacks during healthy state) ``` **Why this matters**: - **Guaranteed signature injection.** At priority 0, AdtoSign intercepts the routing decision before any customer rule can re-route the mail to a different connector. Without this, a Mimecast/Proofpoint routing rule at priority 0-5 would silently bypass AdtoSign. - **Customer rules still get full access via two-pass evaluation.** When the gateway sends the signed mail back, the Inbound Connector's `CloudServicesMailEnabled=true` setting tells Exchange to re-evaluate ALL transport rules on the second pass. Your DLP / encryption / gateway / archive rules act on the FINAL (signed) message, not the unsigned original. - **Loop prevention.** On the second pass, `X-AdtoSign-Processed=true` (stamped by the gateway) makes this rule skip itself — mail flows out via your normal routing. - **Cross-rule dedup.** `SetHeader X-AdtoSign-Signed=true` makes the `AdtoSign-{name}` Direct HTML rules (priority 1+) skip during healthy operation. They only fire as Tier-2 fallback when Signature Stamping is auto-disabled (all gateway regions down). ### 4. `AdtoSign-{name}` and `AdtoSign - {DG name}` (Transport Rules — Direct HTML) One per signature deployment. These are **fallback rules** — they apply HTML signatures via `ApplyHtmlDisclaimerText` when the gateway is unavailable (Tier 2 failover). ``` Conditions: From = OR FromMemberOf = OR (no filter — catch-all for "All Users" deployments) ExceptIf X-AdtoSign-Signed = true (skip if relay or other rule already signed) Actions: ApplyHtmlDisclaimerText = ApplyHtmlDisclaimerLocation = Append ApplyHtmlDisclaimerFallbackAction = Wrap SetHeader X-AdtoSign-Signed = true (cross-rule dedup: prevents stacking) ``` **Why this matters**: - During healthy Signature Stamping operation: these rules SKIP (header set by Signature Stamping rule). - During Tier 2 (gateway outage): these rules FIRE and inject text-based HTML signatures so your senders still get branded mail. - The cross-rule dedup ensures users in multiple deployments (e.g., Sales DG + Default catch-all) get exactly ONE signature, not stacked. ### 5. `AdtoSign-Enabled-Users` (Distribution Group, if you scoped to specific users) If you chose to scope Signature Stamping to specific users, this DG holds the membership. **Why this matters**: Membership comes from your directory connection sync. Adding users via the AdtoSign UI is the recommended way; manual additions in Exchange admin center will be reconciled on the next sync. --- ## How AdtoSign coexists with your security gateway AdtoSign uses a **two-pass evaluation pattern**. The gateway round-trip triggers Exchange to re-evaluate all transport rules on the return, so your security gateway and DLP rules act on the **signed** mail, not the unsigned original. ### Healthy state (most of the time) **First pass (outbound from user):** ``` Your user sends mail ↓ Exchange evaluates transport rules in priority order: Priority 0 ✓ AdtoSign Route Through Mobile Mail Processor → fires - SETS X-AdtoSign-Signed = true - Routes via AdtoSign Mail Flow Outbound connector Priority 1+ ✗ AdtoSign-Sales fallback → SKIP (X-AdtoSign-Signed is set) Priority 1+ ✗ AdtoSign-Default fallback → SKIP (X-AdtoSign-Signed is set) Priority N+ (other rules still evaluate, but routing is already locked) ↓ Mail leaves the tenant via the AdtoSign Outbound Connector → sgw-{region}.adtosign.com ``` **Gateway processing (~100-400ms):** - The gateway strips mobile-client signatures, injects the AdtoSign signature (with CID-embedded images for inline rendering), stamps `X-AdtoSign-Processed = true`, and sends the mail BACK to your tenant via the AdtoSign Inbound Connector. **Second pass (signed mail returns via Inbound Connector):** ``` Inbound Connector receives signed mail (CloudServicesMailEnabled = true) ↓ Exchange re-evaluates ALL transport rules: Priority 0 ✗ AdtoSign Route Through Mobile Mail Processor → SKIP (X-AdtoSign-Processed is now set) Priority 1+ ✗ AdtoSign-* Direct HTML → SKIP (X-AdtoSign-Signed is set) Priority N+ ✓ Customer DLP rule → fires (scans the FINAL signed body) Priority N+ ✓ Customer encryption rule → fires Priority N+ ✓ Mimecast routing rule → fires → mail flows out via Mimecast ↓ Mail delivers to recipient (DKIM re-signed by Exchange on egress) ``` **Net effect:** - AdtoSign sees the original message and adds branded signature with full image fidelity. - Customer security gateway sees the FINAL signed message and applies DLP / archive / encryption to the version that will actually reach the recipient. - No race condition between AdtoSign and customer routing rules — they fire in separate passes. ### What happens if my customer rule has `StopRuleProcessing = true` above AdtoSign? That scenario can't happen anymore because AdtoSign is at priority 0 — there is no rule "above" it. If you place a rule at priority 0 (effectively above ours), the drift cron raises `FOREIGN_STOP_RULE_ABOVE_MFP` within 4 hours and offers repair (which restores AdtoSign to priority 0). ### What if a customer rule blocks mail (DLP reject) on the second pass? Mail gets blocked normally. AdtoSign already processed and re-sent it, but the second-pass DLP reject prevents external delivery. From the recipient's perspective, the mail is blocked — same as if AdtoSign wasn't in the path. ### Customer rule at "high priority" (low number) is moot for routing Before today's update, customer rules at priorities 0-5 could intercept routing before AdtoSign saw the mail. With priority-zero placement, AdtoSign always sees the mail first. Customer rule priority numbers still matter relative to each other on the second pass, but they don't affect whether AdtoSign processes the mail. ### Tier 1 cross-region failover (transparent) If AdtoSign's gateway region (e.g., Mumbai) becomes degraded: - AdtoSign automatically re-points your Outbound Connector smart host to a backup region (e.g., Singapore). - Latency increases by 50-200ms; everything else continues normally. - No action needed from you. ### Tier 2 failover (gateway all-down) If ALL AdtoSign gateway regions are degraded simultaneously (very rare): - the signature gateway route rule is automatically disabled. - `AdtoSign-{name}` Direct HTML rules now fire as fallback. - Mail continues to flow through your security gateway normally. - Image rendering quality is reduced (text-based HTML instead of CID-embedded). - AdtoSign's drift cron will mark this as "in failover" — NOT as an alert (it's intentional). ### When Signature Stamping is restored - AdtoSign re-enables the signature gateway route rule and re-points to the original region. - Direct HTML rules go back to skipping (header gating). - No action needed from you. --- ## Drift detection and alerts AdtoSign runs an audit every 4 hours that checks your tenant's transport rule + connector state. If something has changed unexpectedly, you'll see: 1. A **drift banner** on the [Deployment page](https://app.adtosign.com/app/deployment) with severity color coding 2. An **email alert** to org owners + admins for severity ≥ "high" (max 1 per 24h to avoid spam) ### Drift severity codes | Code | Severity | What happened | What to do | |---|---|---|---| | `MFP_RULE_MISSING` | 🔴 Critical | Someone deleted the AdtoSign Route Through Mobile Mail Processor rule | Click "Repair now" — re-creates it | | `MFP_RULE_DISABLED` | 🔴 Critical | Someone disabled the signature gateway rule | Click "Repair" OR investigate why someone disabled it | | `MFP_MISSING_SETHEADER` | 🟡 Medium | Old rule lacks the new SetHeader action | Re-deploy any signature → AdtoSign auto-patches | | `FOREIGN_STOP_RULE_ABOVE_MFP` | 🔴 Critical | A non-AdtoSign rule above Signature Stamping has `StopRuleProcessing=true` | Review the rule — it's blocking AdtoSign processing | | `DIRECT_HTML_RULE_MISSING_EXCEPTIF` | 🟡 Medium | Direct HTML rule lacks `ExceptIf X-AdtoSign-Signed` (legacy / test-rule / pre-Sprint-1 deploy) | Call action=repair-direct-html (idempotent, fixes all affected rules at once) OR re-deploy that signature | | `OUTBOUND_CONNECTOR_MISSING` | 🔴 Critical | Connector deleted | Click "Repair now" — re-creates it | | `OUTBOUND_CONNECTOR_DISABLED` | 🔴 Critical | Connector disabled | Click "Repair" | | `INBOUND_CONNECTOR_MISSING` | 🔴 Critical | Connector deleted | Click "Repair now" | | `INBOUND_CONNECTOR_DISABLED` | 🔴 Critical | Connector disabled | Click "Repair" | | `INBOUND_IPS_CLEARED` | 🔴 Critical | Sender IP whitelist cleared | Click "Repair" — re-populates from registry | ### What "Repair" does The repair button re-runs the original setup process **idempotently**. Specifically: ✅ **Touches**: - AdtoSign's Outbound Connector (`Set-OutboundConnector` to restore smart hosts) - AdtoSign's Inbound Connector (`Set-InboundConnector` to restore IP whitelist) - AdtoSign's Route Through Signature Stamping rule (`Set-TransportRule` with all expected actions) - AdtoSign's `AdtoSign-{name}` legacy rules (inventories them, does NOT modify) ❌ **Does NOT touch**: - Your DLP / encryption / archive rules - Your Mimecast / Proofpoint / IronPort routing rules - Any non-AdtoSign-named transport rule - Any non-AdtoSign distribution group - Mailbox settings, group memberships, or compliance policies ### What "in failover" status means If the drift banner shows "in failover" instead of "drift detected", it means: - AdtoSign has intentionally disabled the signature gateway route rule because all gateway regions are degraded. - Direct HTML rules are providing fallback signatures. - This is **NOT** a problem — it's automatic graceful degradation. - Recovery is also automatic; no action needed. --- ## Common scenarios + admin actions ### "I want to add a new transport rule for compliance / DLP" ✅ Go ahead. Place it wherever makes sense for your priority order. AdtoSign won't be affected as long as your rule doesn't: 1. Sit above Signature Stamping rule with `StopRuleProcessing=true` (would block AdtoSign). 2. Set `X-AdtoSign-Signed` or `X-AdtoSign-Processed` headers manually (would interfere with AdtoSign's signaling protocol). ### "I want to remove a sender from Signature Stamping processing" Use the AdtoSign UI to remove them from the deployment scope (Sales DG, etc.). Avoid hand-editing the transport rule's `From` / `FromMemberOf` — your changes will be overwritten on the next signature redeploy. ### "I want to test a change before applying broadly" Re-running setup with `testUserEmails: [...]` in dev mode scopes the signature gateway rule to specific senders. Ask AdtoSign support for the dev mode endpoint if you need this for a pilot. ### "Mimecast is rejecting mail returning from AdtoSign gateway" The gateway return IPs need to be allowed in Mimecast's "Permitted Senders" or equivalent allowlist. The IP list is published in `spf.adtosign.com` SPF record — paste those IPs into Mimecast. ### "I disabled Signature Stamping for testing — how do I re-enable?" In Exchange admin center → Mail flow → Rules → enable "AdtoSign Route Through Mobile Mail Processor". Or click "Repair" in the AdtoSign deployment page. Either works. ### "I need to perform DR drill — block all AdtoSign rules temporarily" In Exchange admin center, disable the AdtoSign route rule + all `AdtoSign-{name}` rules. Mail will flow through your normal pipeline with no AdtoSign processing. To restore: re-enable each rule, OR click "Repair" in the AdtoSign UI to bulk-restore. ### "Drift banner shows critical and I'm getting emails — what's the fastest fix?" 99% of the time: click **"Repair now"** in the deployment page banner OR the email. ~30-60 seconds, zero customer-side impact. The 1% case is `FOREIGN_STOP_RULE_ABOVE_MFP` — that requires you to review the foreign rule manually because we can't auto-modify customer-side rules. --- ## Reference — header signaling protocol | Header | Set by | Purpose | |---|---|---| | `X-AdtoSign-Processed: true` | AdtoSign gateway | Loop prevention — gateway marks mail as processed before returning | | `X-AdtoSign-Signed: true` | Signature Stamping rule + gateway + Direct HTML rules | Skip-if-already-handled signal across Signature Stamping rule and fallback rules | | `X-AdtoSign-Relay: {region}` | AdtoSign gateway | Audit trail — which region processed the mail | | `X-AdtoSign-Processing-Time: {ms}` | AdtoSign gateway | Performance metric in mail headers | | `X-AdtoSign-Embedded: true` | Outlook add-in | Indicates the add-in already embedded the signature client-side (gateway skips) | These headers survive Mimecast and other gateways by default. They're informational — you can inspect them in delivered mail headers to verify the flow. --- ## Need help? - **Self-service**: Click "Run health check" on the deployment page anytime — gives you the full state in 10-15 seconds. - **Email**: support@adtosign.com — include the drift code and timestamp. --- ## Glossary - **Signature Stamping**: Signature Stamping — AdtoSign's signature gateway-based signature processing. - **Direct HTML rule**: A transport rule that injects HTML via `ApplyHtmlDisclaimerText`. Used as fallback when Signature Stamping is unavailable. - **Tier 1 failover**: Cross-region gateway swap (transparent to customer). - **Tier 2 failover**: Gateway disabled, Direct HTML rules take over. - **Drift**: Unexpected change to AdtoSign-managed Exchange objects. - **CID image**: A MIME-attached image referenced in the email body via ``. Renders inline without "load images" prompt. - **Round-trip**: Mail leaves your tenant → AdtoSign gateway → returns to your tenant via Inbound Connector. Triggers a second pass through your transport rules.