Applies to: Live@edu
Topic Last Modified: 2011-11-23
If you are deploying cloud-based mailboxes to supplement an existing on-premises messaging system, you may want to have a shared address space. A shared address space is when two different messaging systems share the same domain suffix.
There are two ways to configure a shared address space. This topic describes the on-premises relay configuration, in which all e-mail sent to recipients in the shared address space by a sender on the Internet is first delivered to the on-premises messaging system. The on-premises messaging system is responsible for forwarding e-mail addressed to recipients in the cloud-based e-mail service.
You may also want to consider Shared Address Space with Cloud Relay for Live@edu. With cloud relay, all e-mail sent to recipients in the shared address space by a sender on the Internet is first delivered to the cloud-based e-mail service, and the cloud-based e-mail service is responsible for forwarding e-mail addressed to recipients in the on-premises messaging system using mail users.
Important This topic describes the on-premises relay configuration for Live@edu organizations. For Microsoft Office 365 for enterprises, see the Exchange Server Deployment Assistant.
Contoso University uses the @contoso.edu address space for all faculty and staff e-mail addresses in an on-premises messaging system. Contoso University plans on giving all students cloud-based mailboxes. However, Contoso University wants all faculty, staff, and students to use the @contoso.edu domain suffix for all e-mail addresses. All e-mail messages must leave the organization with an @contoso.edu From: address, whether the sender is in the on-premises messaging system or in the cloud-based e-mail service. All incoming messages with an @contoso.edu e-mail address should be correctly delivered whether the recipient is in the on-premises messaging system or in the cloud-based e-mail service. To achieve this goal, Contoso University has to implement a shared address space.
The following diagram illustrates the deployment of a shared address space for Contoso University.
Note the following key points:
-
All e-mail sent to any @contoso.edu recipient by a sender on the Internet is first delivered to the on-premises messaging system.
-
The on-premises messaging system is responsible for forwarding e-mail addressed to students in the cloud-based e-mail service.
To make the shared address space work, you need the following components:
-
Multiple domains
-
Multiple e-mail addresses
Ironically, to configure a single shared address space, you need to configure multiple domains. The following domains are required for a shared address space:
- The domain for the shared address space itself In this example, the shared domain is @contoso.edu. This is also the domain that is used for the on-premises messaging system.
- A specific domain for mailboxes in the cloud-based e-mail service In this example, the cloud-based domain is @live.contoso.edu.
The cloud-based domain must be different from the on-premises domain so e-mail is correctly routed between the on-premises messaging system and the cloud-based e-mail service. Senders and recipients that are outside the organization don't care about the cloud-based domain, but it is a vital part of making the shared address space work correctly.
A key ingredient to a shared address space is correctly configuring the e-mail addresses on mailboxes in the on-premises messaging system and in Outlook Live.
Here's how the e-mail addresses must be configured on all mailboxes:
- The primary address The primary address is used as the From: address for all messages sent from the mailbox. There can be only one value for the primary address. In this example, everyone's primary address is in the shared address space @contoso.edu.
- Proxy addresses Proxy addresses are additional addresses for a mailbox. Proxy addresses are also known as secondary e-mail addresses. The mailbox can receive e-mail sent to any of its proxy addresses. The primary address is always listed as a proxy address.
Here are the correct values for the primary address and proxy addresses for on-premises mailboxes and Outlook Live mailboxes.
| On-premises mailboxes | Outlook Live mailboxes | |
|---|---|---|
| Primary address | <user>@contoso.edu | <user>@contoso.edu |
| Proxy addresses | <user>@contoso.edu |
|
When you share an address space between an on-premises messaging system and the cloud-based e-mail service, one of the messaging systems must be configured as authoritative for the shared address space. When the messaging system is designated as authoritative for the @contoso.edu domain, all unresolved recipients generate a non-delivery report (NDR). This configuration prevents e-mail for nonexistent recipients from bouncing back and forth indefinitely between the on-premises messaging system and the cloud-based e-mail service.
You configure the shared address space @contoso.edu in the cloud-based e-mail service as a non-authoritative address space. If the @contoso.edu recipient isn't found in the cloud-based e-mail service shared address book, the message is forwarded to the on-premises messaging system for processing. If the recipient doesn't exist, the on-premises messaging system is responsible for generating the NDR.
If @contoso.edu is configured as the authoritative name space for the on-premises messaging system, how does the on-premises messaging system know to forward messages for valid cloud-based recipients to the cloud-based e-mail service without generating an NDR? The on-premises messaging system must be configured with a forwarding solution that converts the @contoso.edu recipients to @live.contoso.edu recipients. For example:
-
You create mail users or mail contacts in the on-premises address book for all cloud-based recipients.
-
You use address rewriting from @contoso.edu to @live.contoso.edu for all unresolved @contoso.edu recipients.
Other forwarding solutions may also be available depending on the nature of the on-premises messaging system. Regardless of the forwarding solution that you use, make sure that e-mail for nonexistent recipients is handled correctly for both the on-premises messaging system and the cloud-based e-mail service.
As noted earlier, the on-premises messaging system is configured to accept all incoming e-mail from the Internet for the shared address space. In the Contoso University example, all e-mail for the @contoso.edu domain is delivered to the on-premises messaging system. You accomplish this by configuring the MX record for the contoso.edu domain in an Internet-facing DNS server to point to the on-premises messaging system.
After the e-mail arrives, the on-premises messaging system is responsible for correctly determining if the recipient has a mailbox in the on-premises messaging system or in the cloud-based e-mail service, and then delivering the message or forwarding the message as appropriate.
Here are two e-mail routing scenarios in a shared address space:
- E-mail sent to students in the cloud-based e-mail service The messages could come from external senders on the Internet, or from faculty and staff in the on-premises messaging system. The on-premises messaging system is configured to forward e-mail for students to the cloud-based e-mail service. The required configuration depends heavily on the nature of the on-premises messaging system. For details, see Configure a Shared Address Space with On-Premises Relay for Live@edu.
- E-mail sent from students in the cloud-based e-mail service to faculty and staff in the on-premises messaging system The shared address space @contoso.edu is configured as an internal relay domain in the cloud-based e-mail service. When the faculty or staff recipient isn't found in the cloud-based shared address book, the message is routed to the Internet, and the contoso.edu domain points to the on-premises messaging system, so the message is delivered successfully.
Internal e-mail between recipients in the on-premises messaging system or between students in the cloud-based e-mail service is straight-forward. In both cases, the recipients are in their respective address books, so the message is delivered locally.
Likewise, outgoing e-mail to recipients outside the organization operates as expected. The on-premises messaging system uses its existing path to the Internet to deliver e-mail messages to the Internet for recipients outside the organization, and the cloud-based e-mail service delivers messages directly to the Internet.
In the shared address space scenario, when incoming e-mail is first delivered to the on-premises messaging system before being forwarded to the cloud-based e-mail service, the on-premises messaging system becomes a single point of failure. The cloud-based domain can be functioning normally, but because something is wrong with the on-premises messaging system, e-mail can't be delivered to cloud-based recipients.
Also, the on-premises messaging system is responsible for protecting messages that are forwarded to the cloud-based e-mail service from spam and viruses. Failure to do so may cause the e-mail coming from the on-premises messaging system to be blocked or severely throttled by Forefront Online Protection for Exchange.
