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 decide which users will have access to the signature in Outlook.

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

You can define the Senders conditions and exceptions in many ways. If you add multiple senders to the conditions list (the top list in Fig. 1.), they are all connected by the OR logical operator; exceptions in the bottom list work in the same way. For example, you can apply your signature rule to a group of users and exclude one or more users at the same time in the following ways:

  • add a signature to the entire IT department except for the manager, whose signature is governed by a different rule (this is the example shown in Fig. 1.);
  • add a legal disclaimer to all company emails except for the emails sent by employees from a foreign site, due to different legal requirements;
  • add signatures with marketing banners to emails from the Customer Support department but not to emails sent by people from other departments, etc.

Click Add below the conditions or exceptions list and select senders by using the following options:

  • All senders – the rule will apply to all users and shared mailboxes within your Microsoft 365 tenant.
  • Selected senders – this opens a user picker that lists users and shared mailboxes from your tenant (Fig. 2.). You can select a single user or multiple users by using the Ctrl or Shift keys.
  • Group members (inside organization) – this opens a group picker that lists groups (Microsoft 365 groups, distribution lists, security groups and mail-enabled security groups) from your tenant. Note that the rule will apply to members of the selected groups, not the groups themselves. If the group you select has other group(s) nested inside, emails sent by members of nested groups will also meet your condition/exception.
  • Azure AD filter – this lets you set up custom filters based on Entra ID (Azure AD) attributes (see Fig. 3.) to apply the rule to emails sent by members of specific departments, offices, or people living in specific cities, etc. Read on to learn more about this filter.
  • Email addresses – here you can enter one or more email addresses (from your organization), separated by semicolons. This option is useful for setting up email signatures for alias addresses, as the user/group pickers (see Fig. 2.) only show primary email addresses. See this article to find out how to add different signatures when sending emails from aliases / other domains associated with your tenant.

Important

Remember to add at least one user in the conditions field (the top list). If you leave it empty, signatures will be added to all licensed CodeTwo users. The program will notify you about that and automatically add All senders to the top list when you submit your changes via the Save & Publish button.

If you would like to create a rule but don’t want to apply it to any users yet, you can click the Save button instead.

You can only select users or groups specified in the scope of licensed users to set up conditions/exceptions of your rules. For example, if you select the All senders condition, it will apply to the group of users selected in the scope of licensed users. Learn more about this scope

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 (Fig. 3.) will list users/groups with email addresses from all these domains.

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

Using the Azure AD filter

In the example shown in Fig. 3., we configured the rule to add signatures to emails sent by our IT team, excluding the managers.

Using the Azure AD filter to define both conditions and exceptions in the Senders step.
Fig. 3. Using the Azure AD filter to define both conditions and exceptions in the Senders step.

The software knows when to add signatures because we added an Azure Active Directory filter condition, which checks if the sender's Department field in Entra ID (Azure AD) is equal to IT – see Fig. 4. for detailed configuration. In a similar way, an exception to the rule was defined: if the sender's Title in Entra ID contains the value Manager, the rule will not be triggered.

Azure Active Directory filter options.
Fig. 4. The Azure Active Directory filter options.

User AD field (see Fig. 4.) includes common Entra ID attributes such as First/Last Name, Company, Department, E-mail or Phone, Exchange Online custom attributesattributes synced from on-prem Exchange Server, as well as CodeTwo custom attributes.

Recipients

The Recipients step (Fig. 5.) 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. 5. The Recipients step. Here, the rule applies to emails sent to anyone.

Important

  1. 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.
  2. 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. 6.) 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. 6. – 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. 6. 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. 7.) you can define where to search for the phrase and decide if the program should remove it from the message.

Keyword configuration options.
Fig. 7. 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. 7.).

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. 8.), 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. 8.). 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. 8. 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. 10.). 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. 9.):

  • 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. 9. 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. 10.), 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. 10. 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. 10.). 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. 11.):

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

Note: This option is deprecated and will be removed soon.

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. 11. 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. 12.). 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. 12. 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. 13.).

Configuration of the Recipients condition: here, the rule applies to external emails only.
Fig. 13. 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. 14. 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. 14. 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, 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. 15. 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. 15. 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. 16.). The wildcard (*) character ensures that all email addresses ending with .ca will trigger our signature rule.

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

How are signatures added to emails 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.

How are signatures added to emails sent from aliases?

If you set up rules for primary email addresses only, your users will get the same signature no matter if they use their primary address or an alias to send emails (this is because aliases are associated with the primary email address in Microsoft 365). To add signatures to alias addresses, you need to set up a dedicated rule for them.

Here's how it works if you set up separate rules for alias addresses:

  • Cloud (server-side) signatures – to ensure users get the correct signature when sending an email from alias, you need to:
    • place the rules configured for alias addresses at the top of your cloud (server-side) signatures list, above the rules configured for primary addresses,
      OR
    • add alias addresses as exceptions to the rules configured for your primary email addresses.
  • Outlook (client-side) rules – when a user selects an alias address in the From field in Outlook, the signature configured for that alias will become available in the add-in pane. The user will need to manually add it to email, as described here. To enable this, ensure this add-in setting is turned on for your tenant.

Learn more about adding different signatures to emails sent from alias addresses

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

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

You can also use the signature rules tester to see what signature rule is triggered when sending an email to a specific recipient.

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.

You can also use the signature rules tester to see what signature rule is triggered when sending an email to a specific recipient.

Can I convert cloud (server-side) email signature rules to Outlook (client-side) signature rules and vice versa?

Yes. See this article to learn how to do it automatically.

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?