Does Domain Rewrite modify messages sent between the Source and Target tenants?
The expected rewrite behavior is based on which rewrite mode is enabled – Rewrite with Target Address or Rewrite with Source Address. Both modes rewrite messages sent to external users that do not belong to either tenant and do not rewrite messages sent to internal users in the sending user’s tenant. For messages sent between the source and target tenants, the behavior is as follows:
Rewrite with Target Address - Outbound
Messages sent from a rewrite-enabled user in the source tenant to a user in the target tenant will be rewritten just like messages sent to fully external recipients. If you do not want these messages rewritten, you can add an exclusion to the rule “BT-IntegrationPro-Out-S-Internet” for the domain(s) in the target tenant.
Rewrite with Source Address - Outbound
Messages sent from a rewrite-enabled user in the target tenant to a user in the source tenant will not be rewritten. If you want those messages rewritten, you must create contacts in the target tenant for each source user and then add the contacts to the distribution list BT-IntegrationPro-{Source Tenant GUID}.
How can I check if my email has been processed by Domain Rewrite Service?
Administrators can confirm if the message has been processed by Domain Rewrite Service by submitting a message trace in Microsoft 365 admin portal or review the message header.
How can administrators confirm Domain Rewrite service has been configured for my tenants?
How can administrators confirm Domain Rewrite service has been configured for my tenants?
Administrators may verify the configurations from the Microsoft 365 Exchange Online Administrator Portal.
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 like the ones show below.
How are Transport Rules & Send Connectors used?
How are Transport Rules & Send Connectors used?
Exchange Online transport rules and send connectors are used to route mail 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 On Demand Migration Domain Rewrite Service and messages that do not are immediately sent to the recipients.
|
|
important: Support for the Domain Rewrite 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. |
There are 3 categories of transport rules. The following section outlines each category and describes the naming convention used for the rules.
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 update the SMTP header added above appropriately.
- Quest-CxxxPxxx-Out-[From/ToCc] - rules for external recipients.
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.
- Quest-CxxxPxxx-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.
- Quest-CxxxPxxx-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.
