Address Groups
Address groups are simply named groups of one or more, up to 1000, email addresses. Address groups are used often in policies, and can be used for the following reasons:
- To filter a policy based on a group of message recipients. When you specify an address group in the Recipient field of a policy, then the policy will only match if the message recipient is in the address group. Using an address group in the Recipient field never affects message scoring.
- To identify Imposter Target Address, enter the Address Group(s) containing individuals within your organization for whom you want the policy to detect impostors in the Imposter Target Address Group field of a policy. The condition will look for the address group members' names in the Display Name (i.e. Friendly From) of the Address Group. If a given Address does not use a Display Name, the condition evaluates the local part of the email address in the address group to see if it matches the email address in the Imposter Target Address.
When you create a new organization, three address groups are pre-created for you:
- Executives (automatically associated with the Executive Imposters policy, see Default Policies for details)
- C-Level Executives (automatically associated with the C-Level Imposters and Suspicious Messages to C-Level policies, see Default Policies for details)
- Top Partners and Vendors (automatically populated with up to 1000 email addresses from domains tagged Partner or Vendor, see Domain Tags for details)
One of the first tasks you should do when setting up a new organization is to populate these address groups with your executive and C-level executive email addresses, and then configure the associated policies.
The Top Partners and Vendors address group is updated automatically on a weekly basis. Cloud Email Protection detects individuals at partners and vendors (from domains tagged as Partner, see Domain Tags for details) who regularly communicate with employees at your organization and populates the Top Partners and Vendors address group with up to 1000 of these individuals.
For other address groups, you can create them with your own individual email addresses, in which case you make any address group changes manually, or you can create them by synchronizing an Azure AD group, in which case the address group is updated when changes are made to the Azure AD group. See Create an Address Group and Microsoft Entra ID (formerly Azure AD) Synchronization With Address Groups for more information.
TIP: If you want to create a large address group and do not have Microsoft Entra ID (formerly Azure AD) available to you, Fortra Cloud Email Protection can also upload a list of comma-separated value (CSV) records to create address groups. Contact your support representative for details.
Address Group Exceptions
Addresses in the exception list are for specifying "known good" email addresses of the people in the address group, such as or personal email addresses, to avoid false positives.
For example, suppose that legitimate messages using your company's executives' names are sent from the address <yourco_announce@example.com>. You can add that email address to the exceptions list for the Executives address group. Now when an authentic message from <yourco_announce@example.com> is detected, it will not fire an alert based on this address group.
Addresses in the exceptions list are never tagged as impostors unless the message itself is inauthentic, and they are only considered when the address group is referenced by the From and Reply-To conditions in a policy.
You can add addresses such as messenger@webex.com or reply@chatter.salesforce.com so that when a user in your Address Group is spoofed legitimately, such as "John Doe <messenger@webex.com>” or "John Doe <reply@chatter.salesforce.com>” the condition will not match.
You can also add personal addresses such as "johndoe@gmail.com," which may share the Friendly From of addresses above.
Some email services make use of “+” addressing, per the sieve filtering standard. In these cases the local part of an email address will vary with a random text string after the “+” in the address, which can cause problems for setting an exception in an address group. For example "John Doe <notifications+2hef98h2uibf8h@yammer.com>." In these cases, the address group matching will automatically ignore the '+' and all characters between the “+” and the “@.” So you could add just "notifications@yammer.com" to the exceptions list to ignore this so it will not match on the John Doe display name.
Some messages are automatically excepted from address group display name matching by Fortra Cloud Email Protection. For example, messages that pass authentication and come from a domain tagged as “internal,” “partner,” or “service” will not be called an address group match.
Address Group Examples
The section shows how address groups and policies work together.
Address Group In the Recipient Field of a Policy
When an address group is referenced in the Recipient field of a policy, it is simply a recipient filter for the policy. The policy will apply only when the recipient address is in the address group.
For example, your Genius address group now contains Albert Einstein <aeinstein@genius.com> and Stephen Hawking <shawking@genius.com>. If you now create a policy called Untrusted messages sent to geniuses and put the Genius address group in the Recipient field of the policy, that policy will only match on messages that meet the trust criteria and have aeinstein@genius.com or shawking@genius.com as the recipient. Exceptions do not apply to the use of address groups in the Recipient field.