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.

Important

Keep in mind that the Recipients and Keywords steps are available for cloud (server-side) signature rules only. As for Outlook (client-side) signature rules, only the Senders step is available, where you define which users should have access to a specific signature. These users can then choose different signatures depending on the recipients of their emails directly in Outlook. Learn more about signature modes

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.

The Senders step with 1 condition and 1 exception configured.
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.

Info

The scope of users who can get signatures might also be limited during the configuration of connectors. Learn more

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.

Azure Active Directory filter options.
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.

Important

  1. Remember to define at least one user in the conditions field (the top list). If you leave this section empty, signatures will be added to all users specified in the connectors wizard (learn more). The program will notify you about that (and automatically add the All senders condition to the top list) when you submit your changes via the Save & Publish button.
  2. If you would like to create a rule, but do not want to apply it to any users yet, you can click the Save button instead. If the rule has already been published, you can temporarily disable it via the Unpublish button available in the main window of the signature management app (learn more).
  3. If you add members of a group that has other group(s) nested inside, emails sent by members of the nested group(s) will also meet your condition/exception.
  4. User AD field (see Fig. 2.) includes common AD attributes such as First/Last name, Company, Department, E-mail or Phone, Exchange Online custom attributes, attributes synced from on-prem Exchange Server, as well as CodeTwo custom attributes.
  5. If you have multiple domains added to your Microsoft 365 tenant (e.g. @my-company1.com, @my-company2.com, etc.), the user and group pickers used in the program will list mailboxes/groups with email addresses from all these domains (Fig. 3.).

The user picker shows the primary email addresses (mailboxes) for all domains added to your tenant.
Fig. 3. The user picker shows the primary email addresses (mailboxes) for all domains added to your tenant.

  1. You can define conditions and exceptions based on the primary email address only. This means the pickers will not show email aliases. The Azure AD filter option (see Fig. 2.) also does not support aliases. Learn more about using email aliases with CodeTwo Email Signatures 365

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).

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

Important

  1. To be able to add signatures to internal emails, make sure that the option Apply signatures also to internal messages has been selected during the configuration of Exchange Online connectors. Otherwise, internal emails will not pass through CodeTwo services. Learn more
  2. If you send an email to multiple recipients (associated with different rules), each recipient will get your email with the right signature. See this section to learn more.
  3. Remember to define at least one condition on the top list. If you leave this section empty, the rule will apply to emails sent to any recipient. The app will notify you about that (and automatically add the All recipients condition to the top list) when you submit your changes via the Save & Publish button.

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.

The Keywords step available for cloud (server-side) signature rules.
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.

Keyword configuration options.
Fig. 6. Keyword configuration options.

Info

You can insert your keyword anywhere inside the message title or body. An asterisk (*) may be used as a wildcard character. Add it before and/or after the phrase to make sure that your keyword is always found (see Fig. 6.).

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.

Important

If the Scheduler is off or is not yet configured for a signature rule, this rule will be active continuously (without any time limits).

The Scheduler's activity is based on the selected time zone. You can choose the time zone yourself by using the drop-down menu at the top (see Fig. 7.). If it’s possible to obtain sufficient information from your web browser and operating system, your time zone will be detected (and selected) automatically.

Configuration of the Scheduler.
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 (ESIG for O365 scheduler button ON) or not (ESIG for O365 scheduler button PAUSE).

Logic

In the Logic step, you can:

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.

The Logic step available for cloud (server-side) signature rules.
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.

List of cloud (server-side) signatures. The rules are applied in the order they are placed on the list.
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.

Keep in mind that users can still select a different signature while composing a message 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.

Warning

The CodeTwo Signatures Add-in for Outlook deletes all user-defined signatures from all email accounts and profiles configured in Outlook, not only from the account signed in in the add-in.

The Logic step available for Outlook (client-side) signature rules.
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.

Important

The relation between the Senders, Recipients and Keywords conditions is logical conjunction (the AND logical operator). This means that all these conditions must be fulfilled to trigger a rule and add a corresponding signature.

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.

The Senders step with one condition.
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.).

Configuration of the Recipients condition: here, the rule applies to external emails only.
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.

The Keywords step with one Keyword condition.
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:

Important

If you define multiple exceptions, a signature rule is suppressed for each exception individually.

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.

Adding an exception to email senders.
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.

Defining a new Recipients exception.
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.

Defining a keyword exception.
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.).

ESIG 365 - message splitting (bifurcation) diagram
Fig. 17. How message splitting works.

Important

  • Email headers: The email header is not changed – the recipients listed in the To or Cc fields of the original message will be included in every email copy after splitting. Only the body of each email copy differs (it includes a different signature) as a result of processing by different rules.
  • The Sent Items folder: Only one email copy will be visible in your Sent Items – it will be the one that was processed last by the CodeTwo cloud service. Learn more

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. 

Classic experience (UI)

If you use the classic signature management experience, when both User A and User B edit signature rules in their browser and User A saves changes first, User B will not be able to make any changes to rules (and will be notified about it). User B needs to refresh the page to make their changes. After the refresh, User B will see all changes made by User A (but will lose their changes).

The same applies if User A and User B use different signature management experiences – users who use classic experience will always be blocked from making changes (if another user saves changes in the new experience first), while users who use new experience will always be able to save their changes (overwriting changes made by users who use the classic UI).

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.

In this article

Was this information useful?