There's an Open-Source Outlook Signature Add-in on GitHub — Here's What It Can (and Can't) Do
Drafted with AI assistance and reviewed before publishing. How we write and source articles →
TL;DR: Signature-POC is a small, open-source Office.js add-in that automatically injects a centrally managed HTML signature into Outlook the moment someone opens a new compose window — no task pane, no button, no user action. It’s a genuinely interesting proof of concept: the signature itself lives on Cloudflare Pages, so it can be updated without touching or re-sideloading the add-in, and no email is ever routed through a third party to apply it. It’s also a useful, honest illustration of where “signature management” stops being a solved problem: it pushes one identical signature to everyone. The moment you need a signature that knows the recipient’s name, title, department, or office, this pattern runs out of road.
What it actually does
Most DIY signature attempts are a block of HTML someone pastes into Outlook’s signature settings once, which quietly falls out of date the next time the logo changes or someone gets promoted. Signature-POC works differently, because it uses a real piece of the Office.js platform rather than working around it: event-based activation.
The flow is simple. Outlook fires the OnNewMessageCompose event the moment a user starts a new message, reply, or forward. A small event handler (commands.js) — hosted on Cloudflare Pages rather than bundled into the add-in — fetches a flat HTML file and calls setSignatureAsync() to inject it into the compose window. There’s no UI for the user to interact with and nothing to remember to do. Because the signature content is fetched at compose time from a URL rather than baked into the add-in package, updating it is a git push, not a re-deployment.
Architecturally, that puts it in the same camp SigHQ’s own server-side vs. add-in comparison describes: the signature is written directly into the compose window by the client, and no outbound mail is ever intercepted or relayed through a third party to apply it. That’s a meaningful architectural property, not an incidental one — it’s the same reason SigHQ’s review of Set-OutlookSignatures, the other open-source project in this space, treats “no cloud relay” as worth calling out explicitly rather than assuming every signature tool works this way.
The compatibility picture is more specific than it looks
It’s tempting to assume an Office.js add-in like this “just works everywhere Outlook does.” It doesn’t, and the gaps are specific enough to be worth knowing before building on the same pattern. Per Microsoft’s own supported-clients table for event-based activation:
- New Outlook for Mac supports it. Legacy/classic Outlook for Mac does not, at all — the cutoff is a UI generation, not a calendar year.
- Windows is supported on both the new Outlook for Windows and classic Outlook for Windows — the latter needs Windows 10 version 1903 or later.
- Outlook on the web supports it too.
There’s a second, sharper gap underneath that: classic Outlook for Windows builds older than Version 2403 run event handlers in a JavaScript runtime limited to ES2016 — no async/await. Code written the “modern” way will silently time out on those builds rather than fail loudly. It’s exactly the kind of platform-fragmentation problem covered in what IT admins need to check before migrating to new Outlook — Microsoft’s add-in platform has genuinely different capability tiers hiding behind what looks like one product name, and this project’s own commit history shows a fix for the ES2016 issue that was written and then reverted, which is as good a demonstration as any of how easy this is to get wrong.
Signature management is bigger than signature injection
This is the part worth being direct about. Getting a signature to appear automatically is the easy 20% of the problem. Signature-POC solves exactly that 20% — one global signature, identical for every sender, with no directory lookup involved at all.
Real “signature management,” as opposed to signature injection, is mostly about what happens before the HTML gets written into the compose window: pulling each employee’s name, job title, department, phone number, and office location from a directory and merging it into a template per person; giving sales or HR a different variant to the rest of the company, the way role-based signatures work in practice; keeping one person’s signature from silently drifting from the template the day they change their own settings; and giving whoever owns the rollout a way to update all of it without touching code. The three types of email signature software breaks down what a market built around that harder 80% actually looks like — and none of the three categories described there is “one static file pushed to every mailbox,” because that’s not what most organisations with more than a handful of people actually need.
None of that is a criticism of the project — a proof of concept is allowed to be exactly what it says it is. It’s a useful marker, though, for exactly where the line sits between “a clever weekend build” and “an actual signature management system.”
Who this genuinely suits
Signature-POC is a good fit for a small, technically capable team: a handful of people, one shared brand signature, someone comfortable sideloading a manifest and reading Office.js docs, and a strong preference for zero recurring cost over convenience. If that’s the whole requirement — one signature, applied automatically, updatable with a git push — this is a perfectly reasonable way to solve it, and the code is sitting there to fork.
It stops being the right tool the moment any of these show up: more than one signature variant across the business, personalisation per employee, a non-technical person who needs to own updates, org-wide deployment without hand-sideloading each machine, or a need for someone to be accountable when it breaks. At that point the honest options are either the internal engineering investment the buying checklist asks you to weigh seriously, or a platform built to handle the harder 80% by default.
Frequently asked questions
Does this add-in route email through a third-party server?
No. It injects the signature directly into the compose window via Office.js’s setSignatureAsync() API — the same client-side pattern add-in-first tools use generally. Outbound mail is never intercepted or relayed through the project’s own infrastructure, or anyone else’s, to apply the signature.
Does it work on Outlook for Mac?
Only the new Outlook for Mac. Legacy/classic Outlook for Mac doesn’t support the event-based activation feature this add-in depends on at all, regardless of version.
Does it work on Windows?
Yes — both the new Outlook for Windows and classic Outlook for Windows support it, though classic Outlook for Windows needs Windows 10 version 1903 or later, and older classic builds (pre-Version 2403) can’t run the add-in’s async/await code without timing out.
Can it give different employees different signatures?
Not as published — it pushes one identical HTML signature to every mailbox, with no directory lookup or per-employee personalisation. Adding that would mean building a templating and data layer on top of it, which is most of what a dedicated signature management platform actually does.
SigHQ is building an add-in-first email signature management tool for Microsoft 365 organisations of 50–250 employees — signatures applied in Outlook at compose time, without email routing through third-party infrastructure. Join the waitlist to follow progress.