SPF

To authorize Microsoft Office 365 to send emails on your behalf you will have to add it to your SPF record. The SPF record mechanism used for Office 365 is: 

include:spf.protection.outlook.com 

If Office 365 is your only sender your SPF record will look like the below example:

v=spf1 include:spf.protection.outlook.com ~all

NOTE: The only scenario for which you should not have to do anything is when you are fully hosted on Office 365 in which case everything will be set up for you by default. 

Scenario 1. Hybrid
In this scenario your mailboxes are on-premise and some on Office 365. In this case the SPF record will look similar to the example shown below, where the "ip4" mechanism is your on-premise server IP address and the "include" mechanism authorizes Office 365 to send emails on your behalf.

v=spf1 ip4:1.1.1.1  include:spf.protection.outlook.com -all

In this scenario you will need to create two connectors in Office 365. One for traffic from on-prem to Office 365 and one for traffic from Office 365 to on-prem.

Scenario 2. Hybrid + Third-party services
In this scenario you are sending mail from on-premise servers, Offie 365 and a third-party. So in the SPF record you need to authorise all sources of email.

v=spf1 ip4:1.1.1.1 include:spf.protection.outlook.com include:third_party -all

You will again need to create two connectors for mail flow between your domain and Office 365.

DKIM

In order to DKIM sign your custom domain emails you will need to complete the following steps:

  1. Sign in to Office 365 with your admin account and choose Admin.

2. Once in the Admin center, expand Admin centers and choose Exchange.

3. Go to protection --> dkim


4. Select the domain for which you want to enable DKIM and then, for Sign messages for this domain with DKIM signatures, choose Enable. Repeat this step for each custom domain.

Creating the CNAME records
The CNAME records are used to map an alias name to the true or canonical domain name. In essence when you provision a new domain name in Office 365 you will need to create two CNAME records for it so that it points to your initial domain. Here is an example:

We will use example.onmicrosoft.com as our initial domain, also called the tenant domain. But we actually own example.com and after we provision it in Office 365 we need to publish the two CNAME records so that example.com points to example.onmicrosoft.com using the format below.

NOTE:
If you are one of Office 365 US Government Community (GCC) customers, the domainGUID method below will not work for you. You will need to use the proper MX value for your domain. Example: selector1-<domain-key>._domainkey.<initialDomain> for the examples below. Use this article to find the MX record needed for your domain-key value.

Host name:			selector1._domainkey.<domain>
Points to address or value: selector1-<domainGUID>._domainkey.<initialDomain>
TTL: 3600

Host name: selector2._domainkey.<domain>
Points to address or value: selector2-<domainGUID>._domainkey.<initialDomain>
TTL: 3600

In our example the CNAME records will look like this:

Host name:			selector1._domainkey.example.com
Points to address or value: selector1-example-com._domainkey.example.onmicrosoft.com
TTL: 3600

Host name: selector2._domainkey.example.com
Points to address or value: selector2-example-com._domainkey.example.onmicrosoft.com
TTL: 3600

Please pay close attention to the domainGUID which does not use a full stop "." but a dash "-" instead. This is taken from the MX record of your custom domain, in this case example.com

The reason behind the two CNAME records is because Microsoft rotates the two keys for added security.

Enabling DKIM signing
Once you have added the CNAME records (two per domain) DKIM signing can be enabled through the Office 365 admin center or by using Windows Powershell.

For more information on how to configure DKIM in Office 365 please click on the button below.

Create a free OnDMARC account to test your configuration. 

Did this answer your question?