All Collections
Microsoft Office 365
Microsoft Office 365 SPF and DKIM set up
Microsoft Office 365 SPF and DKIM set up

Follow these instructions to set up your DKIM and SPF record for Office 365.

Ivan Kovachev avatar
Written by Ivan Kovachev
Updated over a week ago

SPF is incorporated as a TXT record within your DNS provider, serving the purpose of designating authorized mail servers eligible to send emails on behalf of your domain. When a recipient mail system receives a message from your domain, it references the SPF TXT record to ascertain whether the message originates from an authorized messaging server, and it also checks that the return-path domain matches the domain in the from (called SPF alignment). This mechanism ensures a secure and trustworthy email delivery process for your domain.

Set up your SPF record for Office 365

To authorize Microsoft 365 (formerly Office 365) to send emails on behalf of your domain you will have to add it to your SPF record. The SPF record mechanism used for Microsoft 365 is: <-- this part allows all Office 365 IPs to send emails on your behalf.

If Microsoft 365 is your only legitimate source of emails, your SPF record should look like the below example:

v=spf1 ~all

If you already have an existing SPF record such as:

v=spf1 ~all

and you would like to add Office 365 as an additional sending service, you will have to copy the include and append it to your current SPF record. The final SPF record should look like this:

v=spf1 ~all


You should only have one SPF record per domain/subdomain.

If you decide to use Dynamic SPF, and get a warning in your Microsoft 365 portal about your SPF record being invalid, read the article we created about why it happens and why it's safe to ignore.

Set up your DKIM for Office 365

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

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 Microsoft 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 as our initial domain, also called the tenant domain. But we actually own and after we provision it in Office 365 we need to publish the two CNAME records so that points to using the format below.

If you are one of Microsoft 365 US Government Cloud (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:
Points to address or value:
TTL: 3600

Host name:
Points to address or value:
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

The reason behind the two CNAME records is that 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 Microsoft 365 Security admin center at

Check if DKIM is configured correctly

Why not use our free Investigate tool to swiftly verify your DKIM configuration? 

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 and get started with a 14-day trial. 

Did this answer your question?