Rules, Connectors, and Groups
I’ve finished project setup for Domain Rewrite, what’s next?
After Domain Rewrite is configured in your project, each tenant will have a series of configurations automatically deployed through our orchestration engine. The following FAQs will help you get acquainted with the Domain Rewrite configuration components.
What is setup when I enable Domain Rewrite?
When Domain Rewrite is enabled, the following configuration items are created and managed. If Domain Rewrite is disabled, the same configurations will be removed.
- Exchange Online Transport Rules to redirect mail flow for Domain Rewrite eligible users
- Exchange Online Connectors to manage encrypted mail flow between Domain Rewrite and Exchange Online
- Mail-Enabled Groups to managed user’s eligibility for Domain Rewrite
All configurations can be reviewed for any tenant from the Exchange Online portal. You may also view all configurations using PowerShell.
How can I confirm everything was created?
You may verify the configurations from the Microsoft 365 admin portal or by using PowerShell.
To verify by portal, simply login to the Exchange Online Admin Portal. Then navigate to Mail Flow. Under Mail Flow you will find the rules and connectors. To view the groups, navigate to recipients then groups.
The simplest way is to use a PowerShell query to get a list of all rules, connectors and groups. Follow these easy steps to do just that.
- Launch PowerShell.
Connect to your tenant, if you don’t know how, here is a quick article from MS:
Once authenticated, run these example commands:
Get-TransportRule BT-* -ErrorAction SilentlyContinue | select @{Name='Identity'; Expression={'Rule: '+$_.Identity }}
Get-InboundConnector BT-* -ErrorAction SilentlyContinue | select @{Name='Identity'; Expression={'Inbound: '+$_.Identity }}
Get-OutboundConnector BT-* -ErrorAction SilentlyContinue |select @{Name='Identity'; Expression={'Outbound: '+$_.Identity }}
Get-DistributionGroup BT-* -ErrorAction SilentlyContinue | select @{Name='Identity'; Expression={'Group: '+$_.Identity }}
- Repeat these steps for each tenant.
How are Transport Rules & Send Connectors used?
Exchange Online transport rules and send connectors are the way in which mail is routed from an Microsoft 365 tenant to On Demand Migration Domain Rewrite Service. Transport Rules examine a message to determine if it should be rewritten and the connectors route the message to On Demand Migration Domain Rewrite Service. This ensures that only messages that need to be rewritten are routed to Domain Rewrite and messages that do not are immediately sent to the recipients.
There are 3 categories of transport rules. The following section outlines each category and describes the naming convention used for the rules.
Sorting Rules
For outbound messages, a sorting rule examines each recipient on an SMTP message and adds an SMTP header to identify if the recipient is internal or external.
- BT-IntegrationPro-Out-S-Internet – rule for external recipients.
- BT-IntegrationPro-Out-S-[Guid]-[#] – rules for internal recipients in target tenant [Guid] where [#] indicates a block of SMTP domains. E.g. BT-IntegrationPro-Out-S-15d82781-e5e8-4691-a77f-0f5fb10b6482-1
From, To, CC Rules
For outbound messages, these rules determine if any of the From, To or CC addresses on an SMTP message include an internal or external recipient that should be rewritten and updates the SMTP header added above appropriately.
- BT-IntegrationPro-Out-[From/ToCc] – rules for external recipients.
- BT-IntegrationPro-Out-[Guid]-[From/ToCc] – rules for internal recipients in target tenant [Guid]. E.g. BT-IntegrationPro-Out-15d82781-e5e8-4691-a77f-0f5fb10b6482-From.
Inbound Rules
The outbound rules ensure that Microsoft 365 routes only the messages that need to be rewritten to On Demand Migration Domain Rewrite Service. The inbound rules have two functions.
BT-IntegrationPro-In - rule for messages returning from On Demand Migration Domain Rewrite Service.
After a message is rewritten it is returned to the original tenant for delivery to external recipients.
This rule removes the header added by the outbound rules so that a message is only processed by On Demand Migration Domain Rewrite Service once.
BT-IntegrationPro-In-DKIM - rule for messages returning from On Demand Migration Domain Rewrite Service.
When an external recipient replies to an ERS user, the message is rewritten back to the original domain. After which, the message is redirected to the original tenant.
This rule removes the secret key added to the header by the sending tenant to ensure the message was securely delivered before and after being rewritten.
How are Connectors used?
Domain Rewrite adds an inbound and outbound connector to all Microsoft 365 tenants defined on a project. The purpose of these connectors is to ensure mail flow from an Microsoft 365 tenant to Domain Rewrite is encrypted with the assigned TLS/SSL certificate. This outbound connector contains the FQDN of the Domain Rewrite ERS Relay used to receive mail for the tenant. Some versions of ERS include connectors for each Client/Project combination.
- BT-IntegrationPro-In – inbound connector
- BT-IntegrationPro-Out – outbound connector
How are groups used?
When an Email Address Rewrite mode is selected for a user, the user is added to either the ERS Day One group (Rewrite with Target Address) or the ERS Day Two group (Rewrite with Source Address).
The ERS day One and day Two groups are cloud-only Exchange Online distribution groups. ERS Day One is used to control which (not migrated) source users should be presented to external recipients using their target address. ERS Day Two is used to control which (migrated) target users should be presented to external recipients with their source address. Some versions of ERS include groups for each Client/Project combination.
Administration Groups
Domain Rewrite automatically adds the following two (2) groups in the source tenant(s) of a project. These groups are managed by the administrator(s) of the tenant.
- BT-IntegrationPro-[DayOne/DayTwo] – day one or day two mailbox users. E.g. BT-IntegrationPro-DayOne.
Internal Groups
Domain Rewrite automatically adds several groups in the source and target tenant(s) for internal use. These groups should not be changed or deleted by administrators and are managed by Domain Rewrite.
Source Tenants – Domain Rewrite adds the following groups in the source tenant(s) of a project.
- BT-IntegrationPro-[DayOne/DayTwo]-[Guid] – target addresses (contacts) of day one or day two users in target tenant [Guid]. E.g. BT-IntegrationPro-DayOne-15d82781-e5e8-4691-a77f-0f5fb10b6482
Target Tenants – Domain Rewrite creates the following groups in the target tenant(s) of a proj
- BT-IntegrationPro-[DayOne/DayTwo] – source addresses (contacts) of day one or day two users from all source tenants. E.g. BT-IntegrationPro-DayOne.
- BT-IntegrationPro-[DayOne/DayTwo]-[Guid] – source addresses (contacts) of day one or day two users from source tenant [Guid]. E.g. BT-IntegrationPro-DayOne-15d82781-e5e8-4691-a77f-0f5fb10b6482.
- BT-IntegrationPro-NC-[Guid] – source addresses (contacts) of users from source tenant [Guid] that have not been cutover. E.g. BT-IntegrationPro-NC-15d82781-e5e8-4691-a77f-0f5fb10b6482.
How does Mail Flow work with Domain Rewrite?
Rewrite with Target Address – Outbound Mail Flow
When a user sends an email as user@source.com, the Transport Rules in the Source Tenant check whether the message is in scope for Domain Rewrite
At least one external recipient in “To” or “Cc”
Sender and/or at least one recipient in “To” or “Cc” is Domain Rewrite Enabled
If the message is in scope for Domain Rewrite and there are multiple internal and external recipients, the message will be bifurcated and:
Copy of the message sent to external recipient will be securely redirected to the Quest Rewrite Service using the Outbound Connector in the Source Tenant.
Copy of the message sent to internal recipient is delivered by Exchange Online at the Source tenant with unchanged addresses.
When the Quest Rewrite Service receives the message from user@source.com, it processes it by rewriting @source.com to @target.com for every user that has Domain Rewrite enabled. The addresses in "From", "To", and "Cc" of the email message are rewritten for all external recipients.
The Quest Rewrite Service signs the message and securely (via the certificate uploaded during project setup) redirects it back to the Source Tenant using the Inbound Connector.
Exchange Online at the Source sends the message to external recipients as if it was sent by user@target.com, and all addresses of message recipients in "To" and "Cc" that have Domain Rewrite enabled appear as @target.com for external recipients
Rewrite with Target Address – Inbound Mail Flow
External recipient is not aware about @source.com and replies (or create a new email) to user@target.com
When the reply or a new mail arrives to the Target mail domain, the Transport Rules in the Target Tenant check whether any recipients in the “To” or “Cc” are in scope for Domain Rewrite
If the message is in scope for Domain Rewrite, it is securely redirected to the Quest Rewrite Service using the Outbound Connector in the Target Tenant
If the message is in scope for Domain Rewrite and there are multiple internal (recipients in the target tenant) and external recipients (recipients in the source tenant with Rewrite Service enabled), the message will be bifurcated and:
Copy of the message sent to external recipient (recipients in the source tenant with Rewrite Service enabled) will be securely redirected to the Quest Rewrite Service using the Outbound Connector in the Source Tenant.
Copy of the message sent to internal recipient is delivered by Exchange Online at the target tenant with unchanged addresses.
When the Quest Rewrite Service receives the message addressed to user@target.com, it processes it by rewriting @target.com back to @source.com for every user that has Domain Rewrite enabled
The Quest Rewrite Service signs the message and securely (via the certificate uploaded during project setup) redirects it back to the Target Tenant using the Inbound Connector
Exchange Online at the Target forwards the message to the Source
Source recipient gets the message as if it was addressed to user@source.com
Rewrite with Source Address – Outbound Mail Flow
When a user sends an email as user@target.com, the Transport Rules in the Target Tenant check whether the message is in scope for Domain Rewrite
At least one external recipient in “To” or “Cc”
Sender and/or at least one recipient in “To” or “Cc” is Domain Rewrite Enabled
If the message is in scope for Domain Rewrite, it is securely redirected to the Quest Rewrite Service using the Outbound Connector in the Target Tenant
If the message is in scope for Domain Rewrite and there are multiple internal (recipients in the target tenant) and external recipients, the message will be bifurcated and:
Copy of the message sent to external recipient will be securely redirected to the Quest Rewrite Service using the Outbound Connector in the Target Tenant.
Copy of the message sent to internal recipient is delivered by Exchange Online at the target tenant with unchanged addresses.
When the Quest Rewrite Service receives the message from user@target.com, it processes it by rewriting @target.com to @source.com for every user that has Domain Rewrite enabled. The addresses in "From", "To", and "Cc" of the email message are rewritten for all external recipients
The Quest Rewrite Service signs the message and securely (via the certificate uploaded during project setup) redirects it back to the Target Tenant using the Inbound Connector
Exchange Online at the Target sends the message to external recipients as if it was sent by user@source.com, and all addresses of message recipients in "To" and "Cc" that have Domain Rewrite enabled appear as @source.com for external recipients
Rewrite with Source Address – Inbound Mail Flow
External recipient is not aware about @target.com and replies (or create a new email) to user@source.com
When the reply or a new mail arrives to the Source mail domain, the Transport Rules in the Source Tenant check whether any recipients in the “To” or “Cc” are in scope for Domain Rewrite
If the message is in scope for Domain Rewrite, it is securely redirected to the Quest Rewrite Service using the Outbound Connector in the Source Tenant
If the message is in scope for Domain Rewrite and there are multiple internal (recipients in the source tenant) and external recipients (recipients in the target tenant with Rewrite Service enabled), the message will be bifurcated and:
Copy of the message sent to external recipient (recipients in the target tenant with Rewrite Service enabled) will be securely redirected to the Quest Rewrite Service using the Outbound Connector in the Source Tenant.
Copy of the message sent to internal recipient is delivered by Exchange Online at the source tenant with unchanged addresses.
When the Quest Rewrite Service receives the message addressed to user@source.com, it processes it by rewriting @source.com back to @target.com for every user that has Domain Rewrite enabled
The Quest Rewrite Service signs the message and securely (via the certificate uploaded during project setup) redirects it back to the Source Tenant using the Inbound Connector
Exchange Online at the Source forwards the message to the Target
Target recipient gets the message as if it was addressed to user@target.com
When is it safe to remove Domain Rewrite ERS configurations?
You may disable Domain Rewrite when production services are no longer required. Upon disabling, the related configurations will automatically be removed.
DMARC
What is DMARC?
DMARC is an email authentication protocol. It is designed to give email domain owners the ability to protect their domain from unauthorized use, commonly known as email spoofing. Wikipedia
Is DMARC supported with Email Rewrite Services (ERS)?
Yes, DMARC is fully supported in all ERS mail flow scenarios. Either natively or through product supported methods.
| ERS MAIL FLOW | DMARC |
|---|---|
| Mail Sent to External Recipients | Natively Supported |
| Mail Sent to Cross-Tenant Recipients | Natively Supported |
| Mail Received from External Recipients | Product Supported |
| Mail Received from Cross-Tenant Recipients | Natively Supported |
Table 1: Supported DMARC Mail Flow Scenarios
What does product supported mean?
Product supported means that Domain Rewrite maintains domain authenticity, through internal methods to ensure the message received by the originating Microsoft 365 tenant was DMARC compliant before it is rewritten and redirected to the destination Microsoft 365 tenant.
In other words, Domain Rewrite ERS will verify and sign the rewritten email with a secret key so that when it is received by the destination Microsoft 365 tenant, transport rules may verify its authenticity then deliver to the intended user.
What does natively supported mean?
Natively supported means that DKIM domain alignment is achieved when an ERS rewritten email is sent or received. Therefore, DMARC will pass when received without interruption by the intended recipient domain.
What is required for DMARC to function with ERS?
DMARC is supported natively for all ERS users when sending mail outbound to an external domain recipient or across to a neighboring Microsoft 365 tenant. Simply choose the accepted domains in use during your project setup of the DKIM signatures. This will ensure the required domains are signed to achieve domain alignment and pass DMARC. The project wizard will guide you through the process.
Why are reply emails sent to the Junk folder?
When an ERS user receives a reply email from an external user, it is rewritten back to the original email address. This disrupts domain alignment and Exchange Online Protection by default will mark such emails as SPAM, delivering it to the end-user’s junk email folder.
How do I prevent ERS reply emails from being marked as SPAM?
It’s very easy to do. Simply setup a new action in one of the ERS transport rules. When ERS is deployed in each tenant environment, transport rules are created to manage to flow of mail for ERS users only.
This new action will allow ERS validated emails only to by-pass SPAM and deliver the message directly to the end-user’s inbox.
How do I setup an action in my transport rule to prevent ERS reply mail going to Junk?
During this deployment, a rule named “BT-IntegrationPro-In-DKIM” is created and configured in each Microsoft 365 tenant in scope for Email Rewrite Services.
Follow these steps to setup a new action in the ERS Transport Rule using the Exchange Admin Center.
- Login into Exchange Admin Center with your Exchange Online Administrator or higher role account.
- Navigate to Mail Flow, Rules.
- Locate the rule named, BT-IntegrationPro-In-DKIM.
- Click Edit.
- Click Add Action.
- From the Do the following… field select, Modify the Message Properties.
- Select set the spam confidence level (SCL).
- Select the specify SCL to be Bypass spam filtering.
- Select OK.
- Select Save.
PowerShell may also be used to modify the rule. Here is an example.
Set-TransportRule "BT-IntegrationPro-In-Dkim" -SetSCL –1
See the Set-TransportRule for more information.
May I set additional actions to the rule such as add a disclaimer or append the subject?
Yes, additional actions are supported on this rule. For example, it may be desired that a disclaimer be added to these ERS emails informing the recipient they are safe and were rewritten by our authorized service provider. Another common example is to prepend to the subject line that this is an ERS email. This provides additional awareness to the end-user users receiving and sending these types of email.
If additional actions are added to this rule, please validate the changes do not impact any functionality. And do not modify the rule order or add rules that reorder the ERS rules.
If this rule is deleted will it be recreated automatically?
Yes, Domain Rewrite health monitoring will recreate any rules that it created for ERS. If ERS is disabled in your project, all rules will automatically be removed from all tenant environments.
Will the rule be recreated with my additional actions?
No, any additional actions you may have added to the rule must be added again to the newly created rule.
How do I make a back-up of my rules with my custom actions?
You may easily use Exchange Online PowerShell to export your rules to a CSV file as a back-up. For example, here is a script that will export all rules created by Domain Rewrite during the ERS deployment.
Get-TransportRule BT-Integration* | export-csv C:\Users\%USERNAME%\Downloads\BT-Integration_TransportRules.csv
Domain Move
This user guide covers the steps required to configure and perform a Domain Move. The Domain Move Quick Start Guide summarizes these steps and addresses some frequently asked questions.
Platform Requirements
Supported Environment Deployments
Domain move between two Microsoft 365 tenants cloud-only or hybrid tenants is supported.
Exchange Hybrid Deployments
Domain Move currently provides limited support for Exchange hybrid deployments. Environments with an Exchange Server 2013 (or later) hybrid deployment are supported, but with the following limits on functionality:
- Support for the Email Relay Service is limited to mail flow configurations that use Microsoft 365 for message ingress and egress. Centralized mail flow configurations that use the on-premises Exchange environment for inbound and outbound message delivery may require custom configuration with Support.
Application Service Account Requirements
To set up a Domain Move project the following must be provided by the owner of each of the associated Microsoft 365 tenants.
- Application Account: One (1) dedicated and licensed application service account to grant permissions and automatically orchestrate various activities within the project. This account must have the Exchange Online plan assigned to facilitate automatic email communications to end-users and project administrators during cutover activities, otherwise all communications will appear to be sent from the PowerShell account.
- Roles: The Global Administrator role is required for connecting environments for projects and workflows to grant permissions and to create a PowerShell account within each configured tenant.
- Licenses: At least one (1) E1 or above license must be available to be assigned to the PowerShell account for Migration/Integration Projects.
What are the minimum administrator roles required to manage a project?
At a minimum, after project set up the following Microsoft 365 Role is required to automatically manage various aspects of your project.
- Global Administrator Role
Modern Authentication Requirements
Domain Move projects take advantage of Modern Authentication to help manage your projects. Modern Authentication is the default behavior for all Microsoft 365 tenants. Unless it was disabled, no action is required. However, we recommend the following configuration parameter is validated prior to deployment.
Get-OrganizationConfig | Format-Table Name,OAuth* -Auto
If Modern Authentication is disabled it must be enabled prior to any migration activities can proceed. To enable Modern Authentication for Exchange Online, run this command under the correct authority.
Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true
Here is some additional information about how to Enable modern authentication in Exchange Online.
PowerShell
The following accounts are required:
- Account: One Cloud-only account will automatically be created during project setup.
- Microsoft 365 Administrator Roles: Automatically assigned the Exchange and SharePoint Administrator roles.
- Microsoft 365 License Requirements: Automatically assigned one available license (E1 minimum) for destination tenants.
- The accounts must be excluded from MFA requirements.
Important Note: This account will automatically be assigned the Global Administrator role at the start of a Domain Cutover event, where more authority is required to complete the process.