Email signatures management software for MSPs, every client tenant, from one login.

On a Windows PC you deploy with your RMM: nothing. Their signature is in Outlook, Thunderbird, Postbox, Mailbird or eM Client the next time they log on, and every change you make afterwards flows through without them doing anything.

On the Outlook add-in, browser extension, macOS app or iOS Shortcut: paste one key, once. That's the whole user-facing process, and we're building direct API deployment to remove even that first paste on the add-in.

You give the installer a seed list: one line per mailbox with that user's signature key and email address, either in a file beside the installer or straight on the command line. Your RMM or Intune runs the installer silently as SYSTEM. The list is stored on the PC, and when a user next logs on the SigStudio tray app finds the seed that matches their mail account and installs the signature straight into their mail client. From then on it checks SigStudio every two hours and keeps the signature current.

Already have the app installed? Your RMM can write the same seed list to one registry value and skip the installer entirely.

No. The client's workspace admin exports the keys, you build the seed list, and it lives in your RMM. Nobody is emailed a code, which matters because mailing a thousand people a secret string is exactly the kind of work that generates the tickets you're trying to remove. A key only grants read access to that one rendered signature, but treat the list as internal all the same.

No, and this is usually the part that decides the deal. The Windows app installs signatures into Outlook 2013, 2016, 2019 and classic Outlook for Microsoft 365, plus Thunderbird, Postbox, Mailbird and eM Client, and your RMM can push it silently with every user's signature already attached. The macOS app covers 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.

No. New Outlook (the Store app, sometimes called Monarch) keeps no local signature files, so there's nothing on the PC for a desktop app to write into. Those users get the Outlook add-in, which also covers Outlook on the web and mobile. A mixed tenant simply runs both routes: RMM push for the classic desktops, add-in for everyone else.

It stays deleted until you say otherwise. Seeds only ever add, so a user's removal holds between pushes. When you want it back, run the install command with the seed list again: every run with seeds counts as a new push, and the app re-applies each seed at the user's next logon or check. You decide, not the app.

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, meaning Apple Mail, Spark, Yahoo, Canary, Polymail and 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.

The Windows app is for the classic and legacy clients that keep local signature files, which is exactly where roaming signatures don't apply. The two routes don't overlap.

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, in phases, and completes it in April 2027. It is permanent. 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. Nothing SigStudio deploys uses EWS.

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 and the desktop apps, neither of which is affected 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.