We ran into the same issue now. We cannot send mails to our bank becuase they are using this service and do their own spf check.
Whitelisting the whole symantec cloud is not an option for us because this opens too many "holes".
Symantec rewrites the "received from" fields in the mail header and replaces them with their own. This not only causes spf to fail it also
is a clear violation of rfc1523!
Then requesting the receiver and/or sender to remove or open security features to work around is not the correct way!
rfc 1523 clearly states in 3.7.1 that received from fields in header must not be removed or rewritten. It is only possible to add a new one.
Original Message:
Sent: 11-08-2016 07:37 AM
From: Mark Sutcliffe
Subject: Symantec.cloud modifies Sender IP and causes SPF fail
Hi Mike,
We recommend that all clients using our email service include our record in their SPF record if they implement one even if they don't route their outbound email via us. There is more information in the below article
https://support.symantec.com/en_US/article.TECH226211.html
Our record is include:spf.messagelabs.com
We don't recommend using "MX" just the above record.
You are correct in that this should work however the example given at the beginning of this thread by Phillip was a non symantec.cloud client domain sending to him and then this being forwarded to office 365 and the email falling foul of the Office 365 SPF check then whitelisting our IP ranges in Office 365 would be the best course of action as a non-client would be unlikely willing to add our SPF record which is understandable.
Our IP range document can be found below,
http://imageserver.messagelabs.com/EmailResources/ImplementationGuides/Subnet_IP.pdf
Kind regards,
Mark