Email Security.cloud

 View Only
  • 1.  Symantec.cloud modifies Sender IP and causes SPF fail

    Posted Nov 02, 2016 07:40 AM

    We have Symantec.Cloud on a number of sites and a potential issue has just been highlighted. A client of ours who does not use Symantec.Cloud (yet) has a valid SPF record setup and when he sends an e-mail to my personal Yahoo account it passes the SPF check with:

    Received-SPF: pass (domain of cmauk.co.uk designates 209.85.217.181 as permitted sender)

    However when he e-mails our work account it gets scanned by Symantec.Cloud and then passed on to our Office 365 setup and when it reached there the SPF fails:
     
    Received-SPF: SoftFail (protection.outlook.com: domain of transitioning
     cmauk.co.uk discourages use of 195.245.230.39 as permitted sender)
     
    Now as you can see the IP address has changed from 209.85.217.181 his Google IP to 195.245.230.39 a messagelabs IP and it fails the SPF check. It's not a big issue in our case as we can whitelist him but this must be happening to other clients all over the world where Messagelabs changes the IP and anything doing a SPF check behind it will cause a fail.
     
    Is there anything that can be done to stop this change of IP address?
     
     


  • 2.  RE: Symantec.cloud modifies Sender IP and causes SPF fail
    Best Answer

    Posted Nov 03, 2016 04:18 AM

    Hi Philip.

    If you are using symantec.cloud for your inbound email then the only place an SPF check should take place is within our service. This can be done on the portal. This is because all emails scanned by us will be sent to your office 365 and will always show our IP's as the sending IP.

    Please do let me know if you require any further information concerning this matter.

    Kind regards

    Kevin Brosnan



  • 3.  RE: Symantec.cloud modifies Sender IP and causes SPF fail

    Posted Nov 03, 2016 11:21 AM

    Thanks for the response Kevin but ticking the SPF check in the portal won't stop Office 365 from doing it's own SPF check once it has been passed will it? Or any other mail platform that comes after Symantec like Google or on premise Exchange.

    I understand the SPF can take place in Symantec it's how you then stop the mail platform that comes after it from generating the SPF fail as per the above example when it carries out it's own test. Or is the guidance to try and prevent the platform that comes after Symantec from carrying out it's own SPF/spam test in which case are there any guides for common platforms?



  • 4.  RE: Symantec.cloud modifies Sender IP and causes SPF fail

    Posted Nov 04, 2016 08:17 AM

    Hi Philip,

    When using our service you need to ensure that you configure the Office 365 not to use SPF checking. If you want to use SPF checking then it should be used in the portal where we will check the SPF then pass the email on to Office 365 as per your inbound routes.

    Kind regards

    Kevin Brosnan



  • 5.  RE: Symantec.cloud modifies Sender IP and causes SPF fail

    Posted Nov 04, 2016 09:44 AM

    Hi Philip,

    I just wanted to add on to what Kevin has said to answer to the question "are there any guides for common platforms?"  It can be difficult for us to say as such systems can change at any time and we wouldn't be aware.  My recollection from the last time I was in Office 365 is that there isn't an option to specifically disable the check.  You might need to whitelist our IP ranges.  Office 365 support would be able to give you the best details.

    It is simply one of the basic issues of SPF, any kind of relay server will break authentication.  We are not changing anything abotu the email; the original sender IP remains the same. However, SPF checks are not performed against original sender IP, they are performed against the IP of the server currently passing the email into the server doing the SPF check. As we are the entry point to your system, it will always be our IPs passing to Office 365. Essentially, performing an SPF Check after the mail passes the MX Record server, will result in a fail; it is not specific to our service being in place.  If Office 365 passed the message to a physical server on your end and that server was doing an SPF, then it would reject the mail too.



  • 6.  RE: Symantec.cloud modifies Sender IP and causes SPF fail

    Posted Nov 04, 2016 10:15 AM

    Thanks for the clarification guys appreciate it.



  • 7.  RE: Symantec.cloud modifies Sender IP and causes SPF fail

    Posted Nov 07, 2016 09:08 AM

    idea--  in the DNS TXT record for the domain,  in the SPF area (  v=spf1 mx  ) , add the Include for ML.

    like this---  include:spf.messagelabs.com 

    When O365 does the SPF check, it should see the ML addresses.

    Will that work OK ?

    Thanks

    =====



  • 8.  RE: Symantec.cloud modifies Sender IP and causes SPF fail

    Broadcom Employee
    Posted Nov 08, 2016 07:38 AM

    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



  • 9.  RE: Symantec.cloud modifies Sender IP and causes SPF fail

    Posted Apr 27, 2020 01:26 PM
    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.