Domain Rewrite
What is Domain Rewrite?
For mergers and acquisitions, email rewriting allows a company to present a unified email address to the outside world before and after the user’s mailbox has been migrated. Domain Rewrite is a key requirement for any organization utilizing more than one Microsoft 365 tenant to service their end-users.
Domain Rewrite substitutes the From, To, and Cc addresses in the outgoing and incoming emails with the addresses from the target or source tenant depending on the selected domain rewriting scenario. Emails are automatically redirected to the source or target mailbox, and you can specify the users processed by the service. For example, you can turn on the service for only Sales and Marketing team members.
Domain Rewrite will take all the necessary steps to create this coexistence space in the Exchange online environment, including creating and managing all the required connectors, mail flow rules, mail-enabled users, and groups in source and target environments.
Domain Rewrite supports the following scenarios:
Replace senders’ address with the target primary email address.
Replace senders’ address with the source primary email address.
This user guide covers the steps required to configure and enable Domain Rewrite. The Domain Rewrite Quick Start Guide summarizes these steps and addresses some frequently asked questions.
How do I enable domain rewrite service for users using Domain Rewrite?
If the Rewrite With Target Address mode is selected, their outbound email messages will be intercepted by Domain Rewrite. Domain Rewrite will rewrite the message header with the target tenant’s SMTP Accepted Domain information. To the outside world, it looks as if the sender was already using a mailbox in the target tenant.
This scenario commonly applies to users from the Source tenant that need to communicate with external recipients from the name of the Target organization. It usually happens when the mail migration is not yet finished, but you want to use the consistent branding.
Rewrite With Target Address
To enable a user for Rewrite with Target Address, select the matched user, click Email Rewrite from the action menu, and then click Apply Action. Select Rewrite With Target Address mode, select either the Prepare User(s) for Address Rewrite or Enable User(s) for Address Rewrite option, and then click Submit.
The Prepare User(s) for Address Rewrite option sets forwarding but does not enable rewrite. If an account is mailbox-enabled or a cloud-only MEU, forwarding is set on the tenant object. If an account is a hybrid MEU, forwarding is set on the AD object and the changes must replicate to the tenant via Entra Connect. This option is useful for confirming all permissions and access is working prior to enabling rewrite. Performing Prepare ahead of time reduces the steps and duration of enabling address rewrite later.
The Enable User(s) for Address Rewrite option sets forwarding, waits for Microsoft replication, and then begins the process to enable rewrite.
When the Skip Mail Forwarding Configuration option is checked, the rewrite enablement process begins without setting forwarding.
Rewrite With Source Address
If the Rewrite With Source Address mode is selected, any email sent from that user will appear as if they are still coming from the source mailbox’s primary SMTP address. During a merger or acquisition project, this allows a company to hide the migration process from the outside world, until all users have been migrated and the Accepted Domains can be migrated themselves.
This scenario commonly applies to migrated users in the Target tenant that still need to communicate with external recipients from the name of the Source organization. It usually happens when you need to keep the original brand while merging all accounts in the Target Tenant.
To enable a user for Rewrite with Target Address, select the matched user, click Email Rewrite from the action menu, and then click Apply Action. Select the Rewrite With Source Address mode, select either the Prepare User(s) for Address Rewrite or Enable User(s) for Address Rewrite option, and then click Submit.
The Prepare User(s) for Address Rewrite option sets forwarding but does not enable rewrite. If an account is mailbox-enabled or a cloud-only MEU, forwarding is set on the tenant object. If an account is a hybrid MEU, forwarding is set on the AD object and the changes must replicate to the tenant via Entra Connect. This option is useful for confirming all permissions and access is working prior to enabling rewrite. Performing Prepare ahead of time reduces the steps and duration of enabling address rewrite later.
The Enable User(s) for Address Rewrite option sets forwarding, waits for Microsoft replication, and then begins the process to enable rewrite.
When the Skip Mail Forwarding Configuration option is checked, the rewrite enablement process begins without setting forwarding.
Does Domain Rewrite rewrite the address when a “Send-on-Behalf” delegate sends a message for an enabled Domain Rewrite user’s mailbox?
Yes. Domain Rewrite supports rewriting the address of the mailbox owner and/or delegate. If Domain Rewrite is enabled for both, both addresses are rewritten. If Domain Rewrite is enabled for the mailbox owner, then only their address will be rewritten.
Domain Rewrite Requirements
Domain Rewrite (Email Rewrite)
To deploy Domain Rewrite between tenants the following will need to be ready prior to the configuration of the service.
Domain Rewrite Deployment Checklist:
The following checklist provides a quick reference to the items or decisions required to begin configuration of Domain Rewrite.
- Procure one (1) SSL single domain certificate for each tenant environment using one (1) of the accepted domains.
- The password associated with the SSL certificate will be required when uploading each certificate.
- Choose which domains will particulate in Domain Rewrite.
- Deploy DKIM DNS TXT records for each tenant environment during project set up.
SSL Certificates
To successfully configure the Email Rewrite Service, a valid SSL certificate must be procured for each source and target tenant. Each certificate must contain a single accepted domain, one (1) for each tenant. The selected certificate cannot contain subject alternative names (SAN). The common name (Subject Name) must match one (1) of the Exchange Online accepted domains configured within the tenant.
This certificate is utilized to secure the Exchange Online connectors over TLS that will be used to transfer message between the Email Rewrite service and each tenant. The new certificates will be uploaded to the project using a PFX formatted certificate. PFX files contain the public key file (SSL Certificate file) and the associated private key file (password).
The requirements for the certificate are as follows: (Names are for example purposes only.)
- Common Name: contoso.com
- Cryptographic service provider: Microsoft RSA SChannel Cryptographic Provider
- Bit length: 2048 or higher
- Must be valid for Server Authentication and Client Authentication.
- Must be signed by a trusted public root CA.
- Must contain a private key (password).
- Must not expire before the end of the project.
- Must have a Friendly Name defined.
DKIM (Email Signatures)
Domain Rewrite ensures email authenticity after rewrites by signing messages using a Domain Keys Identified Mail (DKIM) certificate. To properly sign emails, a DKIM certificate will automatically be generated and assigned to each participating domain(s) in the source and target tenants.
Each participating Accepted SMTP Domain from the source and target tenants will require a DKIM TXT record be created in your public DNS. During project configuration, Domain Rewrite will generate all the required parameters to easily and quickly publish your TXT records for each domain.
Each participating Accepted SMTP Domain from the source and target tenants will require to enable DKIM at the tenant level, additional information can be found at this Microsoft Link How to use DKIM for email in your custom domain - Office 365 | Microsoft Learn
DNS
To complete set up of Domain Rewrite the DKIM/Email Signatures DNS txt record must be published in the source and target public DNS. Once the records are published, Domain Rewrite will automatically verify the records. Once verified you will be able to complete the project’s Domain Rewrite configurations.
The following is an example of the TXT record parameters required to publish the record. Your key will be unique to your project.
- Name: selector1._domainkey
- Type: TXT
- TTL: 10
- Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQCmvFUb+TkozfdnA0dA3AHOwAUYdfNVlBkR72+gqp2GxwK8yYPRI/E1/zp5DDZ/i8epWTR/F9u4jDJxjLqYF9d8m7qhJFjXxzWH2TbMQC4VgUfRtq5WAJmPUrCBdxxvMoOAKQ+aYagtXpv9HlH7PAKXsUFbqGGZ0GQFSvM0GKC7hQIZZQAB
SPF
When planning the deployment of Domain Rewrite Service we recommend the following regarding Sender Policy Framework (SPF) records:
Update your existing SPF record to include the On Demand Migration Domain Rewrite list of acceptable domains. This will prevent any hard failures when routing mail through the Rewrite Relay Service.
Include the following domains with your SPF record from all source and target domains participating in Domain Rewrite:
spf.odmad.quest-on-demand.com
spf.us.odmad.quest-on-demand.com
spf.ca.odmad.quest-on-demand.com
spf.eu.odmad.quest-on-demand.com
spf.uk.odmad.quest-on-demand.com
spf.au.odmad.quest-on-demand.com
DMARC
If your organization utilizes Domain-based Message Authentication, Reporting and Conformance (DMARC) to prevent email spoofing, then Domain Rewrite is DMARC ready.
There are no additional requirements to support DMARC with Domain Rewrite, however it is highly recommended that the following related topics be reviewed prior to execution.
DKIM
What is DKIM?
DomainKeys Identified Mail (DKIM) is an email authentication method designed to detect forged sender addresses in emails, a technique often used in phishing and email spam. DKIM allows the receiver to check that an email claimed to have come from a specific domain was indeed authorized by the owner of that domain. Wikipedia
Why is DKIM required for Domain Rewrite (ERS)?
A DKIM or commonly known as an Email Signature, is required for Email Rewrite Services (ERS) to ensure Domain Alignment and Authenticity. Without the proper email signature, DMARC would fail if quarantine or reject are enabled. For more information about DMARC and ERS, see this article.
When is DKIM required for Domain Rewrite (ERS)?
When emails are rewritten by ERS, receiving servers must be able to validate and trust the authenticity of the sender. To do this ERS will sign each email with a DKIM signature. This signature contains a public and private key that must be compared using public DNS to verify ownership of the domain(s).
By default, all your accepted domains are eligible for a DKIM signature. If you wish to exclude a domain from ERS because you know it is not-in-use, then you may uncheck the domain to exclude it. Microsoft domains are automatically excluded.
When do I choose my DKIM domains for ERS?
During project setup of the ERS components.
The project wizard will walk you through the configurations of ERS. During this process you will be asked to choose which domains will require email signatures. It is recommended any accepted domain being used by any mail-enabled object within your tenant environments be published. If the accepted domain is not in use by anyone, then it is not required. If in doubt, enable it.
How do I publish my DKIM DNS records?
It’s simple if you have access to your public DNS. In most cases, even as IT administrators we may not have direct access to update public DNS. In those cases, you’ll need to submit a change control to publish DNS TXT records for all the accepted domains. And each record must contain the public key provided in the “Copy DNS Information” action in the project wizard.
On Demand Migration will present a unique public key associated with the domains. That key is to be published as a DNS TXT record for the selected domain. Here is an example of such a record.
Example TXT Record:
Name: selector1._domainkey.contoso.com
Type: TXT
Value: v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUXA4GNADCBiQKBgQC0uekhrGKBUmlvPXcy2XxEBG 7Hn+64l505xl0vwk3cnHwWaVw1LTFcsFxUCf2tXpNE02ap5EhCCTjGGOyEJ/ZX1ScptyDP3 X/eJDn4jq5sQQruK3F9KdU9kLTmkALK+ySz+lpX40DLXWw2BauOEzpVD65XZUwiN5DJUc 37/RcozRwIDAQAB
The Project implementer will copy this information and provide it to the team that manages DNS for this domain. On Demand Migration will immediately begin monitoring DNS for this record. Once the DNS TXT record has been validated by On Demand Migration, the Project implementer may select the desired domains to complete the setup.
TLS/SSL
What is TLS?
Transport Layer Security (TLS), and its now-deprecated predecessor, Secure Sockets Layer, are cryptographic protocols designed to provide communications security over a computer network. Several versions of the protocols find widespread use in applications such as web browsing, email, instant messaging, and voice over IP. Wikipedia
Why is TLS required for Domain Rewrite (ERS)?
To ensure encrypted, secure mail routing, TLS is enforced for all connections.
To successfully implement the Domain Rewrite, a valid SSL certificate is required for all source and target tenants in scope for this service.
When the Email Rewrite Service is enabled for the first time, Connectors will be automatically created in Exchange Online to provide secure (TLS) email routing between the tenants and the Domain Rewrite relays.
When is TLS required for Domain Rewrite (ERS)?
It is always required. An SSL certificate is always required to ensure a secure connection between ERS and Exchange Online.
What is required to setup TLS for Domain Rewrite (ERS)?
Each tenant configured within the Domain Rewrite project will require 1 SSL certificate in the PFX format. The SSL certificate can only be uploaded to Domain Rewrite in the required PFX file format. PFX files contain the public key file (SSL Certificate file) and the associated private key file (password).
The requirements for the certificate are as follows (names are for example only):
- Common Name: contoso.com
- Cryptographic service provider: Microsoft RSA SChannel Cryptographic Provider
- Bit length: 2048 or higher
- Must be valid for Server Authentication and Client Authentication.
- Must be signed by a trusted public root CA.
- Must contain a private key (password).
- Must not expire before the end of the project.
- Must have a Friendly Name defined.
- No Wildcards Certificates
- No SAN (Subject Alternate Name) Certificates
- PFX file format with Password
- Paired with Email Signatures (DKIM) Domain
How do I upload the PFX certificate?
During project setup, the wizard will ask you to upload your pfx file and enter in the password.
When the SSL certificates are successfully uploaded and activated in On Demand Migration, an email notification will be sent to the project administrators. And, as with most Project settings, you can always return to the Dashboard to upload new certificates or make changes.