Email signatures for every client tenant, from one login.

Paste one key, once. After the add-in, extension or app is in place, the user pastes their unique signature key into it and their signature installs. That's the whole user-facing process. Every change you make afterwards — a rebrand, a new banner, a corrected phone number — flows through without them doing anything again. We're building direct API deployment to remove even that first paste.

No, and this is usually the part that decides the deal. The Windows app installs signatures into Outlook 2013, 2016 and 2019, plus Thunderbird, Postbox and Mailbird. The macOS app does the same for Outlook for Mac, Outlook 2019 for Mac, Thunderbird, Postbox and Mailbird. So the machines you can't modernise stop being a manual job every time a client rebrands.

Every signature is also produced as a rendered, formatted HTML file and as raw HTML source. If the client, app, CRM or sending tool has a signature box that takes HTML, it's supported — no integration needed, and you can read the source before you paste it. In practice that covers the long tail of one-department-at-one-client tools that nothing else handles.

Today, yes, using the HTML source or rendered file wherever the tool stores a per-user signature. Direct browser-extension support is in progress — Salesforce and Follow Up Boss first, plus a custom app integration tool for other sending platforms. We're not putting a date on it here; ask on the call for the current state.

Users can sideload the same add-in themselves. Same capability, same result, you just lose the ability to push it in one action. In practice this is how a lot of pilots start: get five users running on sideload, show the client the before-and-after, then ask for the tenant-wide deployment with evidence in hand.

Yes, for the Outlook app on both iOS and Android, with no separate install. The signature is stored in the mailbox, so it syncs to the app the same way it syncs between the user's desktop and web. This is the part most vendors can't do, and it's worth demonstrating on a client's own phone during the walkthrough.

Gmail's phone app gets a lightweight version through the extension. Other iOS mail apps — Apple Mail, Spark, Yahoo, Canary, Polymail, Front — use the iOS Shortcut. The only genuine gap is Android mail apps other than Outlook and Gmail, which don't accept HTML signatures at all.

Because Gmail caps a stored signature at 10,000 characters, and a full HTML signature with inline styling goes past that regularly. It's one of the most common support questions in the whole category. So the extension installs a trimmed mobile version into Gmail's settings for the phone, and swaps the full signature back in whenever the user composes on the web. The user sees the right one in each place without thinking about it.

Instead of storing signatures as files in %AppData%\Microsoft\Signatures on each machine, Outlook stores them in the Exchange Online mailbox so they follow the user between devices. It applies to Microsoft 365 and Outlook.com accounts on Outlook build 2303 and later on Windows. Exchange on-premises, POP and IMAP accounts can't use it.

It's the other way round, and this is the single most common misunderstanding we hear. Roaming signatures are staying. What's temporary is your ability to turn them off: Microsoft's documentation for Set-OrganizationConfig -PostponeRoamingSignaturesUntilLater describes it as a way for admins to temporarily disable the feature without opening a support ticket. Treat any tenant currently relying on that switch as living on borrowed time.

No, they're what makes the mobile sync work. Microsoft's warning is aimed at signature tools that write files into the local %AppData%\Microsoft\Signatures folder; those stop working once the feature is on. Our add-in installs the signature through Outlook itself, so it lands where roaming signatures already keep it and then follows the user to every device signed into that mailbox. A tenant that turns roaming signatures on mid-rollout doesn't create a ticket for you.

Two things, and both catch people out:

• The signature parameters on Set-MailboxMessageConfiguration, including SignatureHtml and AutoAddSignature, stop working. Microsoft's cmdlet reference states this directly. Worth remembering that cmdlet only ever applied to Outlook on the web anyway, which surprises a lot of people who've been running it as their standard script.
• Microsoft warns that third-party signature add-ins that write to the local signature folder will no longer work when the feature is enabled.

There are two levers and both have caveats. At tenant level, Set-OrganizationConfig -PostponeRoamingSignaturesUntilLater $true, documented as temporary. At client level, the DisableRoamingSignatures registry value under Outlook's Setup key. Note that one is under HKEY_CURRENT_USER, so it's per-user per-machine, its own deployment problem across a fleet, and the reason a lot of MSPs give up on it halfway through. Our honest advice: don't fight it. Deploy something that works with the feature on.

Microsoft begins disabling EWS in Exchange Online in October 2026 and completes it in April 2027. It affects signatures if any of your tooling reads or writes mailbox data over EWS, which covers a lot of in-house scripts and some older third-party tools. Microsoft publishes EWS usage reports and a code analyzer; run them across your tenants before Q4 rather than after.

No. The Graph mailbox settings endpoint covers automatic replies, date and time format, locale, working hours, delegate meeting rules and user purpose. Signatures aren't among them, and there's a long-standing open developer request for it. So the honest position is that EWS is going away, Graph never arrived, and the remaining routes are transport rules, add-ins or client-side deployment. We use the add-in route, which is unaffected by the EWS retirement.

No. The signature is installed into the user's mail client and the message is composed with it already in place. We don't sit in the mail flow, we don't act as a relay, and we don't modify messages in transit, so there's no connector to add, nothing to re-order in front of a security gateway, and no dependency on our uptime for a client's mail to send.

No. DKIM breakage happens when something alters the message body after it has been signed. Because the signature is already part of the message when the user hits send, Microsoft 365 or Google signs the finished message exactly as it normally would. Same reasoning for Safe Links and third-party gateways: there's no additional hop to order correctly.

Yes. One workspace per client, with its own brand profile, users and templates. Workspaces are unlimited on every plan, so a client with three sub-brands costs you nothing extra in structure. You can give a client's marketing lead access to their workspace alone, with fonts, colours and layout locked so nothing drifts off-brand.

Partners buy at wholesale, 30% off recommended retail, across every client workspace on the account, and bill their clients however they prefer. Talk to us about your tenant count and we'll confirm the terms in writing before you commit anything.

For a plain text disclaimer at the bottom of a thread, yes, and it's free. Microsoft's own documentation lists what you give up: no inline images, the signature can't sit directly under the latest reply, users can't see it in Sent Items, and lines containing directory variables that don't resolve get skipped entirely, so a user with an empty mobile field gets a gap. It also only reaches Exchange — the Gmail, Thunderbird and CRM users in the same client are still yours to sort out by hand.