Address
rewriting was created by Microsoft to allow an organization to have all
outbound or inbound email appear to be delivered from one domain when
several mail-enabled domains could be sending messages through the same
systems. This allows a company to provide a consistent appearance when
communicating via email. Address rewriting is commonly used on outbound
email when companies merge with or acquire other organizations. Address
rewriting is also used on outbound email when an organization’s network
contains several other domains. Using address rewriting in these
scenarios results in external recipients seeing email as originating
from one domain name even if it is coming from a domain with a
completely different name.
Note
If you enable
address rewriting on external messages, ensure you have enabled address
rewriting on inbound messages as well, so that inbound messages will be
delivered to the appropriate recipients.
Configuring Address Rewriting
As with many of the
components for the Edge Transport server, address rewriting is enabled
on inbound email messages so messages that were rewritten when sent
externally can be routed back to the appropriate person. Address
rewriting can also be beneficial when sending email between internal
systems. For example, if an IT department has multiple domains and the
organization wants all email communication from the IT department to
internal departments (other than IT) to come from *@it.companyabc.com, then address rewriting would be used to accomplish this.
Note
Using address
rewriting on your outbound email messages eases white-listing of your
organization’s email for external recipients and business partners by
simplifying the answer to their question: “What domain and systems can
we expect to receive email from?”
Note
Changes described in this
section are applied only to the local system. This is important if you
have more than one Edge Transport server in your environment.
Some considerations to
take into account when using address rewriting are items that will not
be rewritten, end result of email addresses being combined, messages
that have been secured, and rewriting in both directions.
Address rewriting will
not modify messages that are attached to the message being rewritten and
also will not modify the SMTP Return-Path, Received, Message-ID,
X-MS-TNEF-Correlator, Content-Type Boundary=string headers, and headers
located inside of MIME body parts. Message-ID, X-MS-TNEF-Correlator,
Content-Type Boundary=string headers, and headers located inside of MIME
body parts are used when securing email messages such as with
encryption or Microsoft Rights Management and are, therefore, not
rewritten purposely to ensure the message isn’t modified to ensure
delivery and integrity of the content.
To ensure that
messages (mainly responses to rewritten messages) get routed to the
appropriate person, a few items need to be addressed. First, the end
result of the email address must be unique between users so conflicts
and incorrect delivery of messages does not occur; second, a proxy
address must be configured on the mailbox that matches the rewritten
address; and third, address rewriting must be configured on both the
Send and Receive Connectors of the Edge Transport server.
To ensure the
rewritten email address between domains will remain unique to the user,
take into account how each domain creates their usernames. For example,
domains that allow simple usernames like Alexa@, Reese@, or support@ will have more conflicts when using address rewriting than organizations that use more unique or defined usernames like Alexa_Chimner@, RMChimner@, or online-sales-support@.
If two domains used simple usernames in their email addresses and the
organization wanted to use address rewriting, the end result could
contain too many conflicts, presenting the need to change email
addresses at least in one domain. This could end up being quite an
involved task depending on the number of users in each domain. For
example, CompanyABC.com wants to have all email from domains like infosec.companyabc.com, it.companyabc.com, and development.companyabc.com leave the organization as companyabc.com. If two different users named Mike have the same email prefix (mike) in it.companyabc.com and infosec.companyabc.com, there will be a conflict as they would both be rewritten to [email protected]. This has more of an impact on replies to rewritten messages than it does to new outbound messages.
Note
The use of wildcards
is supported in limited usage when rewriting addresses. For example,
wildcards can only be used on internal domains. Partial wildcard use
such as john*@finance.companyabc.com or username@sales*.companyabc.com is not supported, whereas username @*.companyabc.com is. One example of wildcard usage is rewriting *@development.companyabc.com and *@software.companyabc.com to *@support.companyabc.com.
Address rewriting can
only be configured through the Exchange Management Shell. No address
rewriting options are available in the Exchange Management Console. Each
shell command has its own parameters you can set based on the action(s)
performed by the command. There are four commands: Get-AddressRewriteEntry, New-AddressRewriteEntry, Set-AddressRewriteEntry, and Remove-AddressRewriteEntry.
The Get- command is used to retrieve the configuration of address rewriting. For example, entering Get-AddressRewriteEntry displays the configuration settings on the local system.
The New-AddressRewriteEntry command can be used to add a new rewriting entry. Use of this command requires three parameters: ExternalAddress, InternalAddress, and Name. The following example rewrites all email addresses in both directions for companyabc.com:
New-AddressRewriteEntry -Name "Two-way Rewrite entry for companyabc.com" -InternalAddress companyabc.com -ExternalAddress companydef.com
The Set-
command allows an administrator to activate address rewriting or modify
the existing configuration. The following example switches the internal
and external domains given in our previous example and updates the
description to reflect the change:
Set-AddressRewriteEntry -Identity "Two-way Rewrite entry for companyabc.com"
-ExternalAddress companydef.com -InternalAddress companyabc.com -Name "Two-way Rewrite entry for companydef.com"
Remove-AddressRewriteEntry -Identity ""Two-way Rewrite entry for companydef.com"
