Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
RafaelSantiago
Participant
Jump to solution

SPF temperror and Unverified tag added to internal emails after integrating with Microsoft Office365

Recently we have integrated the Harmony Email solution with a customer's Microsoft Exchange environment.

After applying a Prevent (Inline) policy to some users, we started experiencing some internal mails (between users of the same domain) showing up on the users mailboxs with an unverified tag, assumingly added by Exchange.

Captura de ecrã 2025-07-23 093012.png

All of them are between users with Prevent policies applied to them in the Harmony Email config. Also when looking at the headers, all of them give an SPF:temperror DNS timeout. 

Authentication-Results: spf=temperror (sender IP is 52.212.19.177)
smtp.mailfrom=<customer_domain>; dkim=none (message not signed)
header.d=none;dmarc=temperror action=none
header.from=<customer_domain>;compauth=fail reason=601
Received-SPF: TempError (protection.outlook.com: error in processing during
lookup of <customer_domain>: DNS Timeout)

The IP it's trying to check is from Check Point, included in the spfa.cpmails.com domain.
We added this domain to SPF a while before changing the policy to Prevent.

As the name temperror indicates, this behavior with the Unverified tag, and the SPF temperror that comes with it, are very volatile. The customer has a big email volume, so we see it every day, but it doesn't happen with the majority of internal mails of users included in the Prevent policy.

For the emails that don't have the unverified tag, the SPF passes with exactly the same IP.

One possible justification for this could be issues with the customer DNS, but before adding the Prevent Policies (and before the Harmony Email solution) to the customers infrastructure, they had never seen this kind of behavior with unverified tags, and they also had never had any SPF related issues.

One other possible justification is problems with the spfa.cpmails.com domain, sometimes timing out when the Exchange tries to check the IPs included in their DNS configuration.

I asked the customer to add ipv4:52.212.19.177, to try to avoid having to check the spfa.cpmails.com domain and see if the unverifieds stop happening.

If it is, this customer can't be the only one suffering with this issues.

For other customers that use Harmony Email in Prevent, have their data residency in the EU, and see the IP 52.212.19.177 on SPF (from what I have seen, in the EU, multiple IPs can be used but in this scenario I have only seen this one), has anyone been having this kind of issues with SPF?

Infinity Portal tenants residing in Europe

  • 52.17.62.50

  • 52.212.19.177

  • 3.252.108.160/28

  • 13.39.103.0/28

  • 13.39.103.16/28

  • 3.252.108.176/28

 

Thank you for your attention.

Regards,

Rafael Santiago

 

 

 

2 Solutions

Accepted Solutions
RafaelSantiago
Participant

Hi everyone,

We have added the ip4:52.212.19.177 on the SPF of the customer's domain, and since then no more unverified emails appeared.

I'm pretty confident this is a problem with the domain spfa.cpmails.com propagation and or response throughout DNS. I am trying to address this issue with Check Point TAC, but in the meantime this seems to be a valid fix.

Thanks once again to @ToffenDask, definitely helpfull to know we were not the only ones experiencing this.

Regards

Rafael Santiago

View solution in original post

(1)
ToffenDask
Contributor

Apologies for the late reply. We had indeed done something just like that earlier - we added include:spf.protection.outlook.com to our record to resolve a similar issue. It somewhat defies the purpose of having Check Point manage our SPF entries if we need to add multiple exceptions.

View solution in original post

0 Kudos
(1)
4 Replies
ToffenDask
Contributor

Yes, we noticed this intermittent time-out issue from Microsoft towards 52.212.19.177 after we switched to having SPF managed by Check Point. We raised a ticket with Harmony support in early June but were basically brushed off with "you would need to engage with Microsoft as the means to gain that information would not be available to us given that this occurred in the Microsoft environment".

Life's too short for us to raise tickets with MS if it can be avoided - we can live with this as it's only affecting us very intermittently (and the only negative effect appears to be an "Unverified" banner in Outlook). If I were an MSP support this solution for customers I would chase this to the bottom, though - Check Point should definitely be stepping up.

 

RafaelSantiago
Participant

Hi @ToffenDask 

Thanks for the quick reply.

I have a case opened with Check Point support but I'm also not seeing it go very far.
Have you tried to put ipv4:52.212.19.177 on your SPF configuration, to see if the time out happens when Microsoft tries to communicate with spfa.cpmails.com domain, to see their IPs?

I'm not 100% sure, but I assume that if we put ipv4:52.212.19.177 first thing in the SPF config, then Exchange just sees that that IP is allowed to send mails from your domain, and doesn't give temperror. 

Either way I'll test that with the customer and report back if it fixes it.

I have tried creating some allow rules in the Tenant Allow/Block Lists, on Microsoft Exchange config but haven't been able to make the tags stop showing up from the Exchange side.

Regards

Rafael Santiago

0 Kudos
RafaelSantiago
Participant

Hi everyone,

We have added the ip4:52.212.19.177 on the SPF of the customer's domain, and since then no more unverified emails appeared.

I'm pretty confident this is a problem with the domain spfa.cpmails.com propagation and or response throughout DNS. I am trying to address this issue with Check Point TAC, but in the meantime this seems to be a valid fix.

Thanks once again to @ToffenDask, definitely helpfull to know we were not the only ones experiencing this.

Regards

Rafael Santiago

(1)
ToffenDask
Contributor

Apologies for the late reply. We had indeed done something just like that earlier - we added include:spf.protection.outlook.com to our record to resolve a similar issue. It somewhat defies the purpose of having Check Point manage our SPF entries if we need to add multiple exceptions.

0 Kudos
(1)

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events