Conditions and exceptions

Signature rules let you design your signatures, specify when to add them to emails sent by your organization and which users should get them. The signature-adding algorithm is based on conditions and exceptions, defined individually for each signature rule. Conditions are circumstances that need to be fulfilled to trigger a signature rule and add a related signature. Exceptions are the exact opposite – when they are met, your signature will not be added. This article explains how it all works.

Defining conditions and exceptions for a signature rule

To configure conditions and exceptions for a signature rule, access app.codetwo.com and sign in to your Microsoft 365 tenant. Next, select your signature rule from the list or create a new one: either cloud (server-side) or Outlook (client-side). The Name step allows you to name your rule and add an optional description. Conditions and exceptions are defined in the Senders, Recipients and Keywords steps, with scheduling options available in the Scheduler step and additional settings present in the Logic step.

Senders

The Senders step lets you specify users to whom your signature rule will be applied (Fig. 1.). If you are configuring a cloud (server-side) signature rule, the top list (Add the signature to emails...) allows you to define conditions by choosing senders whose emails will be stamped with your signature. The bottom list (Do not add the signature to emails...) allows you to add exceptions – users who will not get the signature. As for Outlook (client-side) signature rules, the Senders step is where you define users that will have access to the signature from Outlook.

Fig. 1. The Senders step with 1 condition and 1 exception configured.

The program allows you to define the Senders conditions and exceptions in many ways: you can add all or individual users, members of selected groups in your organization, or set custom filters based on Azure AD attributes.

If you add multiple different senders on the conditions list (the top list in Fig. 1.), they are all connected by the OR logical operator; exceptions on the bottom list work in the same way. In the example shown in Fig. 1. we configured the rule to add signatures to emails sent by our IT guys, excluding the managers. The software knows when to add signatures because we added an Azure Active Directory filter condition to check if the sender's Department field in Active Directory is equal to IT – see Fig. 2. for detailed configuration. In a similar way, an exception to the rule was defined: if the user's Title in AD contains the value Manager, the rule is not triggered.

Fig. 2. Azure Active Directory filter options.

Thanks to all these user configuration possibilities, you can apply your signature rule to a group of users and exclude one or more users at the same time, for example:

• add a signature to the whole IT department except for the manager whose signature is covered by a different rule (this is the example above);
• add a legal disclaimer to all company emails except for the emails of employees from a foreign site, because different laws apply there;
• add signatures with marketing banners to the whole Customer Support department but not to emails sent by people from other departments, etc.

Recipients

The Recipients step (Fig. 4.) is only available for cloud (server-side) signature rules. Here, you need to choose if you want to add your signature to emails sent to everyone or to specific people only. This selection is made on the top list of the Recipients step. You can also add exceptions - if an email is sent to recipients specified on the bottom list, the rule will not be applied, and the signature will not be added. On the conditions list, you can select:

• all recipients or internal/external recipients only (an email direction-based condition),
• members of specific groups (Microsoft 365 groups, distribution lists, security groups and mail-enabled security groups) in your organization,
• specific email addresses.

When using the email address filter, you can use asterisks (*) as wildcards that substitute any number of characters. This allows you to create, for example, conditions/exceptions that apply only when emails are sent to specific domains. For instance, if you select the Email addresses option on the top list and type *example.com*, the rule will apply only to emails sent to email addresses that include example.com ([email protected], [email protected], and so on).

Fig. 4. The Recipients step. Here, the rule applies to emails sent to anyone.

Keywords

The Keywords step (Fig. 5.) allows you to define specific phrases that will trigger or suppress your cloud (server-side) signature rule. This option is very useful e.g. when you want to apply an additional signature only to selected recipients or if you want to quickly remove the default signature of your company from a private message. The latter is shown in Fig. 5.: if the program finds the #nosignature phrase in the email subject or body, the signature will not be added and the phrase itself will be removed from the message. The asterisks surrounding the keyword phrase are optional, but here they ensure the rule will be triggered even if any characters (letters or signs) directly precede or follow the phrase, so phrases such as (#nosignature) or -#nosignatures will all work.

Fig. 5. The Keywords step available for cloud (server-side) signature rules.

You can add one or more keywords. By default, they are connected via the OR logical operator.

When adding or editing a keyword (Fig. 6.) you can define where to search for the phrase and decide if the program should remove it from the message.

Fig. 6. Keyword configuration options.

For more information about how to use keywords to force or suppress signature rules, check these examples of use.

Scheduler

In the Scheduler step (Fig. 7.), you can specify when your rule will be active. ​The Scheduler is configured separately for each rule. It allows you to manage the activity of a rule by selecting time ranges and recurrence patterns. You can create daily, weekly, monthly or custom patterns.

Fig. 7. Configuration of the Scheduler.

If you turn the Scheduler on for your rule, a small icon appears next to the rule's name (see Fig. 9.). This icon shows if the rule is currently active () or not ().

Logic

In the Logic step, you can:

• define how the program should process subsequent rules if you have more than one – settings available for cloud (server-side) signature rules only,
• configure Outlook signature adding options – settings available for Outlook (client-side) signature rules only.

Rule processing settings for cloud (server-side) signature rules

If you use many signature rules in your Microsoft 365 organization, it is important to manage how they are executed. You can do this in the Logic step (Fig. 8):

• If you select the option If this rule is applied > Process the next rule on the list, our software will check if the conditions of the signature rule are met, and if they are, it will add a signature defined by the rule and move to the next rule (the one directly below it on the list). If you select If this rule is applied > Do not process any more rules, our software will check if the conditions of the signature rule are met, and if they are, it will not process any more rules.
• When it comes to the If this rule is not applied option, the case is similar. Our software checks if the conditions of the signature rule are met, and if they are not, it moves to the next rule or stops processing any other rules depending on the choice you made.

Fig. 8. The Logic step available for cloud (server-side) signature rules.

When setting up the processing of multiple rules, remember:

• The settings are configured for each rule separately.
• The rules are applied in the order they are placed on the cloud (server-side) signatures list visible in the signature management app's main window (see Fig. 9.), from top to bottom.
• If several signatures are to be added by different rules, they will be added top to bottom in the same order as the rules that govern them.

Fig. 9. List of cloud (server-side) signatures. The rules are applied in the order they are placed on the list.

This is important if you want to add several signatures in a specific order. The order of rules can be changed using the Move up and Move down buttons (as shown in Fig. 9.). For each rule you also need to decide what happens if it is applied or not.

For each signature, the process of checking if the conditions of the signature rule are met continues until the program reaches the final signature rule (at the bottom of the list) or until the condition to stop processing next rules is met.

Outlook signature adding options for Outlook (client-side) signature rules

There are three options available (see Fig. 10.):

• Set this signature as default for new messages

When this option is enabled (the default setting), the signature defined in this rule is automatically added to the body of each new email created in Outlook. If the option is enabled in multiple Outlook (client-side) signature rules, each of which is used to set up a different signature for the same user, the signature defined in the first rule (that is, the rule that is on the top of the Outlook signatures list) will be used as the default one in Outlook.

• Set this signature as default for replies and forwards

This option works similarly to the previous one, only the signature is automatically added to replies and forwards. 

• Remove all user-defined signatures in Outlook (works with the legacy COM Add-in only)

If you enable this option, all user-created signatures will be deleted from Outlook. The program will delete the signatures only of those users who fulfill the conditions specified in the signature rule, have installed the CodeTwo Signatures Add-in in Outlook, and are signed in in that add-in. The user-created signatures are removed each time the CodeTwo services sync with the Outlook add-in.

Fig. 10. The Logic step available for Outlook (client-side) signature rules.

In the case of the modern CodeTwo Signatures Web Add-in for Outlook, the user-defined signatures are disabled automatically as described in this article.

Understanding conditions and exceptions

As described above, the Senders, Recipients and Keywords steps let you set conditions (or exceptions) that need to be fulfilled by a message to trigger (or suppress) a rule and add (or exclude) an email signature. Apart from conditions and exceptions, you can specify when a signature rule should be active by using the options available in the Scheduler step.

To manage email signatures efficiently, it's important to understand how conditions and exceptions are related.

Conditions

Conditions can be defined on the top lists of the Senders, Recipients and Keywords steps.

To better understand that, imagine the following scenario for a cloud (server-side) signature rule: a company has a new product named XYZ and would like to add a dedicated signature to selected emails sent by the marketing team outside the organization. Let us assume that we already created a new signature rule and designed the signature template for this rule, and we only need to define the conditions for when this template is added.

First, we select this rule on the rules list and go to the Senders step. We add the Marketing group as the condition (top list), with no other conditions or exceptions (Fig. 11.). This means that our signature will be added only to emails sent by the employees working in Marketing.

Fig. 11. The Senders step with one condition.

After that, we need to specify the email recipients to whom this rule will apply. We want our signature advertisement to be added to emails sent outside the organization. To do that, we switch to the Recipients step and add External recipients to the top list (Fig. 12.).

Fig. 12. Configuration of the Recipients condition: here, the rule applies to external emails only.

Finally, we define a Keyword condition (upper list in the Keywords step) for email subjects by adding the XYZ phrase (the name of our product), as shown in Fig. 13. We set the keyword phrase not to be removed because we assume that our advertising emails always contain (and should contain) the name of the product advertised.

Fig. 13. The Keywords step with one Keyword condition.

With this configuration, our signature will be added only to emails which simultaneously fulfill all three conditions:

• are sent by the Marketing team
• and are sent to users outside the organization
• and contain XYZ (product name) in the message subject.

Exceptions

Exceptions (the bottom lists in the Senders, Recipients and Keywords steps) are connected via the OR logical operator (logical disjunction). In other words:

The following example will help you understand how exceptions are processed by the program. Let us modify the cloud (server-side) signature rule described in the previous example. In the Senders step, we add an exception (the bottom list) by creating an Azure AD filter, as shown in Fig. 14. This will exclude users whose job title contains the word Manager (our search algorithm is case-insensitive) from having their emails stamped with the associated signature.

Fig. 14. Adding an exception to email senders.

Now, let's assume that we have a separate email marketing campaign for Canada, so we need to make sure our current rule does not apply to emails sent to the .ca domain. To do that, we go to the Recipients step, choose the Email addresses option on the bottom list (exceptions) and type *.ca as the email address (Fig. 15.). The wildcard (*) character ensures that all email addresses ending with .ca will trigger our signature rule.

Fig. 15. Defining a new Recipients exception.

We can also create an exception that stops the rule from being applied when a specific phrase is typed in an email. We can do so in the Keywords step, as shown in Fig. 16. With this configuration, every email which contains the nosignature phrase in its body or subject will not receive the signature, and the phrase itself will be removed from the message.

Fig. 16. Defining a keyword exception.

With these 3 exceptions and the previous 3 conditions combined, our rule will:

• add the signature only to emails that are sent by Marketing to external addresses and contain the XYZ phrase in the message subject,
• not add the signature in 3 cases:
  • if an email is sent by a user whose job title contains the word manager (case-insensitive)
    or
  • if an email is sent to an email address in the Canadian (.ca) domain
    or
  • if the nosignature phrase is found in the message subject or body.

Frequently asked questions

Adding signatures to messages sent by delegates (Send As / Send on Behalf permissions)

Sometimes a user or a group of users have permission to send messages as other users or on their behalf. These users are referred to as delegates (see this Microsoft article for more information on delegate permissions). To find out how the software handles emails sent as / sent on behalf of another user, read this dedicated article.

What if an email is sent to multiple recipients to whom different cloud (server-side) rules apply? (Message splitting)

The software comes with a message splitting (bifurcation) capability: when you send an email to multiple recipients, and different signature rules apply to these recipients, the software makes sure each recipient gets your email with the right signature version. To do so, the message is split into several identical copies. The number of these copies is equal to the number of different rules that apply to the recipients of your message. Each copy is processed by each related rule and sent only to the recipient(s) that match this rule.

Example: You send an email to 4 recipients to whom 3 different signature rules apply. The software creates 3 instances of this message, and each instance is stamped with a different signature and is sent to the recipient(s) who should see this particular signature (Fig. 17.).

Fig. 17. How message splitting works.

What happens if an email is sent to two recipients, and one recipient meets the condition while the other meets the exception of the same cloud (server-side) signature rule?

In this case, each recipient will get the right version of the message, because the message splitting will occur.

Example: In the Recipients step, you add one condition ([email protected]) and one exception ([email protected]). If you send an email to both A and B, the email will be split into two copies, and recipient A will get the copy with the signature while recipient B will get the copy without the signature. See this section for additional info and important notes.

Can I transfer my on-premises signature rules to CodeTwo Email Signatures 365?

Yes, we have a dedicated tool that allows you to easily move all email signature and disclaimer adding rules and rules with the Auto respond action defined in the CodeTwo Exchange Rules family of products, together with signature and auto-reply message templates configured in these rules. The entire process is completely automatic, and your rules will become available in CodeTwo Email Signatures 365 as cloud (server-side) signature rules or autoresponder rules.

Learn more about the CodeTwo Exchange Rules Converter

What happens when multiple users save changes to rules at the same time?

When both User A and User B edit the rules at the same time and User A saves changes first, User B will be able to save their changes next, but it will overwrite all changes made by User A. 

See next

Signature template editor - after you specify all the conditions and exceptions for your signature rule, it's time to design an email signature. Read this quick guide to learn how to create a signature template step by step.