Knowledge Base

How to prevent Outlook for Windows from adding native signatures


You are managing email signatures centrally in your organization by using a dedicated signature software (such as CodeTwo Email Signatures 365 or CodeTwo Exchange Rules Pro). You would like to disable native/personal signatures added in Outlook for Windows to avoid the problem of duplicated signatures in your users’ emails.


To turn off Outlook for Windows native signatures centrally, you can use one of the modern Web Add-in’s advanced options (CodeTwo Email Signatures 365 only), a Group Policy Object (GPO) or Microsoft Intune. Click the links below to learn more.

The solutions outlined below work only for the classic Outlook for Windows. If you look for a solution to centrally disable native email signatures in different Outlook versions (e.g. the new Outlook for Windows, Outlook for Mac), see this section.

Using Web Add-in to disable native Outlook signatures

If you use our cloud email signature manager with the modern CodeTwo Signatures Web Add-in for Outlook (Web Add-in), you can centrally disable native Outlook signatures for all your users for whom the add-in was deployed. It’s possible for both the users who get Outlook (client-side) signatures in Outlook and who use the add-in to preview cloud (server-side) signatures in Outlook. To achieve this, sign in to CodeTwo Admin Panel and access the Web Add-in’s settings page, as described here, enable the Always disable end users’ default signatures in Outlook advanced option and click Apply (Fig. 1.).

Disabling native Outlook signatures for users with both cloud and CodeTwo Outlook signatures (combo mode).
Fig. 1. Disabling native Outlook signatures for users with both cloud and CodeTwo Outlook signatures (combo mode).

As of now, native signatures will no longer be added automatically when users compose a new message or use the reply/forward option in Outlook, regardless of the signature mode. Learn more

Downloading policy definitions (ADM/ADMX files)

Before you proceed

Your users need to be logged on to a domain to which you have full administrative access, because they have to be subjected to your GPO policies for this solution to work. Organizations working with Exchange Online (Microsoft 365) can also apply this solution if their users are connected to the on-premises Active Directory or Entra ID (Azure AD) to which you have full administrative access.

The provided solution requires a Security Group containing all users who should not have their signatures set up by Microsoft Outlook. If you do not have such a Security Group (e.g. Users with no signature - see Fig. 2.), create a new one directly under your domain.

Fig. 2. A Security Group with users who should not receive a signature.

If you don't have the Administrative Template policy settings (ADM or ADMX) file for the Outlook version used in your organization, you need to download it:

The next steps depend on your environment. Use the links below for guidelines.

Creating a new GPO in Windows Server 2008 / Windows Server 2012 / Windows Server 2016 / Windows Server 2019


Both the ADMX and ADML files are necessary to complete the installation. For more information on these files, see this Microsoft article.

  1. To install policy definitions in Windows Server 2008 and newer, open the location of the downloaded ADM/ADMX files.
  2. Open the ADMX folder and copy all the .admx files to the following directory:
  1. The ADML files are a significant part of the policy definition and need to be installed along with the ADMX files. If you open the PolicyDefinitions folder (see step 2) you can see at least one directory with the name that corresponds to your system's locale, e.g. en-US. Inside the downloaded policy settings package, in the ADMX folder, there are several subfolders with similar locale-related names. In order to complete the installation of the policies, you need to:
    • Ensure that you have opened the PolicyDefinitions folder and the ADM/ADMX files' download location (Fig. 3.).
    • Find out which directories with language-based names exist both in the PolicyDefinitions folder and in the download location.
    • In the download location, copy the folders whose names can also be found in the PolicyDefinitions folder.
    • Paste the copied folders into the PolicyDefinitions folder (see Fig. 3.).

Fig. 3. Copying files to PolicyDefinitions.

Before you proceed further, ensure that you have a relevant Security Group containing all users who should not receive signatures added by Microsoft Outlook.

  1. Now you need to create a new Group Policy Object. Open the Group Policy Management Editor by launching gpmc.msc from the Windows Start menu.
  2. In the left pane, right-click on your domain (e.g. domain103.lab) and select Create a GPO in this domain, and Link it here.
  3. Name your new GPO (e.g. No signatures) and click OK.
  4. Select the newly created object to open it.
  5. On the Scope tab, remove Authenticated Users from the Security Filtering pane.
  6. In the same pane, add the Security Group that you created earlier (e.g. Users with no signature), as shown in Fig. 4.

Fig. 4. Setting up a new GPO object.

  1. Finally, right-click your GPO in the left pane and select Edit from the shortcut menu. In the window that appears, navigate to User Configuration > Policies > Administrative Templates (or Classic Administrative Templates) > Microsoft Outlook [2010] (the number depends on your Outlook version) and Outlook Options, then Mail Format (Fig. 5.).  

Fig. 5. The location of the enabled policy.

  1. In the right pane you will see the Do not allow signatures for e-mail messages option. Enable it, as shown in Fig. 5.

Additional steps for click-to-run and Microsoft 365 Outlook versions

Once you complete the procedure described above, the following key will be added to the Windows registry for each user included in the GPO:


Unfortunately, Outlook for 365 and Outlook installed using the click-to-run installer seem to ignore this key. As a result, the policy to disable personal signatures is not applied at all for users with these versions of Outlook.

To solve the problem, you need to add a slightly different registry key, which will work with the affected Outlook versions, to your policy. Here’s how to do it:

  1. Right-click your No signatures (or whatever you named it) policy and choose Edit.
  2. Once you’re in the editor window, go to User Configuration > Preferences > Windows Settings in the left-hand pane.
  3. Next, right-click Registry, and choose New > Registry Item, as shown in Fig. 6.

Adding a new registry key to your policy.
Fig. 6. Adding a new registry key to your policy.

  1. In the dialog that opens, provide the following details (Fig. 7.):
  • Software\Microsoft\Office\16.0\Common\MailSettings in the Key Path field (bear in mind your Office version may be different, so you’ll need to replace 16.0 with the actual number of your version),
  • disablesignatures in the Value name field,
  • for Value type, choose REG_DWORD,
  • type 1 in the Value data field.

Configuring the registry key settings.
Fig. 7. Configuring the registry key settings.

  1. Finally, click OK.

All users have to log out and then log in for the changes to be applied. Moreover, you can manually force the policy update by running gpupdate /force. Keep in mind that these changes do not take effect immediately because the time of this process depends on your environment's configuration.

Creating a new GPO in Windows Server 2003 / SBS 2003

Before you follow the guidelines below, please ensure that you have a relevant Security Group containing all users who should not receive any signatures created by Microsoft Outlook.

  1. Open Active Directory Users and Computers.
  2. Right-click on your domain.
  3. Choose the Properties, Group Policy tab and click the Open button. The Group Policy Management opens.
  4. Right-click on your domain (e.g. sbs2003.local) and from the shortcut menu select Create and Link a GPO Here.
  5. Name your new Group Policy Object.
  6. Select the newly created GPO in the left pane and ensure that you have opened the Scope tab. 
  7. In the Security Filtering pane, add the Security Group you prepared earlier and then remove Authenticated Users from the list.
  8. Once it is done, right-click on your GPO in the left pane, then select Edit.
  9. Group Policy Object Editor shows up. Expand Administrative Templates. To install the previously downloaded policy definitions, right-click on Administrative Templates and select Add/Remove Templates. A new window appears (Fig. 8.).

Fig. 8. Additional administrative templates.

  1. Click the Add button and find the location where you downloaded the policy definitions. Open the ADM folder, then open the subfolder whose name corresponds to your system locale (e.g. en-us), select all the ADMfiles inside it, and click Open.
  2. New entries should appear on the Current Policy Templates list. Click Close to exit the Add/Remove Templates window.
  3. Now you are able to set policies to remove current signatures in Microsoft Outlook. To do so, please expand the Administrative Templates and select Microsoft Office Outlook XXXX (where XXXX stands for the version of the installed Office templates). In figures 9. and 10., you can see where the policies reponsible for disabling Outlook signatures are located in Office 2003 and Office 2007.

Fig. 9. Disabling signatures added by Outlook 2007, using Exchange Server.

Fig. 10. Disabling signatures added by Outlook 2003, using Exchange Server.

  1. To stop adding Outlook signatures to messages, set the options highlighted in Fig. 9. and  10. (depending on your Outlook version) to Enabled. Additionally for Outlook 2003, make sure that both options (Disable signatures for new messages and Disable signatures for replies and forwards - see Fig. 10.) are configured as shown in Fig. 11.

How set up disabling signatures from Otlook 2003.
Fig. 11. Additional configuration for Outlook 2003 in Exchange Server.

  1. All users have to log out and then log in for the changes to be applied. Moreover, you can manually force the policy update by running gpupdate /force.

These changes do not take effect immediately - the deployment time depends on the configuration of your environment.

See also:

Was this information useful?