Group Policy (GPO) is the classic tool Active Directory administrators use to enforce configuration across a Windows fleet. Many rely on it to deploy an Outlook signature: a script copies signature files into the user's profile and writes a few registry values. The method works — within a narrow perimeter. This guide walks through the steps, the mechanics of the Outlook registry, then the limits that push most organizations toward a cloud approach.
%APPDATA%\Microsoft\Signatures and writing the NewSignature and ReplySignature registry values. The method targets only domain-joined Windows PCs running classic Outlook: it ignores Outlook on the web, Mac, mobile and the new Outlook, and handles static signatures only.
Outlook signature via GPO: what does it mean?
Outlook for Windows (the classic desktop version) stores each signature as three files — .htm, .rtf and .txt — in the user's %APPDATA%\Microsoft\Signatures folder. The default signature choice itself is written to the Windows registry, in a per-account hive (HKEY_CURRENT_USER).
Deploying a signature via GPO therefore means automating two actions: dropping the right files into each user's profile, then pointing the registry at the signature to use. This is done with a logon script attached to a Group Policy Object, or with a Group Policy Preference (GPP) for the registry part. It is a "domain-joined Windows PC" approach, inherited from a pre-cloud world.
Where Outlook stores the signature (registry and files)
Two locations work together:
- The signature files:
%APPDATA%\Microsoft\Signaturesholds a trio of files per signature, named after the display name shown in Outlook (for exampleCompany.htm). - The registry: under
HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\MailSettings, theNewSignaturevalue names the signature for new messages andReplySignaturethe one for replies and forwards. You write the file name without its extension.
16.0 maps to recent Outlook versions (Microsoft 365, 2016, 2019, 2021). Writing these values without the matching files present in the profile leaves Outlook with no signature to load — the two steps are inseparable.
How to deploy a signature via GPO, step by step
The procedure combines a network share, a script and a GPO linked to an organizational unit:
- Create the reference signature in Outlook, then collect the generated files (
.htm,.rtf,.txt) from%APPDATA%\Microsoft\Signatures. - Place those files on a network share readable by the targeted users.
- Write a logon script (batch or PowerShell) that copies the files from the share into the local profile's
Signaturesfolder. - Have that same script write the
NewSignatureandReplySignaturevalues underHKCU\...\Common\MailSettings. - Create a Group Policy Object and attach the logon script, or use a registry preference (GPP) for the keys.
- Link the GPO to the target organizational unit, force a refresh (
gpupdate /force) and test on a domain-joined Windows PC.
Some organizations then lock down user editing of the signature, but that lockdown is neither complete nor portable across Outlook versions.
What are the limits of the GPO method?
GPO remains a Windows-fleet instrument. Applied to signatures, it hits several walls:
- Windows and domain only. You need a device joined to Active Directory. Pure Entra-joined, non-domain or personal devices fall outside GPO.
- No web, Mac or mobile coverage. Outlook on the web, Outlook for Mac and the mobile apps do not use the Windows registry: they will never show the GPO-pushed signature.
- The new Outlook. The new Outlook for Windows is built on the web engine (OWA) and does not read these registry keys — the method stops working there.
- Static signature. The deployed file is identical for everyone. Personalizing the name, title or phone per employee requires a script that queries Active Directory and generates one file per user.
- Heavy maintenance. Every logo change, legal notice or campaign forces you to regenerate the files, update the share and wait for each user's next logon.
- Control left to the user. Once the files are in the profile, nothing stops the employee from editing or deleting the signature between logons.
GPO inserts nothing at send time: it prepares a signature the user can always remove. It therefore does not guarantee that a legal notice or a confidentiality notice actually appears on every outgoing email.
GPO or a cloud solution: comparison
A modern solution like ATOM Signatures applies the signature through a client-side Outlook add-in, independent of the domain and the registry. The contrast is stark:
| Criterion | GPO (registry) | Cloud solution (add-in) |
|---|---|---|
| Devices covered | Domain-joined Windows only | Any device connected to Microsoft 365 |
| Outlook web / Mac / mobile | Not covered | Covered |
| New Outlook | Not supported | Supported |
| Dynamic fields (title, phone) | AD script to maintain | Pulled in real time via Microsoft Graph |
| Targeting | By AD organizational unit | By Microsoft 365 group |
| Updates | Regenerate files + next logon | Instant, centralized |
| User editing | Possible (drift) | Controlled by the administrator |
To deploy a uniform signature across an entire organization, on any device, the cloud approach lifts GPO's constraints at once. See the guide on deploying a signature for the whole organization.
When GPO is enough, when to move to the cloud
GPO can suit an all-Windows organization where everyone runs classic desktop Outlook, joined to an Active Directory domain, with a simple, rarely changed signature and an IT team comfortable with scripting. Within that narrow frame, it avoids a subscription.
You should move to a cloud solution as soon as any of these appear: Macs or mobiles, Outlook on the web, the new Outlook, off-domain or remote devices, fields that vary from one employee to another, frequent updates, or the requirement that a legal notice appear on every send. That is the reality of most Microsoft 365 fleets today. For the wider context, see the Microsoft 365 email signature guide.
Frequently asked questions
Can you deploy an Outlook signature with GPO alone?
Yes, but only on domain-joined Windows PCs running classic (desktop) Outlook. GPO copies signature files and writes registry values under HKCU. It covers neither Outlook on the web, Mac, mobile, nor the new Outlook, where the Windows registry is absent or not read.
Which Outlook registry key controls the signature?
Under HKEY_CURRENT_USER\Software\Microsoft\Office\16.0\Common\MailSettings, the NewSignature and ReplySignature values name the signature file (without extension) to use for new messages and replies. The files themselves live in %APPDATA%\Microsoft\Signatures.
Can GPO insert dynamic fields like title or phone?
Not natively. GPO deploys a static file. To personalize per employee, you need a script that reads Active Directory and generates one file per user, which greatly increases maintenance. A cloud solution pulls those fields in real time through Microsoft Graph.
Can a user edit or delete the GPO-pushed signature?
Yes. Once the files are copied into their profile, the user keeps control in Outlook and can edit or delete the signature. The script re-applies at the next logon, but nothing prevents drift between two sessions.
One signature across every Outlook, no GPO or script. ATOM Signatures applies your organization's signature client-side — Windows, Mac, web and mobile — with fields kept current through Microsoft Graph and 100% Canadian hosting.
Go further: deploy a signature for the whole organization and the complete Microsoft 365 email signature guide.
Sources
- Microsoft Learn — configuring Outlook signatures and file locations: learn.microsoft.com
- Microsoft documentation on Group Policy and logon scripts.