4

We do SPF checks on our mail server, I have a incident where mail from MimeCast sometimes passes and then others fails the SPF check.

The domain in question's spf record states

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

If I do a whois on the IP it is a Mimecast IP

My question is how can I query _netblocks.mimecast.com to get a list of IPs so I can troubleshoot

MadHatter
  • 80,590
Sl33py
  • 165
  • I suppose you've ruled out dig txt _netblocks.mimecast.com (or just about any other DNS query tool) and following that down? – MadHatter Nov 22 '17 at 09:39
  • dig txt _netblocks.mimecast.com does not give me a list of ip's or at least not on my Centos 6 box – Sl33py Nov 22 '17 at 09:43
  • No, it gives you a list of included records, each of which you can then query with dig txt foo.bar.com until you get actual IPs; hence, "following that down". – MadHatter Nov 22 '17 at 09:44
  • Got you! thanks that work please add it as a answer so I can mark it – Sl33py Nov 22 '17 at 09:50
  • I'm not sure it justifies one, but I found I had a bigger point to make, so have done so. – MadHatter Nov 22 '17 at 10:03

1 Answers1

3

You have discovered that many organisations provide SPF records which are themselves made up of SPF records. When we do dig txt _netblocks.mimecast.com we get

;; ANSWER SECTION:
_netblocks.mimecast.com. 300    IN      TXT     "v=spf1 include:eu._netblocks.mimecast.com include:us._netblocks.mimecast.com include:za._netblocks.mimecast.com include:au._netblocks.mimecast.com ~all"

Each of those can then be looked up similarly, with eg dig txt eu._netblocks.mimecast.com to get the raw IP data:

;; ANSWER SECTION:
eu._netblocks.mimecast.com. 300 IN      TXT     "v=spf1 ip4:195.130.217.0/24 ip4:91.220.42.0/24 ip4:146.101.78.0/24 ip4:207.82.80.0/24 ip4:213.167.81.0/24 ip4:213.167.75.0/24 ip4:185.58.84.0/22 ~all"

Outlook's record is a bit more annoying (there's a surprise) in that it's nested:

[me@risby ~]$ dig txt spf.protection.outlook.com
[...]
spf.protection.outlook.com. 586 IN      TXT     "v=spf1 ip4:207.46.101.128/26 ip4:207.46.100.0/24 ip4:207.46.163.0/24 ip4:65.55.169.0/24 ip4:157.56.110.0/23 ip4:157.55.234.0/24 ip4:213.199.154.0/24 ip4:213.199.180.128/26 include:spfa.protection.outlook.com -all"

spfa in turn includes spfb, but that's the last one there, so you can stop digging.

The bigger problem is that this organisation, whoever it is, is getting perilously close to the ten-lookup limit. I count one for the original record, three for the outlook portion, and five for the mimecast portion; total, nine. If both outlook and mimecast add one more each, this organisation's stuffed. It may well know this, but I find that most organisations are sublimely unaware of the finer points of their own SPF record.

Which brings me to my bigger point: if you are thinking of publishing an SPF record, make sure you control your own email infrastructure. If you outsource it, someone else may well shoot you in the foot sooner or later, and your corporate email will become undeliverable because of a change you didn't make and don't know about. If you don't control all your own email, SPF probably isn't for you.

MadHatter
  • 80,590