Sophos Email customers using IP-based mailflow rule connectors must migrate to certificate-based configuration by March 31st. To see if you're affected Click Here.

Thread Info
  • State Verified Answer
  • +3 person also asked this people also asked this
  • Locked Locked
  • Replies 20 replies
  • Subscribers 21 subscribers
  • Views 16124 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

New Mailflow setup

Mark Stringer

I see the new Mailflow functionality is appearing in my Cloud Portal as a released feature. In the help it states:

Sophos Mailflow doesn't currently support the following:

What do you mean by it does not support TLS? What elements of the email transmission are not encrypted using TLS connections exactly?

After switching to the Mailflow method from the Gateway method do I also need to:

1. Remove the Bypass Exchange Online Protection in Microsoft 365 rule in O365 Mailflow Rules?

2. Remove the Secure Connector between Microsoft 365 and Sophos Gateway?

Will the new Mailflow method remove the Sophos Banners on my emails when I reply to them as part of the Outbound process?

Thanks,

Mark.



Edited tags
[edited by: Raphael Alganes at 6:04 AM (GMT -7) on 7 Jun 2023]
Parents
  • +1

    I enabled this recently and had a lot of issues with valid inbound users showing as unverified users due to spf fails because gmail and other common domains don’t designate our custom outlook domain as a valid sender. When Microsoft forwards the email to Sophos, Sophos checks the spf for gmail.com and gmail doesn’t have our outlook domain as a designated sender.

    I also noticed issues with emails going to quarantine on the Microsoft side and bypassing Sophos entirely. The way Microsoft handles redirects to aliases bypasses the forwarding to Sophos. I could see in our message traces in exchange that the emails were being routed to the Sophos connector but when you check for the email in Sophos, a log doesn’t exist. Even when I setup the onmicrosoft.com domain in Sophos Mailflow, I experienced the same issue.

    I opened a ticket with Sophos on this and was informed by support that they haven’t been trained on Mailflow because it’s still in EAP which makes me wonder why I’m being prompted to set it up in Sophos central; I’m not registered for the Mailflow EAP either. Doesn’t seem fully baked at this point and the issue with spf fails and unverified users needs to be addressed before we can migrate fully to Mailflow. I like the idea though and definitely seems more efficient than redirecting MX. Following this thread to see if others have similar issues. 

  • 0 in reply to Caleb Terry

    It went GA on Feb 28th so no longer in EAP which would explain why you are being prompted to configure it. Since with Mailflow configuration SPF and DKIM have to be aligned in M365 or with whomever handles your DNS records, have you changed those to reflect the new configuration since the MX now points to protection.outlook.com? The emails going to quarantine on the Microsoft side likely have to do with still having EOP in the mix. I found that there were plenty of FP when I left EOP turn on, once I turned off / set the M365 SCL to -1 that stopped happening and messages were no longer misclassified by M365 and put in the junk folder. If you send me the ticket number I'll ask someone to dig a bit deeper.

Reply
  • 0 in reply to Caleb Terry

    It went GA on Feb 28th so no longer in EAP which would explain why you are being prompted to configure it. Since with Mailflow configuration SPF and DKIM have to be aligned in M365 or with whomever handles your DNS records, have you changed those to reflect the new configuration since the MX now points to protection.outlook.com? The emails going to quarantine on the Microsoft side likely have to do with still having EOP in the mix. I found that there were plenty of FP when I left EOP turn on, once I turned off / set the M365 SCL to -1 that stopped happening and messages were no longer misclassified by M365 and put in the junk folder. If you send me the ticket number I'll ask someone to dig a bit deeper.

Children
  • 0 in reply to Tom Foucha

    Tom,

    Our SPF and DKIM are aligned with Microsoft with each of our domains. Our MX records for each domain are pointed to the custom domain that Microsoft 365 provides:
    <domain>-com.mail.protection.outlook.com

    We weren't using Sophos Email Gateway before and this was a brand new setup. I will agree that EOP was probably still in the mix yet when Sophos Mailflow configures itself, it creates the spam filter bypass rule which sets everything inbound to -1 and also creates an enhanced filter that smart detects the last IP in the header.

    Even the Sophos test email was failing SPF and getting flagged as an unverified user in Outlook:

    Authentication-Results: spf=permerror (sender IP is 198.154.181.194)
    smtp.mailfrom=sophosemail.com; dkim=none (message not signed)
    header.d=none;dmarc=none action=none
    header.from=sophosemail.com;compauth=fail reason=001
    Received-SPF: PermError (protection.outlook.com: domain of sophosemail.com
    used an invalid SPF mechanism
    Received: from mfid-usw2.prod.hydra.sophos.com (198.154.181.194) by
     SN1NAM02FT0063.mail.protection.outlook.com (10.97.5.98) with Microsoft SMTP

     

    The case number is 04964707. I was informed by the engineer yesterday that it was still in EAP so forgive me for being misinformed. 

    I also reached out to our CSP and an Inside Sales Engineer from Sophos said that Mailflow was still in EAP and won't go GA until end of this qtr/start of next qtr and that email was sent to me today. 

  • 0 in reply to Tom Foucha

    I replied with information regarding the issues we experienced but it got flagged as spam in here.

    Here's the case:
    04964707

    As of yesterday, the engineer I spoke with told me that Mailflow was still in EAP and they weren't supporting it yet. Another inside sales engineer from Sophos sent me this in an email today:

    Thu 3/3/2022 12:02 PM

    The new feature message is auto set to display for a certain amount of time, and cannot be removed. I will stop showing after a certain period they set.

    As for full GA of mailflow, it is set to be at the end of this qtr/start of next qtr.

     

  • 0 in reply to Caleb Terry

    No worries, seems like the support engineer is not up to date. https://news.sophos.com/en-us/2022/03/03/say-goodbye-to-mx-records-with-sophos-email/ :) Since I'm the Sr. Director for Central Email, basically I own the product here at Sophos, I can assure it is now GA. I will ask someone to dig into the case. Feel free to send me an email if you like to, thanks for being a Sophos Email customer. How's that for getting our attention Slight smile

  • 0 in reply to Tom Foucha

    Sounds like the right person is involved now :) Thanks, Tom. I appreciate you for responding so quickly and looking into the issue.

    I'll be happy to give Mailflow another try as I prefer that method over the MX redirection. Huge Sophos fan btw. Chose you guys over Bitdefender and Trend Micro. 

  • 0 in reply to Caleb Terry

    I run my personal domain through MFR, I just sent a message from my gmail.com through MFR with no issues. Yes you will see a softfail but you will also find an SPF=pass in the headers. example:

    Authentication-Results-Original spf=pass (sender IP is 209.85.128.49) smtp.mailfrom=gmail.com; dkim=pass (signature was verified) header.d=gmail.com; dmarc=pass action=none header.from=gmail.com; compauth=pass reason=100

    later in the conversation you will see this one which is M365 saying we aren't permitted to send on behalf of gmail as you noted.

    Authentication-Results spf=softfail (sender IP is 104.47.57.177) smtp.mailfrom=gmail.com; dkim=fail (body hash did not verify) header.d=gmail.com;dmarc=fail action=none header.from=gmail.com;compauth=fail reason=001

    One of the reasons why I find it important to turn off EOP because EOP will trigger on this failure (softfail) and dump it into the junk folder as an unauthenticated message (based on my testing).

    I looked at the ticket in our system and I'd hope you give it a shot but please make sure you update your SPF records. My SPF for my home domain:  v=spf1 include:spf.protection.outlook.com -all

  • 0 in reply to Tom Foucha

    Case 05134281 is the same SPF issue.  I don't see a way out of the SPF issue because domains that do not use O365 and do not use SOPHOS will always get flagged as 'unverified' because of the SPF record of the sending domain will never include O365 or SOPHOS netblocks. 

  • 0 in reply to Tom Foucha

    Sending domains with a strict SPF record, that do not use O365, will not pass the SPF test resulting in an 'unverified sender' banner.

Unfiltered HTML