[Update]: This article was first published on October 19, 2015. It was updated to include more useful information.
Active Directory (AD) and Microsoft Entra ID (Azure Active Directory or AAD) are databases that contain a lot of information about a company, especially its employees. There is a lot of different ways to access this data and even more ways in which you can use it. Pretty much every app and service for Microsoft 365 or Exchange Server uses at least some information from this data treasury to offer better collaboration, automation, etc. In a nutshell, AD user attributes are there to make your job easier. That’s why it might help to know which information is easily accessible and how to get it from your user directory.
In this article, I’ll focus on using Active Directory data to personalize a global email signature across an organization.
What is a global email signature?
A global email signature is a way to manage email signatures in an organization. The general idea is to use one signature template and automatically personalize it for all users. Thanks to this, every mailbox can get a professional, company-controlled signature, without the need for users to do anything. Personal info and contact data used to personalize the template is taken straight from Active Directory (for Exchange Server) or Microsoft Entra ID (for Exchange Online).
There are two most common ways to create a global email signature in Microsoft 365 and Exchange Server:
- Using mail-flow / transport rules. This way, signatures are added in transit – after an email is sent. Here’s a video that shows how to set it up
- Using VBScript. This way, email signatures are created directly in Outlook’s for Windows signature settings. Those articles show how to create and use such scripts:
It’s crucial to know what user attributes are available for signatures and how exactly to use them. And that’s precisely what you’ll learn below.
Active Directory user attributes in signatures: available placeholders for mail flow rules and VBScript
When deploying email signatures for multiple users from a central place, you need a way to easily include these users’ personal information like names, titles, departments, addresses, etc. in the signatures. This is achieved using placeholders integrated with a central directory that stores users’ personal details (e.g. Active Directory), and including the placeholders in signature templates.
Both Microsoft Exchange Server’s and Microsoft 365’s built-in email signature management solutions do exactly that, i.e. download data from Active Directory (or Office 365 user directory) into the signature based on who is the sender of the given email.
Unfortunately, Microsoft 365 and on-premises Exchange do not support all AD user account attributes. However, those which are available should be enough to create a simple email signature.
Here is the full list of attributes supported by Exchange’s and Office 365’s email signature management solutions. I divided them into sections that correspond with tabs in the Active Directory Users and Computers object Properties window. In the right column I’ve put the Active Directory Domain Services names of attributes (use them when deploying the signature template via a VBS script).
IMPORTANT: When setting up email signatures in hub transport/mail flow rules in Exchange 2019, 2016, 2013, 2010 or Microsoft 365, remember to enclose the ADAttribute (left column of below table) with double percent signs, like shown in the table. The “%%” part is not for show.
List of Active Directory user attributes available for email signature rules and VBScript
Active Directory attributes in Exchange and Office 365 email signatures
Used in mail flow rules | Used in a VBScript |
General | |
%%DisplayName%% | AD DS: displayName |
%%FirstName%% | AD DS: givenName |
%%Initials%% | AD DS: initials |
%%LastName%% | AD DS: sn |
%%Office%% | AD DS: physicalDeliveryOfficeName |
%%PhoneNumber%% | AD DS: telephoneNumber |
%%OtherPhoneNumber%% | AD DS: otherTelephone |
%%Email%% | AD DS: mail |
Address | |
%%Street%% | AD DS: streetAddress |
%%POBox%% | AD DS: postOfficeBox |
%%City%% | AD DS: l (as in "location") |
%%State%% | AD DS: st |
%%ZipCode%% | AD DS: postalCode |
%%Country%% | AD DS: co |
Account | |
%%UserLogonName%% | AD DS: userPrincipalName |
Telephones | |
%%HomePhoneNumber%% | AD DS: homePhone |
%%OtherHomePhoneNumber%% | AD DS: otherHomePhone |
%%PagerNumber%% | AD DS: pager |
%%MobileNumber%% | AD DS: mobile |
%%FaxNumber%% | AD DS: facsimileTelephoneNumber |
%%OtherFaxNumber%% | AD DS: otherFacsimileTelephoneNumber |
%%Notes%% | AD DS: info |
Organization | |
%%Title%% | AD DS: title |
%%Department%% | AD DS: department |
%%Company%% | AD DS: company |
%%Manager%% | Returns the common name (cn) of the object defined in the manager AD DS attribute |
Attribute Editor* | |
CustomAttribute1-15 (e.g. %%CustomAttribute1%%) | AD DS: extensionAttribute1 through extensionAttribute15 |
Note: Some Active Directory attributes (e.g. otherTelephone, otherHomePhone, otherFacsimileTelephoneNumber and postOfficeBox) support multiple values. In the case where more than 1 value is provided, the output will include all values separated by semicolons.
* To see this tab in AD Users and Computers, switch on Advanced Features. Custom attributes can also be defined via Exchange Management Console (in users’ Mailbox Properties) or Exchange Management Shell.
Advanced email signature management
While mail flow rules and VBScript let you manage email signatures in a company, they are not ideal. No matter if you use them in on-premises Exchange or Microsoft 365, they have their dark sides. I list some of them below:
Mail flow rule signatures
- Need to be managed by IT.
- Offer no signature editor (you need to use raw HTML code).
- Signatures are added either at the very top or the very bottom of an email conversation. In other words, they work well(ish) only for a first message and not for replies and forwards.
- Only online images can be used. Most email clients block those images by default.
- There’s no way for users to see their signatures before they send an email or even in Sent Items. This usually results in more tickets to IT (‘my signature is missing’ / ’I have double signatures’).
- No way to convert emails to HTML format. Simply speaking – if users send emails from mobiles, they’ll only get a broken plain text signature.
That’s only a few of the limitations. For a complete list of limitations, see this article.
VBScript email signatures
- Work only for Outlook for Windows.
- Require you to have at least some scripting skills.
- Require a local Active Directory.
- Are difficult to update.
If you want to change your email signature management method to easy, effective and free from those limitations, check out those tools.