Product: CodeTwo Email Signatures for Office 365
Product Homepage: click here
Free Trial: click here
Practically since email gained traction and started to be used by more and more people, email signatures have been used in one way or another. Nowadays, signatures range from a simple name and contact details to complex and sometimes beautiful graphical signatures with detailed information about the sender, the organization, or marketing data, for example.
For some businesses, email signatures play an important role in which they help make recipients aware of services the organization provides, helping to increase market exposure and possibly even revenue.
In this product review, I will be having a look at Email Signatures for Office 365 solution by CodeTwo, a Polish software vendor and Microsoft Partner. CodeTwo is widely known for its backup and migration solutions for Exchange and Office 365, as well as many other tools, some of them even free. Amongst these arsenal of products, CodeTwo has tools for email signatures, including ones to centrally manage client-sided signatures for Office 365, G Suite, OWA, and Outlook, as well as server-side rules like the solution I will reviewing here.
CodeTwo is no stranger to email signatures, with over 10 years experience in the field, and solutions for email signatures that go all the way back from Exchange 2000 and up to Exchange 2016 and Office 365.
In a nutshell, CodeTwo Email Signatures for Office 365 is an innovative cloud application that allows organizations to design and centrally manage email signatures, disclaimers, and marketing banners for Office 365 users.
How does it work?
While CodeTwo on-premises solutions for email signatures are based on Exchange Transport Agents and Windows Services running locally on Exchange servers, the Office 365 version cannot use such an approach because Microsoft does not provide server-level access to the servers running Exchange Online. As such, CodeTwo had to rethink its approach. The solution was to use send and receive connectors in Exchange Online to route internal and/or outgoing emails through CodeTwo’s services. These services are hosted on Microsoft Azure servers.
When a user sends an email, that email is sent to CodeTwo Email Azure Service using the newly created send connector, and a signature is applied if the email meets specific conditions defined by administrators. The email is then returned to Office 365 or Exchange Online Protection (EOP) using the new receive connector, and then sent on to its final recipient.
This obviously introduces a small delay in the overall message flow, but CodeTwo states that the average overhead they have observed is around 6 seconds, which seems a perfectly acceptable delay. In my tests, this introduced a 4 second to 5 second delay on average:
Running the application’s engine (CodeTwo Email Azure Service) in the cloud gives the application two major benefits:
- There are no limits when it comes to senders’ email clients (discussed later in this review).
- No setup or changes are required on the client side.
In terms of security, this solution seems to tick all the boxes. First, when we sign up for Email Signatures, we are asked from which location we want to consume CodeTwo services, meaning our emails are processed by CodeTwo servers within the same Microsoft datacenter as our Office 365 tenant.
Then, everything is TLS-encrypted, and CodeTwo does not store any emails or credentials. The latter is achieved by using token-based authentication (OAuth 2.0), which allows third-party applications developed by Microsoft partners to securely use Office 365 users’ information without exposing user credentials and any other sensitive information. This is explained in more detail in the Looking at Microsoft Security from a Developer’s Perspective article.
As to high availability, CodeTwo does not guarantee a specific uptime, but since going live it has consistently maintained a high average uptime of 99.93 percent, matching the highest standards of uptime guaranteed by Microsoft’s cloud services. This is achieved by making the service fault tolerant, meaning that in case of any failure, it fails over automatically to secondary servers in the same geolocation.
Configuring Email Signatures for Office 365
CodeTwo provides a 14-day fully functional trial that anyone can sign up for using this link, or through their main website for this product:
To create a trial account, we chose the log in or create account option:
We can use a Microsoft account or create a dedicated CodeTwo User Panel account. For this review, I will be using my Office 365 tenant’s Microsoft account, but this is not required:
Once we enter our login details, we have to accept the permissions that will be given to CodeTwo:
We are then taken to our Email Signatures Dashboard:
From this dashboard, we have access to a variety of information such as our account details, the status of the service (which we will look at shortly), payment methods if we want to use the service past the 14-day trial, and more.
The first step to start creating and using email signatures is to add a new tenant. We can do this by going to the Tenants tab at the top, or simply by clicking the “+” icon next to the Tenants box. We start by accepting the license agreement:
Next, we are redirected to the Microsoft account sign-in website where we need to log in with our Office 365 global admin credentials (again, the process uses OAuth and no credentials are stored by CodeTwo):
Once more, we confirm the permissions given to CodeTwo and click Accept:
Then, in the Geolocation step of the wizard, we choose where we would like to use CodeTwo services from, typically the closest location to our Office 365 tenant, and click Register. Please be aware that it is not possible to change this later without deregistering your tenant, which will also cancel your subscription. The best option in this case is to contact CodeTwo’s support.
The only manual step in the entire process is to update our Sender Policy Framework (SPF) record and add “include:spf.emailsignatures365.com.” This is so EOP does not block our own emails coming back from CodeTwo into our tenant:
After the SPF record has been updated, we need to configure our send and receive connectors in Exchange Online. This is required so that emails sent from our organization can be forwarded to CodeTwo Email Azure Service, which checks them against rules we configure and then stamps them with signatures. We don’t have to configure these connectors at this stage, but obviously signatures will not be applied until we do so.
These connectors can be configured manually using CodeTwo’s excellent manual or automatically (recommended to avoid any errors) by using the Configure connectors link:
Once more, we need to provide the credentials of an Office 365 global admin. This is because the initial authorization via Azure’s OAuth 2.0 does not allow any third-party apps to access the connectors configuration in Office 365 tenants:
We then need to choose if emails from all users will be routed through CodeTwo Email Azure Service to get signatures applied, or only emails from users that belong to a certain distribution group. This is a very useful feature, especially for testing purposes and to allow customers to buy licenses only for a limited number of users and not the entire organization. We can also choose if we want signatures applied to internal emails, or only those sent to external recipients:
We are now ready to get our new connectors configured:
Please be aware that if the global admin account provided earlier is configured for two-factor authentication (2FA), the connector configuration will fail:
To overcome this, you can either manually configure the rules, as already mentioned, or temporarily disable 2FA, which I did:
If we now go to our Exchange Online admin console, we can see the two new connectors that will be used to route email to and from CodeTwo service:
There is also a new transport rule that will determine which emails to route. In my case, this is any email sent by users in my tenant, except for calendar invites/responses and emails that have the X-CodeTwoProcessed header (used to not process the same message twice):
Back in the control panel, we can check that everything is OK with the service by clicking on Service status. We can also subscribe to a RSS feed so we get notifications about service status changes:
And we are done! It is now time to start configuring and testing our signatures.
Using Email Signatures for Office 365
From an Office 365 perspective, we now have everything in place to start applying signatures to our emails. However, there is still some work left to do from the CodeTwo side, such as creating one or more signature rules that determine the conditions required to add signatures to our emails, and creating a signature itself. To add and configure signature rules, we go to our Dashboard and click the Manage signatures icon:
This will start the Admin Console, which is the application designed to help us configure signature rules.
Each time we launch the admin console, it checks for newer versions and prompts us to install the most recent update, if available. It starts by displaying the Welcome screen at launch:
We need to login to our Office 365 tenant using a global admin account in order to proceed. This process also uses Azure OAuth.
Now that we are logged into the admin console, we can create our first signature rule by clicking on the “+” icon:
The first step to create a signature starts in the Overview pane, where we give our rule a name and ensure it is enabled:
Then comes our conditions and exceptions. First, under Senders, we specify to which senders we want to apply signatures to and if we want to exclude anyone:
We can include/exclude individual users, distribution groups or even create more advanced Azure AD filters:
Next is an option I really like. In Keywords, we can define a keyword condition so that signatures are only applied to emails that match this keyword. In this example, I am specifying that signatures should only apply to emails that have the keyword [Testing] in the subject, and that the keyword should not be removed from the subject (the possibility to remove the keyword from the subject is excellent):
However, for testing purposes, I would recommend adding this condition to the transport rule itself so that emails we do not want to have a signature don’t go through CodeTwo service unnecessarily.
In Email direction, we specify if we want signatures applied to all emails (both internal and external), to internal only, or to external only:
Finally under Design, we have two more options:
The first setting is about email positioning, where we specify how and where we should apply the signature (in my case I chose Signature in the first email only). This is important as different organizations have their own preference and requirements. It is even possible to apply one signature to the first email a user sends, and then a different one (maybe simpler or smaller one) to all subsequent emails!
The second setting is the signature itself. Here we click on Load template, which takes us to a template gallery where we can choose from several signatures designed by CodeTwo:
For this test, let’s choose the following signature:
However, as I want to change a few things I click in Edit, which launches a nice HTML editor from which I can change the signature to my liking:
This built-in editor allows us to easily design email signatures in HTML, RTF and pure text formats, and even to preview how these will look for any user in our tenant!
Images can be easily inserted and arranged in various combinations, including user’s photos stored in Azure AD. We can also choose which AD attributes to dynamically include in our signature by using the AD attributes dropdown:
Once we are happy with all the changes, we simply click Save and our first signature is ready!
Sending a quick test email will show the results of our work so far:
Simple as that! If desired, we can now create additional signatures and multiple rules for different users or departments, for example.
Other features
To conclude this review, I would like to highlight a few other features of CodeTwo Email Signatures for Office 365, some of them already covered in some level throughout this review.
Embedded images
When adding images to a signature, these do not have to be pulled from the Internet by the recipient as they are embedded within the email itself. This causes a small but negligible increase in the email size, but avoids situations where images are blocked and not displayed in the email, possibly ruining the whole signature.
Azure Active Directory user details
As we have already seen, Email Signatures for Office 365 allows us to add AD attributes of users to email signatures. In order to quickly add signatures with users’ details to emails, and to keep Azure AD load at a minimum, the service stores all user’s AD attributes in an internal cache and automatically synchronizes them with our tenant’s Azure AD every 60 minutes. If necessary, we can manually update the AD Azure cache via the Update cache manually now button:
The service also lets us use our own AD custom attributes when composing signatures (also known as Directory extension attributes), even in non-hybrid environments by using CodeTwo’s Email Signatures for Office 365 Custom Attributes Sync app. This app is installed locally on a computer or server, and synchronizes custom attributes to CodeTwo service.
Any device, any client, anywhere
This might be obvious, but since this is a server-side solution, it brings two advantages: it allows us to centrally manage, edit, and automatically insert email signatures and disclaimers to emails, and it works perfectly regardless of what email client is used by users. No matter if they use Outlook, MacMail, Thunderbird, Outlook on the Web (OWA), or even their stock mobile device email client, email signatures are added automatically in the exact position and with the same design as defined by our rule.
Marketing
Email signatures can go a step further beyond promoting an organization’s brand and products to customers. By adding some URL tagging to links, it is possible to easily track the results of a marketing campaign in a web analytics platform such as Google Analytics, as explained in detail in this article.
Sent items update feature
As signatures and disclaimers are added to sent emails when they go through CodeTwo Email Azure Service, they are not visible in the users’ Sent Items folder. This is the case of any email signature solution other than when using Outlook itself. To let users see the signatures in their sent items, CodeTwo Email Signatures has a feature called Sent Items Update (SIU) that, as the name suggests, updates users’ sent messages with signatures after these have been processed.
SIU is installed along with the CodeTwo Email Azure Service, but works as a separate service. It is totally independent from mail flow and the functioning of our Office 365 tenant, which means it has no influence on email processing and delivery time. Once more, emails are not stored anywhere and SIU does not require any service accounts to operate as the authentication and authorization processes use OAuth 2.0.
By default, SIU is disabled and needs to be enabled by an admin in the CodeTwo User Panel to start updating sent emails. It works per tenant, so we have to turn it on for each tenant separately.
Once enabled, we are notified that signatures will now appear in users’ Sent Items (for new emails they send from now on), which they do within just a few seconds.
The verdict
CodeTwo Email Signatures for Office 365 is one of the best email signature solutions I have seen. It makes the whole process straightforward and its HTML editor is easy to use and quick to provide great looking results.
If everything could be done online without the need to install a separate admin console, this would have been a 5/5 rating.
MSExchange.org Rating 4.8/5
