TechNet
Export (0) Print
Expand All

Mail flow best practices for Exchange Online and Office 365 (Overview)

Exchange Online
 

Applies to: Exchange Online

Topic Last Modified: 2016-05-03

 

This article is intended for IT Pros. Want something else?

Try Set up Office 365 for business or Deploy Office 365 Enterprise for your organization.

Office 365 gives you flexibility in determining the best arrangement for how email is delivered to your organization’s mailboxes. The path email takes from the internet to a mailbox and vice versa is called mail flow. Most organizations would like Office 365 to manage all their mailboxes and filtering, and some organizations need more complex mail flow setups to make sure that they comply with specific regulatory or business needs. If you’re part of a small business or simply an organization that wants Office 365 to manage all your mailboxes and mail flow, we recommend following the steps in Set up Office 365 for business. That article provides a complete checklist for setting up Office 365 services and programs, including how to set up your mail flow and email clients.

For information about how your email is protected with EOP, see Exchange Online Protection overview.

This guide covers the following scenarios.

 

Mail flow setup Your organization's scenario Complexity

All mailboxes and mail flow managed by Office 365 (recommended)

Scenario 1

I’m a new Office 365 customer, and all my users’ mailboxes are in Office 365. I want to use all filtering solutions offered by Office 365.

Scenario 2

I’m a new Office 365 customer. I have an existing email service but plan to move all the existing users’ mailboxes to the cloud at once. I want to use all filtering solutions offered by Office 365.

Simple

Using a third-party cloud service with Office 365

Scenario 1

I plan to have Office 365 host all of my organization’s mailboxes. My organization uses (or plans to use) a third-party cloud service for filtering spam and malware. All email sent from the internet must be filtered by this third-party cloud service.

Scenario 2

I plan to have Office 365 host all my organization’s mailboxes. My organization needs to send all email to a third-party service, such as archiving or auditing. However, the third-party service doesn’t provide a spam filtering solution.

Complex

Setting up mail flow where some mailboxes are in Office 365 and some mailboxes are on your organization’s mail servers

ImportantImportant:
In the near future, Office 365 will reject email from unknown senders that are relayed from on-premises servers. This means that if the sender or recipient domain of a message doesn’t belong to your organization, Office 365 will reject the message unless you have created a connector to allow this behavior. This change will help prevent unauthorized parties from using your organization to send spam or malware through Office 365.
This change potentially affects your mail flow if you use any scenario in this section. Each scenario has best practices to ensure that your mail flow continues uninterrupted.

Scenario 1

I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use Office 365 as my spam filtering solution and would like to send my messages from my on-premises server to the internet via Office 365. Office 365 sends and receives all messages.

Scenario 2

I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use the filtering and compliance solutions that are already in my on-premises environment. And all messages coming from the internet to my cloud mailboxes or messages sent to the internet from my cloud mailboxes need to route through my on-premises servers.

Scenario 3

I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use the filtering and compliance solutions that are already in my on-premises email environment. All messages coming from the internet to my cloud mailboxes or messages sent to the internet from cloud mailboxes must route through my on-premises servers. And I need to point my domain’s MX record to my on-premises server.

Scenario 4

I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use the filtering and compliance solutions that are already in my on-premises email environment. All messages sent from my on-premises servers must relay through Office 365 to the internet. And I need to point my domain’s MX record to my on-premises server.

Very complex

Using a third-party cloud service with mailboxes on Office 365 and on your organization's mail servers

Scenario

I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use a third-party cloud service to filter spam from the internet. My messages to the internet need to route through Office 365 to protect my on-premises servers’ IP addresses from being added to external block lists.

Most complex

Sending emails from a multifunction printer/scanner/fax/application through Office 365

For details about this scenario, see How to set up a multifunction device or application to send email using Office 365.

Scenario

All my organization’s mailboxes are hosted in Office 365, but I have a multifunction printer, scanner, fax machine, or an application that needs to send email.

Complex

Using Exchange Online Protection (EOP) standalone

For details about this scenario, see Mail flow in EOP and How do connectors in EOP or Exchange Online work with my own email servers (also called "on-premises servers")?

Scenario

I have my own email servers (on-premises servers), and I subscribe to EOP only for email protection services.

Simple

TipTip:
Are you new to Office 365 mail flow? Check out the Introduction to the basics of Office 365 mail flow at the end of this topic. We especially recommend reading the part about SPF records because customers often list the wrong values in their SPF record, which causes mail flow problems.
NoteNote:
Examples in this guide use the fictitious organization, Contoso, which owns the domain contoso.com. The IP address of the Contoso mail server is 131.107.21.231, and its third-party provider uses 10.10.10.1 for their IP address. These are just examples. You can adapt these examples to fit your organization’s domain name and public-facing IP address where necessary.

For information about migrating your email to Exchange Online, see Ways to migrate multiple email accounts to Office 365.

  • I'm a new Office 365 customer, and all my users' mailboxes are in Office 365. I want to use all filtering solutions offered by Office 365.

  • I'm a new Office 365 customer. I have an existing email service but plan to move all the existing users' mailboxes to the cloud at once. I want to use all filtering solutions offered by Office 365.

For this scenario, your organization's mail flow setup looks like the following diagram.

Mail flow diagram showing mail going from the internet to Office 365 and from Office 365 to the internet.

For most organizations, we recommend using hosted mail flow because it's the simplest configuration and means that Office 365 manages all mailboxes and filtering. The simplicity of this configuration makes it easier for you to set up and manage mail flow. To set up hosted mail flow, we recommend using the Office 365 setup wizard. To get to the Office 365 setup wizard, go to Setup in the Office 365 admin center.

Screenshot of the Setup option in the Office 365 admin center navigation menu

The Office 365 setup wizard walks you through the following steps.

  1. Add your custom domains in Office 365, and prove that you own the domains by following the instructions in Add users and domains.

  2. Create user mailboxes in Exchange Online or move all users' mailboxes to Office 365.

  3. Update the DNS records for the domains that you added in step 1. (Not sure how to do that? Follow the instructions on this page.) The following DNS records control mail flow:

    • MX record – Point your MX record to Office 365 in the following format: <domainKey>-com.mail.protection.outlook.com

      For example, the domain contoso.com should have the MX record contoso-com.mail.protection.outlook.com.

    • SPF record – This is a special TXT record in DNS, which is used to identify a service as a valid sender for a particular domain. Because Office 365 is sending all your messages, only list Office 365 as a valid sender for your domain. To do that, add an SPF record for your domain in the following format: v=spf1 include:spf.protection.outlook.com -all

For a full list of setup instructions, check out Set up Office 365 for business or Deploy Office 365 Enterprise for your organization, depending on what plan your organization uses.

  • I plan to have Office 365 host all my organization's mailboxes. My organization is using (or wants to use) a third-party cloud service for filtering spam and malware. All email sent from the internet must be filtered by this third-party cloud service.

For this scenario, your organization’s mail flow setup looks like the following diagram.

Mail flow diagram with arrows showing email going from the internet to a third-party solution with filtering to Office 365 and from Office 365 directly to the internet.

  1. Add your custom domains in Office 365, and prove that you own the domains by following the instructions in Add users and domains.

  2. Create user mailboxes in Exchange Online or move all users' mailboxes to Office 365.

  3. Update the DNS records for the domains that you added in step 1. (Not sure how to do that? Follow the instructions on this page.) The following DNS records control mail flow:

    • MX record – Your domain's MX record needs to point to your third-party service provider. Follow their guidelines for how to configure your MX record.

    • SPF record – Because your domain’s MX record will need to point to the third-party service (in other words, you require complex routing), your SPF record should include them as well. Please follow the guidelines from your third-party cloud service. However, you should also add Office 365 as a valid sender. For example, if contoso.com is your domain, and the IP address for the third-party cloud service is 10.10.10.1, the SPF record for contoso.com should be: v=spf1 ipv4: 10.10.10.1 include:spf.protection.outlook.com –all

      Alternatively, depending on the third-party provider's requirements, you may need to include the domain from the third-party instead like the following example: v=spf1 include:spf.protection.outlook.com include:third_party_cloud_service.com –all

  • I plan to have Office 365 host all my organization’s mailboxes. My organization needs to send all email to a third-party service, such as archiving or auditing. However, the third-party service doesn’t provide a spam filtering solution.

We don’t recommend or support this scenario because it causes Office 365 spam filtering not to work properly. If you choose this scenario, your organization’s mail flow setup looks like the following diagram.

Mail flow diagram showing the unsupported scenario of mail going from the internet to a third-party solution without filtering to Office 365 and from Office 365 to the third-party solution to the internet.

  • Don’t use this scenario because it isn’t supported currently. Until this scenario is supported, we recommend that you use solutions (archiving, auditing, etc.) that are provided by Office 365.

  • I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use Office 365 as my spam filtering solution and would like to send my messages from my on-premises server to the internet via Office 365. Office 365 sends and receives all messages.

Most customers who need a hybrid mail flow setup should allow Office 365 to perform all their filtering and routing. We recommend pointing your MX record to Office 365 because this provides for the most accurate spam filtering. For this scenario, your organization’s mail flow setup looks like the following diagram.

Mail flow diagram showing the scenario where your MX record points to Office 365 and mail from the internet goes to Office 365 and then to your on-premises servers. Mail travelling from your on-premises servers goes to Office 365 and then to the internet.

  1. Add your custom domains in Office 365, and prove that you own the domains by following the instructions in Add users and domains.

  2. Create user mailboxes in Exchange Online or move all users' mailboxes to Office 365.

  3. Update the DNS records for the domains that you added in step 1. (Not sure how to do that? Follow the instructions on this page.) The following DNS records control mail flow:

    • MX record – Point your MX record to Office 365 in the following format: <domainKey>-com.mail.protection.outlook.com

      For example, if your domain is contoso.com, the MX record should be: contoso-com.mail.protection.outlook.com.

    • SPF record – This should list Office 365 as a valid sender, plus any IP addresses from your on-premises servers that connect to EOP, and any third parties that send email on behalf of your organization. For example, if your organization’s mail server’s internet-facing IP address is131.107.21.231, the SPF record for contoso.com should be: v=spf1 ipv4: 131.107.21.231 include:spf.protection.outlook.com –all

      Alternatively, depending on the third-party's requirements, you may need to include the domain from the third-party instead like the following example: v=spf1 include:spf.protection.outlook.com include:third_party_cloud_service.com –all

  4. In the Exchange admin center, use the connector wizard to Configure mail flow using connectors in Office 365 for the following scenarios:

    • Sending messages from Office 365 to your organization’s mail servers

    • Sending messages from your on-premises servers to Office 365

    You need to create a connector to support sending mail from your on-premises servers to Office 365 if either of the following scenarios apply to your organization.

    • Your organization is authorized to send messages on behalf of your client, but your organization doesn’t own the domain. For example, contoso.com is authorized to send email via fabrikam.com, which doesn’t belong to contoso.com.

    • Your organization relays NDRs (non-delivery report) to the Internet via Office 365.

    To create the connector, choose the first option in the connector creation wizard on the “How should Office 365 identify email for your email server” screen.

    Screenshot showing the New Connector screen of the Hybrid Connection Wizard for Exchange

    This allows Office 365 to identify your email server using the certificate. In this scenario, the certificate CN or Subject Alternative Name (SAN) contains the domain that belongs to your organization. For more details, see Identifying email from your email server. For connector configuration details see, Part 2: Configure mail to flow from your email server to Office 365.

  5. You don't need connectors in the following scenarios unless there is a special requirement with one of your partners, such as enforcing TLS with a bank.

    • Sending mail from Office 365 to a partner organization

    • Sending mail from a partner organization to Office 365

NoteNote:
If your organization’s mail server has Exchange 2013 or Exchange 2010 deployed, we recommend that you use the Hybrid Configuration wizard to configure connectors in Office 365 as well as on your on-premises Exchange servers. For this scenario, your domain’s MX record can’t point to your organization’s mail server.

  • I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use the filtering and compliance solutions that are already in my on-premises environment. And all messages coming from the internet to my cloud mailboxes or messages sent to the internet from my cloud mailboxes need to route through my on-premises servers.

If you have business or regulatory reasons for filtering mail in your on-premises environment, we recommend pointing your domain’s MX record to Office 365 and enabling centralized mail transport. This setup provides optimal spam filtering and protects your organization’s IP addresses. For this scenario, your organization’s mail flow setup looks like the following diagram.

Mail flow diagram showing the scenario where your MX record points to Office 365 and filtering happens on your on-premises servers. Mail from the internet goes to Office 365 and then to your servers for compliance filtering and then back to Office 365.

  1. Add your custom domains in Office 365, and prove that you own the domains by following the instructions in Add users and domains.

  2. Create user mailboxes in Exchange Online or move all users' mailboxes to Office 365.

  3. Update the DNS records for the domains that you added in step 1. (Not sure how to do that? Follow the instructions on this page.) The following DNS records control mail flow:

    • MX record – Point your MX record to Office 365 in the following format: <domainKey>-com.mail.protection.outlook.com

      For example, if your domain is contoso.com, the MX record should be: contoso-com.mail.protection.outlook.com.

    • SPF record – This should list Office 365 as a valid sender, plus any IP addresses from your on-premises servers that connect to EOP, and any third parties that send email on behalf of your organization. For example, if your organization’s mail server’s internet-facing IP address is131.107.21.231, the SPF record for contoso.com should be: v=spf1 ipv4: 131.107.21.231 include:spf.protection.outlook.com –all

  4. Use Centralized Mail Transport (CMT) for on-premises compliance solutions.

    • Mail that comes from the internet to a mailbox in Office 365 first gets sent to your on-premises server, and then comes back to Office 365 to be delivered the mailbox. Line 1 represents this path in the scenario 2 diagram.

    • Mail that comes from Office 365 and is destined for the internet first gets sent to your on-premises servers, then comes back to Office 365, and then is delivered to the internet. Line 4 represents this path in the scenario 2 diagram.

    • To achieve this configuration, create connectors via the Hybrid Configuration wizard or via cmdlets, and enable CMT. For details about CMT, see Transport options in Exchange hybrid deployments.

You don't need connectors in the following scenarios unless there is a special requirement with one of your partners, such as enforcing TLS with a bank.

  • Sending mail from Office 365 to a partner organization

  • Sending mail from a partner organization to Office 365

  • I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use the filtering and compliance solutions that are already in my on-premises email environment. All messages coming from the internet to my cloud mailboxes or messages sent to the internet from cloud mailboxes must route through my on-premises servers. And I need to point my domain’s MX record to my on-premises server.

As an alternative to Scenario 2, you can point your domain’s MX record to your organization’s mail server rather than to Office 365. Some organizations have a business or regulatory need for this setup, but filtering typically works better if you use Scenario 2. For this scenario, your organization’s mail flow setup looks like the following diagram.

Diagram showing mail flow when your MX record points to your on-premises servers instead of Office 365. Mail goes from the internet to your organization's servers and then to Office 365. Mail goes from Office 365 to your on-premises servers to internet

If the MX record for your domain needs to point to your on-premises IP address, use the following best practices:

  1. Add your custom domains in Office 365, and prove that you own the domains by following the instructions in Add users and domains.

  2. Create user mailboxes in Exchange Online or move all users' mailboxes to Office 365.

  3. Update the DNS records for the domains that you added in step 1. (Not sure how to do that? Follow the instructions on this page.) The following DNS records control mail flow:

    • MX record – Point your MX record to Office 365 in the following format: <domainKey>-com.mail.protection.outlook.com

      For example, if your domain is contoso.com, the MX record should be: contoso-com.mail.protection.outlook.com.

    • SPF record – This should list Office 365 as a valid sender. It should also include any IP addresses from your on-premises servers that connect to EOP and any third parties that send email on behalf of your organization. For example, if your organization’s mail server’s internet-facing IP address is131.107.21.231, the SPF record for contoso.com should be: v=spf1 ipv4: 131.107.21.231 include:spf.protection.outlook.com –all

  4. Since you’re not relaying messages from your on-premises servers to the internet via Office 365, you don’t technically need to create connectors for the following scenarios. But if at some point you change your MX record to point to Office 365, you’ll need to create connectors, so it’s best to do it up front. In the Exchange admin center, use the connector wizard to Configure mail to flow from your email server to Office 365 for the following scenarios, or use the Hybrid Configuration wizard to create connectors:

    • Sending mail from Office 365 to your organization’s mail servers

    • Sending mail from your on-premises servers to Office 365

  5. To make sure that messages are sent to your organization’s on-premises servers via MX, go to Example security restrictions you can apply to email sent from a partner organization, and follow "Example 3: Require that all email from your partner organization domain ContosoBank.com is sent from a specific IP address range."

  • I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use the filtering and compliance solutions that are already in my on-premises email environment. All messages sent from my on-premises servers must relay through Office 365 to the internet. And I need to point my domain’s MX record to my on-premises server.

For this scenario, your organization’s mail flow setup looks like the following diagram.

Mail flow diagram with arrows showing mail from the internet to on-premises servers and then to Office 365. Also shows email travelling from on-premises servers to Office 365 to the internet.

If the MX record for your domain needs to point to your on-premises IP address, use the following best practices:

  1. Add your custom domains in Office 365, and prove that you own the domains by following the instructions in Add users and domains.

  2. Create user mailboxes in Exchange Online or move all users' mailboxes to Office 365.

  3. Update the DNS records for the domains that you added in step 1. (Not sure how to do that? Follow the instructions on this page.) The following DNS records control mail flow:

    • MX record – Point your MX record to your on-premises server in the following format: mail.<domainKey>.com

      For example, if your domain is contoso.com, the MX record should be: .mail.contoso.com.

    • SPF record – This should list Office 365 as a valid sender. It should also include any IP addresses from your on-premises servers that connect to EOP and any third parties that send email on behalf of your organization. For example, if your organization’s mail server’s internet-facing IP address is 131.107.21.231, the SPF record for contoso.com should be: v=spf1 ipv4: 131.107.21.231 include:spf.protection.outlook.com –all

  4. In the Exchange admin center, use the connector wizard to Configure mail flow using connectors in Office 365 for the following scenarios:

    • Sending mail from Office 365 to your organization’s mail servers

    • Sending mail from your on-premises servers to Office 365

    You need to create a connector to support scenario Sending mail from your on-premises servers to Office 365 if any of the following scenarios apply to your organization

    • Your organization is authorized to send mail on behalf of your client, but your organization doesn’t own the domain. For example, contoso.com is authorized to send email via fabrikam.com, which doesn’t belong to contoso.com.

    • Your organization relays NDRs (non-delivery report) to the Internet via Office 365.

    • The MX record for your domain, contoso.com, points to your on-premises server, and users in your organization automatically forward messages to email addresses outside your organization. For example, kate@contoso.com has forwarding enabled, and all messages go to kate@tailspintoys.com. If john@fabrikam.com sends a message to kate@contoso.com, by the time the message arrives at Office 365 the sender domain is fabrikam.com and the recipient domain is tailspin.com. Because mail is being forwarded, neither the sender domain nor recipient domain belongs to your organization.

    To create the connector, choose the first option in the connector creation wizard on the “How should Office 365 identify email for your email server” screen.

    Screenshot showing the New Connector screen of the Hybrid Connection Wizard for Exchange

    This allows Office 365 to identify your email server using the certificate. In this scenario, the certificate CN or Subject Alternative Name (SAN) contains the domain that belongs to your organization. For more details, see Identifying email from your email server. For connector configuration details see, Part 2: Configure mail to flow from your email server to Office 365.

  5. Set up connectors for secure mail flow with a partner organization to make sure that messages are sent to your organization's on-premises servers via MX.

  • I’m migrating my mailboxes to Office 365, and I want to keep some mailboxes on my organization’s mail server (on-premises server). I want to use a third-party cloud service to filter spam from the internet. My messages to the internet need to route through Office 365 to protect my on-premises servers’ IP addresses from being added to external block lists.

For this scenario, your organization’s mail flow setup looks like the following diagram.

Mail flow diagram showing mail from the internet going to a third-party service then to Office 365 and then to on-premises servers. Mail from on-premises servers goes to Office 365 then to the internet (bypassing the third-party service).

  1. Add your custom domains in Office 365, and prove that you own the domains by following the instructions in Add users and domains.

  2. Create user mailboxes in Exchange Online or move all users' mailboxes to Office 365.

  3. Update the DNS records for the domains that you added in step 1. (Not sure how to do that? Follow the instructions on this page.) The following DNS records control mail flow:

    • MX record – Point your MX record to your third-party service. Follow their guidelines for configuring your MX record.

    • SPF record – Because your domain’s MX record must point to a third-party service (in other words, you require complex routing), include the third-party service in your SPF record. Follow the third-party provider’s guidelines for adding them to your SPF record. Also add Office 365 and the IP addresses of your on-premises servers as valid senders. For example, if contoso.com is your domain name, the third-party cloud service IP address is 10.10.10.1, and your on-premises server IP address is 131.107.21.231, the SPF record for contoso.com should be: v=spf1 ipv4:10.10.10.1 ipv4: 131.107.21.231 include:spf.protection.outlook.com –all

      Alternatively, depending on the third-party's requirements, you may need to include the domain from the third-party instead like the following example: v= ipv4: 131.107.21.231 spf1 include:spf.protection.outlook.com include:third_party_cloud_service.com -all

Office 365 uses domains, like contoso.com, to route email messages. When you set up email in Office 365, you typically switch from the default domain that you got when you first signed up for Office 365 (the domain ending with .onmicrosoft.com) to your organization’s domain. Domain names, like contoso.com, are managed by using a worldwide system of domain registrars (for example, GoDaddy, HostGator, or Moniker) and databases called the Domain Name System (DNS). DNS provides a mapping between human-readable computer hostnames and the IP addresses used by networking equipment. If you’re new to DNS, we recommend that you read DNS basics. The following video provides you with a quick overview of some of the most important concepts about what DNS is and how it works.

Your browser does not support video. Install Microsoft Silverlight, Adobe Flash Player, or Internet Explorer 9.

In Office 365 mail flow, two DNS records are particularly important: MX records and SPF records.

MX (mail exchanger) records provide an easy way for mail servers to know where to send email. You can think of the MX record as a type of postal address. If you want Office 365 to receive all email addressed to anyone@contoso.com, the MX record for contoso.com should point to Office 365, and it will look like the following example:

Hostname: contoso-com.mail.protection.outlook.com
Priority: 0
TTL: 1 hour

SPF (sender policy framework) records are a specially formatted TXT record in DNS. SPF records make sure that only the organization that owns a domain is actually sending email from that domain. SPF is basically a security measure to make sure someone doesn’t impersonate another organization. (This impersonation is often called spoofing.) As a domain owner, you can use an SPF record to publish a list of IP addresses or subnets that are authorized to send email on your organization's behalf. This can be helpful if you want to send email from multiple servers or services with different IP addresses. The SPF record for an organization’s domain that uses Office 365 to send all their mail should look like the following example:

v=spf1 include:spf.protection.outlook.com -all
ImportantImportant:
You can only have one SPF record per domain. Having multiple SPF records will invalidate all SPF records and cause mail flow problems.

The SPF record configuration in the previous example tells the recipient email servers that email sent from Office 365’s IP addresses are authorized for the domain. Because most modern email servers look up a domain’s SPF record before they accept any email from it, it’s important to set up a valid SPF record in DNS when you first set up mail flow.

For the best mail flow experience–especially for spam filtering—we recommend pointing the MX record for your organization’s domain to Office 365. Spam scanning is the initial connection point to the Office 365 service. Who is sending the message, the IP address of the server that originally sent the message, and the behavior of the connecting mail server, all help determine whether a message is legitimate or spam. If your domain’s MX record doesn’t point to Office 365, the spam filters won’t be as effective. If your MX record doesn’t point to Office 365, there will be some valid messages that the service misclassifies as spam and some spam messages that the service misclassifies as legitimate email.

With that said, there are legitimate business scenarios that require your domain’s MX record to point to somewhere other than Office 365. For example, email destined for your organization might need to initially arrive at another destination (such as a third-party archiving solution), then route through Office 365, and then be delivered to mailboxes on your organization’s mail server. This setup may provide the best solution to meet your business requirements.

Whatever your needs, this guide will help you understand how your MX records, SPF records, and, potentially, connectors need to be set up.

 
Show:
© 2016 Microsoft