Configuring Office 365 to help in the battle against phishing and spam

by | Sep 27, 2017 | Security | 0 comments

Battling spam and curbing phishing attacks seem to be continual challenges for many organizations. While there are many technical controls to help fight the good fight, end users are largely responsible for handling junk mail and keeping a watchful eye out for the evil that lurks within email messages.

There are many products that front-end mail gateways to help identify spam and possible phishing messages.  These systems rely on a variety of algorithms, keywords, and DNS settings to determine the legitimacy of those messages and the originating systems.  Last week, NIST published an initial draft of SP800-177 ( which gives recommendations and guidelines for enhancing trust in email. This blog highlights a few of the DNS settings (SPF, DKIM and DMARC – mentioned in Chapter 4) you should make to your environment to help improve your score so that legitimate mail doesn’t get flagged by other organization’s email systems. This blog is relevant to any email system, but the examples focus on Office 365.

A word of caution – as many articles on the internet espouse, implementing these settings aren’t entirely foolproof in identifying spam or fraudulent email.

There are many articles on the internet that can get into the technical details of SPF, DKIM and DMARC, but essentially, here is the breakdown:

SPF – This is a domain name record that specifies a list of IP addresses that are authorized to send email on behalf of your domain (including your main email server or any other senders you authorize)

DKIM – With DKIM enabled, each email message is sent from your domain with a digital signature in the header of the message.  The receiver makes use of your public key to decrypt it and validate that the message did, in fact, come from the domain it said it was coming from.

DMARC – This is an additional protection mechanism that works in tandem with SPF and DKIM to further identify and handle email that may be fraudulent.  The key to DMARC is that you need to have SPF and DKIM configured and working first, so make sure you get those two functioning right away.

In order to configure your Office 365 tenant, Microsoft has produced three TechNet articles on how to implement SPF, DKIM and DMARC:




Some of the information in the above articles may seem daunting for an administrator and especially a small business owner. Let’s face it, you probably decided on Office 365 because you could administer much of your email system without the need for a computer guru, so I thought I would share some of the settings as they were implemented with my GoDaddy account.  Keep in mind that if you are using a separate SPAM filter, or other email metering/monitoring/archiving system, these settings will likely be different.


In order to implement DKIM and DMARC, we will need some additional information.  In the next screen shot, you will see an MX record.  Take note of everything prior to

This information will be used in building the DKIM and DMARX DNS entries:

SPF Record 

The SPF record is probably the easiest – there is nothing specific to the tenant when setting this up.  Keep in mind that this example is for Office 365 only and if you have external services (such as marketing via SalesForce or ConstantContact) or an on-premises server, the DNS entry would be much different:


To get DKIM set up, you will need to add the following CNAME records. You will need to set up this set of records for each custom domain name you have pointing to your tenant.  In this example, I only have one.  As you can see, I am using the information I gathered from my MX record to complete the first part of the record.  The second part of the record is your tenant ID:


DMARC is the last one.  I had trouble inputting the information into GoDaddy’s interface – specifically relating to the semi-colon placement.  In this example, there is only one semi-colon in the middle and no semi-colon at the end.  GoDaddy gives an error when trying to insert the trailing semi-colon.  The following is a typical DMARC record set to reject email that doesn’t pass the SPF and DKIM tests. You may want to initially experiment with this by putting DMARC in monitor mode (p=none) and set up a RUA address to capture emails that failed the DMARC check to make sure email that is getting rejected should be. If you want to experiment with some of these settings, I found this great website to help generate the right DMARC record for your needs:

Making changes to your DNS records can have a negative impact on mail flow, so proceed with caution and check each step to make sure your intentions are producing what you are expecting. As a reminder, if you have spam filtering and other email handling (inbound or outbound), your settings will likely be different.  Peters & Associates has expertise to help with any of these settings – especially in complex environments.  If you are interested in discussing further, reach out to us at or 630.832.0075. We’re ready to help!