Applies to: Exchange Server 2007 SP3, Exchange Server 2007 SP2, Exchange Server 2007 SP1, Exchange Server 2007
Topic Last Modified: 2007-11-08

In Microsoft Exchange Server 2007, address rewriting enables you to modify the addresses of senders and recipients on messages that enter and leave your Exchange 2007 organization.

Why Use Address Rewriting?

You use address rewriting to present a consistent appearance to external recipients of messages from your Exchange 2007 organization. Address rewriting can be valuable to organizations that use third-party vendors to provide e-mail support and services. Customers and partners expect e-mail messages to come from the organization, not a third-party vendor. Similarly, after a merger or acquisition, an organization might want all e-mail messages to appear to come from the single new organization. The address rewriting feature frees organizations to structure their businesses by business requirements instead of by technical requirements or limitations.

You can also use address rewriting to enable appropriate routing of inbound messages from outside your Exchange 2007 organization to internal recipients. Address rewriting enables replies to messages that were rewritten to be correctly routed to the original sender of the rewritten message.

You configure Address Rewriting agents on the Receive connector and Send connector on a computer that has the Edge Transport server role installed.

Address Rewriting Scenarios

The following scenarios are examples of how address rewriting can benefit organizations:

  • Group consolidation   Some organizations segment their internal businesses into separate domains that are based on business or technical requirements. However, this configuration can cause e-mail messages to appear as if they come from separate groups or even separate organizations. This appearance might not be desirable to the organization.

    The following example shows how an organization, Contoso, Ltd., could hide its subdomains:

    • Outbound messages from the,, and domains are rewritten to appear as if they all originate from a single domain. All messages are rewritten as they pass through Edge Transport servers that provide Simple Mail Transfer Protocol (SMTP) connectivity between the whole organization and the Internet.

    • Inbound messages to the domain are passed on by the Edge Transport server to the Hub Transport server role, which then determines the correct recipient. For example, messages to are sent to an internal Hub Transport server, which then determines the correct mailbox to send the message to by using the proxy address that is configured on the recipient's e-mail account.

  • Mergers and acquisitions   When organizations merge or are acquired, their technology infrastructure must be modified to match new business and technical requirements. An acquired company may continue to run as a separate business unit, but the e-mail administrator can use address rewriting to make the two organizations appear as if they are one integrated organization.

    The following example shows how Contoso, Ltd. could hide the e-mail domain of the newly acquired company, Fourth Coffee:

    • Contoso, Ltd. wants all outbound messages from Fourth Coffee's Exchange organization to appear as if they originate from All messages from both organizations are sent through the Edge Transport servers at Contoso, Ltd., where e-mail messages are rewritten from to

    • Inbound messages to are rewritten and routed to his e-mail account. Incoming messages that use his old domain are also accepted, because the domain still exists. Inbound replies to e-mail messages that were rewritten are handled by the Edge Transport servers at Contoso, Ltd., where the Address Rewriting agent rewrites the recipient address so that replies are correctly routed to the appropriate e-mail address. Replies to e-mail messages that were sent before the merger to e-mail addresses are routed directly to Fourth Coffee's e-mail servers.

  • Partners   Many organizations use external partners to provide services for their customers, other partners, or the organization itself. To avoid confusion, the organization might replace the e-mail domain of the partner organization with its own e-mail domain.

    The following example shows how Contoso, Ltd. could hide a partner's e-mail domain:

    • Contoso, Ltd. provides support for the larger Wingtip Toys organization. Wingtip Toys wants a unified experience for its customers and requires all messages that originate from support personnel at Contoso, Ltd. to appear as if they were sent from Wingtip Toys. All outbound messages that relate to Wingtip Toys are sent through their Edge Transport servers, and all addresses are rewritten to appear as addresses.

    • Inbound messages for are accepted by Wingtip Toy's Edge Transport servers, are rewritten, and then are routed to the e-mail address.

    So that inbound e-mail is appropriately mapped and routed, you must make sure that the user name part of the address is unique across all e-mail organizations that may be affected by address rewriting.

SMTP Message Headers

Address Rewriting agents rewrite e-mail addresses by rewriting the SMTP headers on e-mail messages that are sent and received by an Edge Transport server. Address Rewriting agents typically rewrite outbound messages because the organization wants to hide the internal domains and subdomains as effectively as possible and present a single external domain to the Internet. Address Rewriting agents typically rewrite inbound messages to route those messages to their intended recipients. For these reasons, Address Rewriting agents rewrite several SMTP header fields on outbound e-mail messages. Address Rewriting agents rewrite only one SMTP header field on inbound e-mail messages. Table 1 shows which SMTP header fields are rewritten on outbound and inbound messages.

Table 1   SMTP header fields rewritten on outbound and inbound messages

SMTP header field Outbound Inbound

Envelope From (MAIL FROM)


Not rewritten

Envelope To (RCPT TO)

Not rewritten


Body To


Not rewritten

Body Cc


Not rewritten

Body From


Not rewritten

Body Sender


Not rewritten

Body Reply-To


Not rewritten

Body Return-Receipt-To


Not rewritten

Body Disposition-Notification-To


Not rewritten

Body Resent-From


Not rewritten

Body Resent-Sender


Not rewritten

What Address Rewriting Agents Will Not Rewrite

Address Rewriting agents do not rewrite several SMTP header fields, because address rewriting would break SMTP functionality. For example, changing these SMTP headers could affect message loop detection, invalidate the signature, or make a rights-protected message unreadable. The following SMTP header fields are not modified by the Address Rewriting agents:

  • Return-Path

  • Received

  • Message-ID

  • X-MS-TNEF-Correlator

  • Content-Type Boundary=string

  • Headers located inside MIME body parts

Address Rewriting agents also do not rewrite header fields within e-mail messages that contain domains for which the Hub Transport server is not authoritative. Rewriting such domains causes an uncontrollable form of message relay.

Address Rewriting agents also do not modify the header fields of messages that are embedded in another message. Senders and recipients expect embedded messages to remain intact and be delivered without modification, as long as the messages do not trigger transport rules that are implemented between the sender and recipient.

Meeting requests that are sent to remote domains that do not support TNEF are sent as iCalendar attachments. Because address rewriting agents do not modify the header fields of embedded messages, the addresses on these meeting requests will not be modified.

Considerations for Use of Outbound-Only Address Rewriting

When an e-mail message is outbound from the Exchange 2007 organization, outbound-only address rewriting involves modification of the sender SMTP address only. The Address Rewriting agent is configured only on the Send connector on the Edge Transport server. The following list shows the conditions that are required to configure an outbound-only Address Rewriting agent:

  • The resulting addresses must be unique across the organization. For example, if the unique e-mail addresses and are included in a rule to rewrite all addresses to, the Address Rewriting agent will rewrite both addresses to and will cause a conflict.

  • A proxy address must be configured on each mailbox that matches the rewritten e-mail address. This enables those mailboxes to receive replies to e-mail messages in which headers are rewritten.

  • When you use wildcard characters, there must be a period between the wildcard character and the domain name.

  • You can use wildcard characters only in the internal domain.

  • No characters can be in front of the wildcard character.

  • Outbound-only address rewriting cannot affect the user name or display name part of the address.

  • Only literal strings are supported.

Considerations for Bidirectional Address Rewriting

Bidirectional address rewriting modifies the sender SMTP address on e-mail messages that are leaving the Exchange organization and the recipient SMTP address on e-mail messages that are entering the Exchange organization. To do this, you configure the Address Rewriting agent on both the Send connector and Receive connector on the Edge Transport server.

The following list shows the conditions that are required when you create a bidirectional Address Rewriting agent:

  • You can't use wildcard characters.

  • You must use full SMTP addresses when you configure a bidirectional address rewriting rule. For example, the internal address is, and the external address is

  • Only literal strings are supported.

  • The address must be unique across the organization. For example, if an e-mail address,, already exists, mapping to will cause replies to messages from to be delivered to the wrong person.

Prioritization of Address Rewriting Entries

The rule that best matches the internal and external domain pair is applied. The following prioritization is the exact order of address rewriting entries from highest priority to lowest priority:

  1. Individual e-mail addresses   For example, mapping to

  2. Specific domain or subdomain mapping   For example, mapping to or to

  3. Domain flattening   For example, flattening * into For example, the following two rules are configured on the Edge Transport server:

    Copy Code
    * maps to maps to
    If sends an e-mail message, the address is rewritten as, because that rule most closely matches the sender's internal domain, even though the * rule is present.

Digitally Signed, Encrypted, and Rights-Protected Messages

Address rewriting should not affect most signed, encrypted, or rights-protected messages. If address rewriting were to invalidate a signature, make an encrypted or rights-protected message unreadable, or otherwise change the security status of such messages in any way, address rewriting is not applied.

Addresses and information in the following message sections can be rewritten, because information in these sections is not part of message signing, encryption, or rights protection:

  • SMTP envelope fields

  • Top-level message body headers

Addresses and information in the following message sections is not rewritten because information in these sections is part of message signing, encryption, or rights protection:

  • Headers that are located inside MIME body parts that may be signed

  • The boundary string parameter of the MIME content type

For More Information

For more information about address rewriting, see the following topics: