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 Northamerica.contoso.com, Europe.contoso.com, and Asia.contoso.com domains are rewritten to appear as if they all originate from a single Contoso.com domain. All messages are rewritten as they pass through Edge Transport servers that provide SMTP connectivity between the whole organization and the Internet.
    
    
  • Inbound messages to the Contoso.com 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 chris@contoso.com 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's 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're 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 Contoso.com. All messages from both organizations are sent through the Edge Transport servers at Contoso, Ltd., where e-mail messages are rewritten from someone@fourthcoffee.com to someone@contoso.com.
    
    
  • Inbound messages to adam@contoso.com are rewritten and routed to his adam@fourthcoffee.com e-mail account. Incoming messages that use his old adam@fourthcoffee.com 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 Fourthcoffee.com e-mail address. Replies to e-mail messages that were sent before the merger to Fourthcoffee.com 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 Contoso.com addresses are rewritten to appear as Wingtiptoys.com addresses.
    
    
  • Inbound messages for support@wingtiptoys.com are accepted by Wingtip Toy's Edge Transport servers, rewritten, and then routed to the support@contoso.com e-mail address.
    
    

    Caution:
    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.

Return to top

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. The following table shows which SMTP header fields are rewritten on outbound and inbound messages.

SMTP header fields rewritten on outbound and inbound messages

Return to top

Address Rewriting agents don't 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 aren't 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 don't rewrite header fields within e-mail messages that contain domains for which the Hub Transport server isn't authoritative. Rewriting such domains causes an uncontrollable form of message relay.

Address Rewriting agents also don't 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 don't trigger transport rules that are implemented between the sender and recipient.

Return to top

When an e-mail message is outbound from the Exchange 2010 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 ed@sales.contoso.com and ed@research.contoso.com are included in a rule to rewrite all addresses to contoso.com, the Address Rewriting agent will rewrite both addresses to ed@contoso.com 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 can't affect the user name or display name part of the address.
  
  
• Only literal strings are supported.
  
  

Return to top

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 chris@contoso.com, and the external address is support@contoso.com.
  
  
• Only literal strings are supported.
  
  
• The address must be unique across the organization. For example, if an e-mail address, bob@contoso.com, already exists, mapping robert@fourthcoffee.com to bob@contoso.com will cause replies to messages from bob@contoso.com to be delivered to the wrong person.
  
  

Return to top

Before you create an address rewrite entry that rewrites multiple domains, you must prepare your subdomains. Also, before you perform the procedure for creating an address rewrite entry for multiple subdomains that's described in Create an Address Rewrite Entry, you must understand the requirements for rewriting e-mail addresses in multiple domains to a single domain, and the appropriate preconfiguration for the affected mailboxes and contacts.

Important Considerations

When you flatten internal subdomains into a single external domain, you must consider the following factors, which apply only when multiple subdomains are being rewritten:

• Unique aliases are required   All e-mail aliases, the part of the e-mail address to the left of the at (@) sign, must be unique across all subdomains. For example, if there is a joe@sales.contoso.com, there can't be a joe@marketing.contoso.com.
  
  
• Proxy addresses are required   A proxy address that matches the e-mail address that's produced by the Address Rewriting agent must be configured on every e-mail account that's in the subdomains that are rewritten. For example, if joe@sales.contoso.com is rewritten to joe@contoso.com, the e-mail address joe@contoso.com must be added as a proxy address to Joe's mailbox.
  
  
• Contacts may be required   If you're rewriting e-mail from a non-Exchange 2010 e-mail system, you must create Active Directory mail-enabled contacts for each e-mail address in the non-Exchange 2010 e-mail address that's being rewritten. This mail-enabled contact must contain the original e-mail address and the rewritten e-mail address. For example, if joe@unix.contoso.com is rewritten to joe@contoso.com, you must create a mail-enabled contact in Active Directory with joe@unix.contoso.com as the target SMTP address and joe@contoso.com as the proxy SMTP address.
  
  

These factors are important because rewriting addresses in multiple subdomains causes a many-to-one relationship between internal subdomains and the externally visible domain. Because of this many-to-one relationship, the Address Rewriting agent can't determine which subdomain contains the correct recipient when a message that's addressed to the externally visible domain is received.

Important:
Make sure that every e-mail alias that exists across all subdomains is unique. Exchange 2010 doesn't check to verify that every e-mail alias that can be rewritten to a single domain is unique.

Removing Conflicting E-Mail Addresses

Applying Proxy Addresses to Recipient Mailboxes

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   An example is mapping john@contoso.com to support@contoso.com.
   
   
2. Specific domain or subdomain mapping   An example is mapping Contoso.com to Northwindtraders.com or Sales.contoso.com to Contoso.com.
   
   
3. Domain flattening   An example is flattening *.contoso.com into Contoso.com. For example, the following two rules are configured on the Edge Transport server:
   
   

   	Copy Code
   *.contoso.com maps to Contoso.com Japan.sales.contoso.com maps to contoso.jp

   If masato@japan.sales.contoso.com sends an e-mail message, the address is rewritten as masato@contoso.jp, because that rule most closely matches the sender's internal domain, even though the *.contoso.com rule is present.
   
   

Return to top

Address rewriting shouldn't 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 isn't applied.

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

• SMTP envelope fields
  
  
• Top-level message body headers
  
  

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

• Headers located inside MIME body parts that may be signed
  
  
• The boundary string parameter of the MIME content type
  
  

Return to top