SPF Errors when Outbound Mails or DLP Security enabled

[Christoph_Hornu]

Environment: Check Point Harmony E-Mail & Collaboration with O365

Goal: Adding more security to outbound mails

Issue: After enabling DLP or activating the checkbox "Inline (outgoing) mail under Advanced Options" all mails fail SPF checks on the mail receiver side.

Therefore we opened a SR with TAC and received the following information about the Check Point mail servers that are used by Check Point for DLP:

• 52.17.62.50 eu-dlp.cloud-sec-av.com

As the issue also occurs without DLP as described above, there are obviously more sender domains to check the validity for SPF records. We'd like to avoid trial and error tests.

Is there an official documentation for this configuration or does someone have any experience to share on this topic?

Thanks for any tips or ideas!

@Igor_Moskowitz @Jonas_Reiter 

[Hasnainkhan]

In general, we do not recommend adding an outgoing IP address to the sender's SPF record because we prefer not to be visible to the public like traditional gateways. Sometimes, we suggest on a case-by-case basis that tenants use DLP or Inline for outgoing emails and face frequent SPF issues.

Here are some findings. In my experience, the results were different when I sent the same email to three different domain recipients and then sent it to outlook.com.

1. Gmail accepted the email, validated SPF as a pass, and detected no problem.
2. Yahoo accepted the email, validated SPF as a pass, and detected no problem.
3. Outlook accepted the email, validated SPF as a pass, and detected no problem.
4. Checkpoint accepted the email but not validated and instead considered the existing failed SPF for IP "3.214.204.181".

Gmail email status and SPF validated with the last sender MTA IP “40.107.237.106”



Gmail SPF status PASS with the last sender MTA IP “40.107.237.106”



Yahoo SPF status PASS with the last sender MTA IP “40.107.237.101”



Outlook SPF status PASS with the last sender MTA IP “52.100.173.235”



Checkpoint SPF status FAIL and the last MTA IP was “40.107.237.105” but SPF failed for “3.214.204.181”


Gmail recorded 2 “Received-SPF”, first from “3.214.204.181” (DLP/inline outbound IP) to protection.outlook.com and it failed but second from “40.107.237.106” (the last MTA) and google.com has validated as Pass.


Yahoo recorded only one “Received-SPF”, from “40.107.237.101” (the last MTA) and yahoo.com has validated as Pass.



Outlook recorded 2 “Received-SPF”, first from “3.214.204.181” (DLP/inline outbound IP) to protection.outlook.com and it failed but second from “52.100.173.235” (the last MTA) and outlook.com has validated as Pass.



Checkpoint has recorded only one "Received-SPF", which is “3.214.204.181” (DLP/inline outbound IP) to protection.outlook.com, and it failed. Despite detecting Effective-Source-IP (the last MTA) as "40.107.237.105", it considered the existing SPF header Received-SPF. It is possible that here the SPF validation is being done using a different method.



There is one thing common between all of these scenarios, and it is “X-MS-Exchange-Authentication-Results” where “spf=fail (sender IP is 3.214.204.181) smtp.mailfrom=xxxxxpportlab.onmicrosoft.com, DKIM and DMARC" which is expected since email is being returned to MSFT (O365) from xxxxxpportlab.onmicrosoft.com by IP 3.214.204.181. The results of email authentication checks for SPF, DKIM, and DMARC are recorded (stamped) in the Authentication-results message header in inbound messages.

Additionally, Gmail, Yahoo, and Outlook (public domains) have checked SPF records for sender domains with the last MTA IP address. At the same time, Checkpoint considered existing SPF records and ignored validating SPF records for the previous IP address of the MTA. The recipient's MX gateway checks SPF records to ensure they are valid using various methods.

As a result, it does not affect all DLP/Inline outbound emails, and we can consider advising tenants individually if it affects them. The outbound IP addresses are available in HEC Admin Guide, and can be added to the SPF records of affected tenants according to their tenants' data residency.


If you have any tenants having issues with SPF, please log a ticket so we can investigate the matter and respond appropriately.