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.

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

Converted esisting Email security to Mailflow with MS365

We've successfully setup Mailflow for our MS365 domain. We used the "copy existing MS365 Domains and Policies" and confirmed.

Mailflow seems to be working correctly after testing. All looking good. However I am curious what to do with the existing DNS settings that we've configured at our 3rd party DNS hosting for the old situation.

What happens to existing created records that are still pointing to the SOphos Hydra servers?

- MX

- SPF 

DO these servers need to be removed and MX reverted back to the initlal MS365 DNS from Microsoft?

I  have a hard time finding out if anything in DNS config is neccesary to revert or not.



Added tags
[edited by: Raphael Alganes at 6:08 AM (GMT -7) on 7 Jun 2023]
Parents
  • DNS MX records should all point to M365 and SPF should be updated as well to v=spf1 include:spf.protection.outlook.com -all and of course any other records you need in your specific SPF record. 

  • Thanks for the quick answer Tom. It would be my exact thoughts but thanks for clarifying.

    Now, is it by design that this appears in the "Message history": What we see are both entries for Gateway and Mailflow. Email is being delivered fine, no duplicates in mailbox.

  • The only messages you should see showing gateway are those that are still using the old mx record for delivery. Once everything has been switched to MFR you should delete the gateway section in Central Email settings so that only MFR exists. I imagine some servers might still be pointing to the old mx record or have it cached. 

  • Ok, i completely deleted the gateway from the Domain/Status section. Still showing some Gateway entries.

  • those are likely servers that have cached the old mx and or are configured directly pointing to the old record. They should clear up over time, if not you will need to investigate and if they are servers/applications under your control change the mail host or smarthost entry. If they are from external senders they will update cache over the next couple days, although it should be sooner propagation can take up to 72 hours for some DNS providers.

Reply
  • those are likely servers that have cached the old mx and or are configured directly pointing to the old record. They should clear up over time, if not you will need to investigate and if they are servers/applications under your control change the mail host or smarthost entry. If they are from external senders they will update cache over the next couple days, although it should be sooner propagation can take up to 72 hours for some DNS providers.

Children