Applies to: Live@edu
Topic Last Modified: 2011-03-19
For administrators who manage organizations with both on-premises messaging servers and mailboxes in the cloud-based e-mail service, it's important to understand how e-mail that is sent between your organization, the cloud-based e-mail service, and the Internet is delivered and relayed. One of the most common problems faced by administrators is false positives, when e-mail that is sent to the cloud-based e-mail service from their on-premises e-mail servers is filtered as spam by Forefront Online Protection for Exchange (FOPE). This typically happens if you haven't included all your e-mail servers on IP safelists.
Let's look at the configuration changes you can make to be sure that mail flow isn't disrupted.
What is an e-mail server?
An e-mail server can be dedicated to sending and receiving e-mail, such as a server that is running Microsoft Exchange Server, or the ability to send e-mail can be built into a computer's workflow. E-mail servers are classified as either a gateway server or an internal e-mail server for IP safelisting. Here are a few examples of each type:
Gateway servers A gateway server relays e-mail from a source server to its destination. For the purposes of IP safelisting, add the IP address of any networking device, which relays e-mail from your on-premises organization to the cloud-based e-mail service without performing any spam filtering, to the gateway servers list. Examples of gateway servers include the following:
-
A server that runs the Exchange 2007 or Exchange 2010 Edge Transport server role
-
An SMTP server configuration in Microsoft Internet Information Services (IIS)
-
A gateway appliance or device
-
The router address through which all outbound communications flow
Internal e-mail servers An internal e-mail server generates e-mail and relays it to the Internet through a gateway server. A gateway server can be considered an internal e-mail server if all outbound e-mail relayed to the cloud-based e-mail service through that IP address has already been filtered for spam. Examples of internal e-mail servers include the following:
-
An Exchange server
-
Another kind of server that uses a message transfer agent. For example, you might have a server that runs Microsoft SQL Server and is configured to send e-mail alerts, or a student information system that can send notifications to students in e-mail. For example, a server may automatically send schedule updates or overdue library book notices.
-
A gateway server that relays only trusted e-mail. Trusted e-mail is e-mail that originates inside your organization.
For more information about the spam filtering process and how to manage IP safelists for each server type, see Spam Filtering and Message Hygiene.
What routing scenarios are supported?
Before you configure IP safelists, you may find it helpful to prepare a simple diagram and summary table to document your routing scenario like the ones shown here. You'll also find this information helpful if you ever need to contact support.
Note The IP addresses in this section are for illustration purposes only. All IP addresses that you enter on IP safelists have to be publicly routable IP addresses. The IP safelist referenced in these scenarios can be managed using the FOPE Admin Center.
Stand-alone or tertiary hosted domain with routing directly to the cloud-based e-mail service
In this scenario, an on-premises messaging system isn't required. If you don't have an on-premises messaging system or other kind of server that generates e-mail, you don't have to do any IP safelisting. However, if you have any on-premises servers that send e-mail to the cloud-based e-mail service, you have to add them to the IP safelists. The following diagram shows this configuration:
-
The MX record for your hosted domain points to the cloud-based e-mail service. Therefore, e-mail that is sent from the Internet is delivered directly to the cloud-based e-mail service.
-
All e-mail that is sent through servers in your organization originates in your organization.
Here's how to configure IP safelists for this scenario.
| IP address (Example) | Type of server | Purpose of server | Add to IP safelist |
|---|---|---|---|
|
131.107.1.17 |
Gateway |
E-mail from internal servers is routed to the Internet |
Yes |
|
131.107.1.18 |
E-mail server |
Dedicated e-mail server |
No |
|
131.107.1.19 |
Database server |
Sends e-mail alerts |
No |
In this scenario, because all e-mail that is relayed to the cloud-based e-mail service from the gateway server originates in your organization, the gateway server can be added to the internal servers list and e-mail can bypass both connection filtering and content filtering.
Hosted domain with Internet e-mail relayed through an on-premises messaging system after it processes for spam
In this scenario, you set up your MX record for your the cloud-based e-mail service domain to point to your on-premises messaging system and use a forwarding solution to relay e-mail to the cloud-based mailboxes. You may use a shared address space and have an address rewriting or e-mail forwarding solution, or you may have a stand-alone or tertiary domain configured for internal relay after e-mail has been processed for spam. The following diagram shows this configuration:
-
The MX record for your hosted domain points to your on-premises organization. Therefore, e-mail that is sent from the Internet is delivered to your on-premises organization first.
-
E-mail that is destined for the cloud-based mailboxes is relayed from the on-premises e-mail servers to the cloud-based e-mail service after it has been processed for spam.
-
E-mail that is sent to the cloud-based e-mail service is relayed through your internal e-mail servers and gateway servers.
Here's how to configure IP safelists for this scenario.
| IP address (Example) | Type of server | Purpose | Add to IP safelist |
|---|---|---|---|
|
131.107.1.17 |
Gateway |
E-mail from internal servers is routed to the cloud-based e-mail service. |
Yes |
|
131.107.1.18 |
E-mail server |
Dedicated e-mail server |
No |
|
131.107.1.19 |
Database server |
Sends e-mail alerts |
No |
Because the e-mail that is relayed to the cloud-based e-mail service through your gateway servers, whether from your internal servers or from the Internet, is processed by your own spam filtering system, the cloud-based e-mail service can fully trust connections from your gateway servers. In this scenario, treat your gateway server as an internal mail server.
Shared address space with the cloud-based e-mail service relay
This scenario requires the use of a synchronization solution, such as the Microsoft Online Services Directory Synchronization tool for Microsoft Office 365 or Outlook Live Directory Sync (OLSync) for Live@edu to create reciprocal recipient objects in both your on-premises messaging system and in the cloud-based e-mail service. E-mail from the Internet is always routed first to the cloud-based e-mail service and then relayed to your on-premises recipients as appropriate. E-mail that is sent from your on-premises organization to the cloud-based e-mail service should be trusted and always originates from your on-premises servers.
The following diagram shows this configuration:
-
The MX record for your domain points to the cloud-based e-mail service. Therefore, e-mail that is sent from the Internet is delivered there first.
-
E-mail that is destined for on-premises recipients is relayed from the cloud-based e-mail service to your gateway server.
-
E-mail that is sent to the cloud-based e-mail service from your on-premises organization is relayed through your internal e-mail servers and gateway server.
Here's how to configure IP safelists for this scenario.
| IP address (Example) | Type of server | Purpose | Add to IP safelist |
|---|---|---|---|
|
131.107.1.17 |
Gateway |
E-mail from internal servers is routed to the Internet. |
Yes |
|
131.107.1.18 |
E-mail server |
Dedicated e-mail server |
No |
|
131.107.1.19 |
Database server |
Sends e-mail alerts |
No |
In this scenario, because all e-mail that is relayed to the cloud-based e-mail service from the gateway server originates in your organization, the gateway server can be added to the internal servers list and e-mail can bypass both connection filtering and content filtering.
Tips for success
Here are a few tips to help you reduce the amount of spam your users receive and make sure that your e-mail servers are trusted on the Internet:
-
Verify that your e-mail server or gateway server isn't an open relay. An open relay enables messages to be resubmitted or "relayed" by using a different server to mask the true source of the messages. Only trusted senders should be able to connect to your servers and send e-mail. If unauthenticated senders can relay e-mail through your servers, your organization may be treated as a source of spam.
-
Make sure that all e-mail servers are assigned a static IP address.
-
Enable reverse DNS lookups for your organization. Reverse DNS lookup lets other organizations verify that IP addresses are associated correctly with your domain.
-
Enable SPF records for your organization. And, if you have deployed a shared address space, update your SPF record to include the cloud-based e-mail service servers. For more information, see Use an SPF Record to Validate E-mail Sent from Your Domain.
