IP Safelisting for Mail Delivery and Relay

Applies to: Live@edu

Topic last modified: 2011-03-19

For administrators who manage organisations with both on-premises messaging servers and mailboxes in the cloud-based email service, it's important to understand how email that is sent between your organisation, the cloud-based email service and the Internet is delivered and relayed. One of the most common problems faced by administrators is false positives, when email that is sent to the cloud-based email service from their on-premises email servers is filtered as spam by Forefront Online Protection for Exchange (FOPE). This typically happens if you haven't included all your email 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 email server?

An email server can be dedicated to sending and receiving email, such as a server that is running Microsoft Exchange Server, or the ability to send email can be built into a computer's workflow. Email servers are classified as either a gateway server or an internal email server for IP safelisting. Here are a few examples of each type:

Gateway servers A gateway server relays email from a source server to its destination. For the purposes of IP safelisting, add the IP address of any networking device, which relays email from your on-premises organisation to the cloud-based email 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 email servers An internal email server generates email and relays it to the Internet through a gateway server. A gateway server can be considered an internal email server if all outbound email relayed to the cloud-based email service through that IP address has already been filtered for spam. Examples of internal email 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 email alerts, or a student information system that can send notifications to students in email. For example, a server may automatically send schedule updates or overdue library book notices.
A gateway server that relays only trusted email. Trusted email is email that originates inside your organisation.

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 email 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 email, you don't have to do any IP safelisting. However, if you have any on-premises servers that send email to the cloud-based email 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 email service. Therefore, email that is sent from the Internet is delivered directly to the cloud-based email service.
All email that is sent through servers in your organisation originates in your organisation.

Mail flow to cloud service without relay

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	Email from internal servers is routed to the Internet	Yes
131.107.1.18	Email server	Dedicated email server	No
131.107.1.19	Database server	Sends email alerts	No

In this scenario, because all email that is relayed to the cloud-based email service from the gateway server originates in your organisation, the gateway server can be added to the internal servers list and email can bypass both connection filtering and content filtering.

Hosted domain with Internet email 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 email service domain to point to your on-premises messaging system and use a forwarding solution to relay email to the cloud-based mailboxes. You may use a shared address space and have an address rewriting or email forwarding solution, or you may have a stand-alone or tertiary domain configured for internal relay after email has been processed for spam. The following diagram shows this configuration:

The MX record for your hosted domain points to your on-premises organisation. Therefore, email that is sent from the Internet is delivered to your on-premises organisation first.
Email that is destined for the cloud-based mailboxes is relayed from the on-premises email servers to the cloud-based email service after it has been processed for spam.
Email that is sent to the cloud-based email service is relayed through your internal email servers and gateway servers.

Mail relay to cloud service after spam processing

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	Email from internal servers is routed to the cloud-based email service.	Yes
131.107.1.18	Email server	Dedicated email server	No
131.107.1.19	Database server	Sends email alerts	No

Because the email that is relayed to the cloud-based email 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 email 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 email service relay

This scenario requires the use of a synchronisation solution, such as the Microsoft Online Services Directory Synchronisation tool for Microsoft Office 365 Beta 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 email service. Email from the Internet is always routed first to the cloud-based email service and then relayed to your on-premises recipients as appropriate. Email that is sent from your on-premises organisation to the cloud-based email 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 email service. Therefore, email that is sent from the Internet is delivered there first.
Email that is destined for on-premises recipients is relayed from the cloud-based email service to your gateway server.
Email that is sent to the cloud-based email service from your on-premises organisation is relayed through your internal email servers and gateway server.

Mail flow to cloud and relay to on-premises

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	Email from internal servers is routed to the Internet.	Yes
131.107.1.18	Email server	Dedicated email server	No
131.107.1.19	Database server	Sends email alerts	No

Tips for success

Here are a few tips to help you reduce the amount of spam your users receive and make sure that your email servers are trusted on the Internet:

Verify that your email 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 email. If unauthenticated senders can relay email through your servers, your organisation may be treated as a source of spam.
Make sure that all email servers are assigned a static IP address.
Enable reverse DNS lookups for your organisation. Reverse DNS lookup lets other organisations verify that IP addresses are associated correctly with your domain.
Enable SPF records for your organisation. And, if you have deployed a shared address space, update your SPF record to include the cloud-based email service servers. For more information, see Use an SPF Record to Validate Email Sent from Your Domain.