Ensure your SPF Record is Correct


Update: Feb 26, 2015 – A great post about Office 365 SPF checks was recently written by one of our program managers which I would high recommend reading. How Office 365 does SPF checks for customer-to-customer mail

 

I've recently seen an increase in cases that involve incorrectly published SPF records that have resulted in sent mail failing the SPF check. Ensuring your SPF record is up to date is great proactive work that can help prevent issues with SPF checks. In this article I'm going to go over how to properly set your SPF record if you are using Exchange Online or Exchange Online Protection.

There is also a common mistake that organizations sometimes make in their SPF record when they are smart hosting mail out through EOP which I will also highlight.

How does SPF Work?

SPF is a text DNS record that is published for a domain. This record lists all of the devices (typically by IP but there are other options) that are allowed to send mail on behalf of the domain. An SPF record can end in one of the following.

~all = If the SPF check fails, the result is a soft failure. Some mail systems may mark a message as spam if it has soft failed an SPF, but typically not.

-all = If the SPF check fails, the result is a hard failure. Most mail systems will mark an inbound message as spam if the SPF check results in a hard failure.

SPF is designed to help prevent spoofing. There are spoofing techniques that SPF cannot protect against, and this is where DMARC and DKIM come in. I'll be writing an article soon about this technology.

In EOP, if you would like inbound messages that hard fail an SPF check to be marked as spam, you can enable the following option in your content filter.

One way to view the SPF record of a domain is to type the following in a command window (remove the triangle brackets).

nslookup -type=txt <domain>

Configure your SPF Record

If you subscribe to Exchange Online and ONLY send mail out of the cloud mailboxes, your SPF record will probably look as follows.

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

If you are in a hybrid setup or use EOP without cloud  mailboxes, you will need to add the IPs of your on-premises edge mail servers to your SPF. In these situations, if outbound mail is being smart hosted through EOP, your SPF will probably look as follows. Here, 10.0.0.1 and 10.0.0.2 represent the IPs of the on-premises edge servers.

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

This next bit is very important. If you only take one thing away from this article, it should be this next paragraph.

Even if you smart host all of your outbound mail through EOP, you will still need to add your on-premises mail servers to your SPF record to ensure receiving partners SPF checks don't fail against your domain. I have seen some cases where organizations that smart host all of their outbound mail through EOP do not add their on-premises IPs to their SPF record and this has resulted in some SPF failures. It is very important that all devices that send mail on behalf of your domain are included in your SPF record, even if they smart host their outbound mail through EOP.

Resources

How Office 365 does SPF checks for customer-to-customer mail
Customize an SPF record to validate outbound email sent from your domain

Comments (5)

  1. Hi TecHMSP, not that it means much from me, but apologies for the problems it caused you. We recently published a new article on how EOP checks SPF for O365 customer to O365 customer mail flow. See

    http://blogs.msdn.com/b/tzink/archive/2015/02/26/how-office-365-does-spf-checks-for-customer-to-customer-mail.aspx.

  2. turbomcp says:

    Thanks
    very interesting refresh on spf
    waiting for next articles about DMARC and DKIM

  3. TecHMSP says:

    Thanks for changing the way EOP works without notifying any of your customers. I was having a lot of mail flow issues due the fact the email headers now report my internal IP as the sending IP instead of EOP.

  4. Tekena says:

    Hi,

    I followed exactly the steps you outlined here and the result is…sometimes SPF passes, other times (most times), it fails. Can it be made to pass every time? Thanks.

    Regards,
    Tekena

    1. If your SPF is setup correctly, you shouldn’t see intermittent behavior. I would start with headers from both messages that passed SPF and those that didn’t. See what the sending IP is in each of the headers, and ensure the sending IPs for the messages that fail are correctly entered in your SPF. Also ensure your SPF record does not contain more than 10 DNS lookups.

Skip to main content