2 zones in SPF but warning

My SPF record reads “v=spf1 include:domain1.com include:domain2.com ~all” but a warning is displayed atop the DNS Records page:

Required steps to complete zone set-up. The number of lookups on your SPF record exceed the allowed limit of 10. This will result in emails failing SPF authentication.

How do I determine if either domain has additional lookups? And is there a way to flatten this manually to avoid the warning?

Thanks

Anything that isn’t ip6: and ip4: in your SPF record will be “additional lookups”.

Each additional lookup can include even further additional lookups.

If you include Google’s “include:_spf.google.com”, that would be one look up on it’s own, but since Google’s “main” SPF then contains “include:_netblocks.google.com include:_netblocks2.google.com include:_netblocks3.google.com”, that would be 3 additional lookups, or to summarize, giving total of 4 lookups, even though you only included one.

You should NEVER use include:example.com in the SPF record that is residing on example.com’s own TXT record, as that would literally create a loop back to itself.

Or said in another way, if both of your domains, domain1 and domain2 contains the same SPF you’re listing above, they are literally looping back and forth between the two domains, causing an endless loop.

Sure.

Just remove all the useless stuff from your SPF record.

If you previously used Google to send messages on your behalf, but dropped them back in 2018, but still haven’t didn’t remove e.g. “include:_spf.google.com” from your SPF, then you need to clean up your SPF and remove it now.

Digging more in to your specific situation than the above, would require that you share your actual domain name(s).

2 Likes

Thanks for helping.

Let’s say the domain is DOMAINX.COM, which uses Microsoft for email and a different company for hosting the website, and the record is:

“v=spf1 include:hotmail.com include:webhost.com ~all”

domain1 is “hotmail.com” and domain2 is say “webhost.com” for the website - webhost.com sends some logs for the website to [email protected], and sends these from [email protected]

I have no clue how hotmail.com expands, but it’s probably a lot more than webhost.com

If you enter your domain into dmarcian’s SPF Surveyor, they will show you the full expanded contents of your SPF record.

2 Likes

Thanks. SPF Surveyor revealed that hotmail.com requires 7 lookups to evaluate the SPF record, and the webhost’s domain requires 20. The warning shown is:

   *Error! 27 DNS lookups required to evaluate the SPF record. The maximum is 10*.

The webhost’s domain has been deleted from the SPF record, but this is not a perfect solution. If the webhost always sent logs from the same mail server IP, then this could be added (up to three, I presume). Is this correct? Any tips on how to determine this?

The info at SPF Best Practices: Avoiding SPF Record Flattening - dmarcian and The Dangers of SPF Flattening - dmarcian are good reading.

1 Like

At 20 lookups, that record is unusable by anyone! That’s a new record in failure. I have seen an ISP record that had 10 lookups, which also will fail as an include: mechanism since that adds one lookup thereby pushing it over the limit.

1 Like

&&

include:hotmail.com might not be the right one to use, according to my understanding of your example.

include:spf.protection.outlook.com is (currently, at the time of writing this) only filled with ip6: and ip4: mechanisms, and as such, does not count for more than 1.

The latter one is the most typical one (if not the only one) to use, when you use e.g. Microsoft Office 365 / Outlook, with a custom domain.

Depending on how deep we go, it might not be 100% correctly understood:

If it is indeed from the same IPv6 and/or IPv4 address(es) all the time, you could technically add them as ip6: and ip4: mechanisms within your SPF.

In e.g. this one:

v=spf1 ip6:2001:db8:beef::/48 ip4:192.0.2.0/24 include:_spf.example.com -all

ip6:2001:db8:beef::/48 and ip4:192.0.2.0/24 does NOT count towards the total number of 10 lookups, as that limit only applies to mechanisms that require further DNS lookups (e.g. a, mx, include, exists, ptr, etc.)

Doing a such kind of workarounds, would however mean that you wouldn’t automatically be following your provider’s eventual future update of their SPF record, and as such, both the results as well as the potential consequences of The Dangers of SPF Flattening that you refer to, would apply for you.

In short words, your SPF might end up on becoming broken at any time, due to such workarounds.

With help from DMARC reports, you can determine which actual IP addresses (and sources) that are sending messages claiming to be from your domain name.

You would get reports for messages claiming to be from your domain name, regardless of if it is from a legitimate (e.g. your actual provider) or illegitimate source (e.g. fake, phishing, etc.).

Those reports aren’t … very human-readable though, and are better geared for automated systems to receive and parse though.

I’ve seen one in the 90’s some time, I believe 97 total lookups or so. :thinking:

But as long as only a minority (if any at all) that rejects emails from such broken set ups, there wouldn’t be any incentive to fix the broken set ups either (e.g. “if it ain’t broken, don’t fix it”).

2 Likes

There are “sub-sections” in the list, for lack of a better term. Some of the webhost’s sections and names refer to domains other than the webhost’s, the last of which is actually a google.com domain?!?! :confused:

Is it possible to just add a reference to one section? The MX section looks most like the mail servers that would be used, if the names are anything to go by.

Thanks for taking the time to write a helpful and comprehensive reply - much appreciated.

The mail server is the free outlook.com service, with a custom domain, created probably 20 years ago when it was still permitted for Hotmail users. I understand this has been withdrawn but will continue for those who already have it in place. Hence the inclusion of hotmail.com. I recently tried changing this to outlook.com and email delivery stopped, so it was reverted to hotmail.com

I’ll give include:spf.protection.outlook.com a try and see what happens though.

But that still leaves the webhost’s domain with 20 lookups, unless I can find a way to filter out a subset.

Thanks for you help

I see, that one would be different from the one I was referring to.

include:hotmail.com does however also include include:spf.protection.outlook.com, so even if you only reference include:hotmail.com, they will both be included in your SPF.

So with the new information, I would just forget that part with “moving” to include:spf.protection.outlook.com.

If you, like mentioned above, are able to figure out what kind of their include: (or other mechanisms) that are actually used to do the mail deliveries for you, you could be able to work around the issue, by taking individual items over to your own SPF.

Again, such actions would come with potential consequences, where your SPF could break over night.

If you could share the actual domain of the “webhost”, e.g. the one you referred to above as include:webhost.com, it might become possible to come with suggestions for potential workarounds.

There’s no real reason to withhold the webhost name: XNEELO

Is there anything that can be conspicuously singled out as the likely mail servers? I understand that if they change this could negatively impact SPF later, but it’s unlikely to be a total change of names and addresses - perhaps some additions or consolidation (it seems to need that).

And this is what’s shown for Hotmail:

That, and your screenshot confirms the suspicion I had above.

You’ve been using the wrong include: all along, for XNEELO.

How to add an SPF record - xneelo Help Centre

  1. Remove include:xneelo.com

  2. Add include:spf.host-h.net

That will reduce the amount of lookups required in your SPF record a lot, with the final result of just 11 lookups.

2 Likes

Thanks for the help. There’s no longer a warning on the Cloudflare DMARC Management Beta page, although SPF Surveyor does give a warning:

I’ll monitor the Cloudflare DMARC page to see what else shows up in the days ahead.

I’ve certainly learnt something from all the folks who’ve been kind enough to help here - thank you all.

1 Like

SPF Surveyor was still reporting 11 lookups and the Cloudflare DMARC page too.

And then I noticed that spf.host-h.net had two blocks, DE and SA, which I soon figured out were Germany and South Africa.

Changing the include to safilters.host-h.net and safilters1.host-h.net reduced the lookups to 9, and SPF Surveyor and the Cloudflare DMARC page are happy.

1 Like

If XNEELO is performing maintenance of the South African infrastructure, they could (even if just temporarily) be re-routing users, including e.g. your outbound email messages, to be passing through their infrastructure in Germany.

They could also do such kind of traffic (re-)routing, e.g. due to load balancing, or various other reasons in order to ensure service availability. In such cases, you might end up on having issues again, since your SPF record might be failing, since your SPF no longer contains the parts of include:defilters.host-h.net.

One thing worth remembering about DMARC reports, is that they are only sent when the sender of the reports (for example Google), has seen at least one message pretending to be from your domain reach their infrastructure.

So while monitoring would indeed be the correct approach, it shouldn’t not only just in the days ahead, but regularly, to ensure things “stays intact”.

That being said, -

The servers from include:defilters.host-h.net does actually send messages from .co.za domain names as well.

The only IPs logged against Xneelo on the Cloudflare DMARC page for now are:

image

This includes before the Xneelo “include” was trimmed.

“For now” is indeed the key here.

In order to attempt to be playing on the safer side (e.g. having them all), an alternative could be:

v=spf1 include:hotmail.com include:safilters1.host-h.net include:safilters.host-h.net include:defilters.host-h.net -all

It would be on 10/10, and no more lookups would possible without trimming( again), but as things are right now, you would have everything included.

Great suggestion, thanks - Cloudflare’s DNS admin page is happy with that (no warnings) and SPF Surveyor says that it makes it 10/10.

I do notice in Cloudflare’s DMARC Management console that for this domain the SPF Aligned is increasing. And there are two domains that are clearly spamming with my email addresses (dedipath & rainbow).

Microsoft does not implement DKIM in Outlook.com or just won’t give out the settings for users of free accounts with custom domains, so this remains zero - I have tried for a year to get the settings, but no help forthcoming or the people whom I reach in Support have been alive for fewer years than I’ve had this Hotmail custom domain setup and have no clue what I’m talking about.

Thanks again for your help

1 Like

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.