Implications of the SPF record for Exchange Online

​When using Exchange Online, configuring the SPF record is a must. Failing to do so will most certainly cause you problems with messages sent to some recipients, as any message that you send from your email will fail the SPF checks and can be marked as spam.

The value for the SPF record that Exchange Online recommends, which can be found under Domains -> View DNS Settings, is the following:

v=spf1 -all

This is fine, IF you are only going to use Exchange Online to send messages. For most enterprises however, this is not the case. And here is where the trouble starts. First of all, the ‘-all’ clause instructs the SPF validator to reject all messages coming from sources not included in the SPF record as spam. So, if there is at least one non-Exchange Online source of emails for your domain, make sure to either include them in the SPF or change the clause to “~all” (which will result in the more acceptable SoftFail).

The inclusion of another mechanisms is the other issue. There is a limit of maximum 10 DNS lookups per SPF record, which is intended to prevent Denial of Service attacks. Anything above 10 should result in PermError, causing you trouble. The “INCLUDE”, “A”, “MX”, “PTR”, and “EXISTS” mechanisms as well as the “redirect” modifier do count against this limit. The “all”, “ip4”, and “ip6” mechanisms do not require DNS lookups and therefore do not count against this limit.

So how is this an issue? Surely the counts for only one lookup? Not really, because once we look at the SPF records for that domain, we find the following:

v=spf1 -all

So, there are 4 more lookups there, and the domain contains 3 more. Overall, the innocent looking SPF record already has exhausted 8 of the 10 allowed lookups. Now, before you start pointing fingers at Microsoft, there are reasons behind this. They need to include a large list of IP ranges to make sure all the relevant Exchange Online servers are present into that single SPF include. And that’s a large list indeed, while in the same time it’s a very good idea to keep the length of a single record under 255 bytes. Could they have done a better job with it? Probably yes, and they did improve on it recently (previously they were using the one, which had 9 lookups!).

So, how to work around this? First of all, if you need 2 or less lookups, you will be able to add any relevant entries with no issues. Another option is to simply add an IP (range) instead of A or MX record, but that comes with the downside that you might have to change it if the corresponding IP is changed in the future.

In most cases 2 more lookups and adding few IP ranges should be good enough. But what if you need more still? You might consider ‘reworking’ the Exchange Online part by eliminating one or more lookups. For example, flatten the ‘third level’ entries ( This will not cause you any trouble now, but in the long run you will have to constantly monitor any changes made on these records by Microsoft and adjust the SPF record accordingly. For example, if they decide to remove the SPF record for, the “include” mechanism will now point to something non-existent, instantly invalidating the whole SPF record for your domain.

Forget about adding more than one SPF record, this will break things as well! What you can do instead is to create a subdomain and use it for Exchange Online mail. For example, you can have for your local servers, and for the Office 365 originating mail. Much like using two separate email providers.

A good resource to learn more about SPF is the SPF project site, or the Wiki page. And if you want to check the validity of your custom SPF record, this is the best validator I’ve found.

3 thoughts on “Implications of the SPF record for Exchange Online

  1. Tom Heitbrink says:

    Seems Microsoft has improved on their use of the SPF record, since nowadays the record is using less lookups:
    “v=spf1 ip4: ip4: ip4: ip4: ip6:2a01:111:f400::/48 ip6:2a01:111:f403::/48 -all”
    “v=spf1 ip4: ip4: ip4: ip4: ip6:2a01:4180:4051:0800::/64 ip6:2a01:4180:4050:0800::/64 ip6:2a01:4180:4051:0400::/64 ip6:2a01:4180:4050:0400::/64 -all”

    means now only 2 lookups where 8 used to be the number.

    1. Vasil Michev says:

      Well, it’s an old article. Things change rapidly in the cloud 🙂


Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.