locked
Receive Connector from Office 365 Best Practice? RRS feed

  • Question

  • We're looking to setup Exchange Hybrid with centralized transport. I seem to have incorrectly assumed the Hybrid Configuration Wizard would create the receive connector for my on-prem servers. I can obviously do this manually, but there's concern that with allowing all the required IP ranges in Exchange Online that someone else from a different tenant could send email directly to our on-prem Exchange servers.

     

    What are the best practices for receive connector Inbound from Office 365 and how can I ensure it will only allow mail from our Exchange Online tenant?


    • Edited by infinit_e Wednesday, February 12, 2020 10:31 PM
    Wednesday, February 12, 2020 10:25 PM

All replies

  • We're looking to setup Exchange Hybrid with centralized transport. I seem to have incorrectly assumed the Hybrid Configuration Wizard would create the receive connector for my on-prem servers. I can obviously do this manually, but there's concern that with allowing all the required IP ranges in Exchange Online that someone else from a different tenant could send email directly to our on-prem Exchange servers.

     

    What are the best practices for receive connector Inbound from Office 365 and how can I ensure it will only allow mail from our Exchange Online tenant?


    Info on how that all works and what you can do to help mitigate it

    https://techcommunity.microsoft.com/t5/exchange-team-blog/office-365-message-attribution/ba-p/749143

    AQ #3 – Does mail between Office 365 tenants always use MX records?

    Yes - except when we’re not expected to. Going back to our example, if a message is truly attributed to contoso.com initially, then when we’re ready to send the message to tailspintoys.com, we will absolutely look up the MX record.  However, there are some exceptions you should be aware of:

    1. Contoso.com can override the routing logic by creating an outbound connector for tailspintoys.com.  This case is the most obvious and is no different than Exchange’s (or any other SMTP server’s) routing logic.
    2. If the mail appears to already be incoming to tailspintoys.com, then we wouldn’t want to route it back out to the tailspintoys.com MX record.  This can happen if contoso.com doesn’t have a properly configured inbound connector. Without a proper connector, we see the message as incoming to tailspintoys.com.
    3. We also give each tenant an onmicrosoft.com address.  These addresses can always be used to route directly to Office 365, no matter where the MX record points (this is how cross premise mail flow works between on-premises and the cloud).

    If tailspintoys.com does not point their MX record to Office 365, they can tell Office 365 to reject messages which do not originate from the endpoint they want all mails to first route through (including onmicrosoft.com domains).  You can do this by creating an inbound connector something like this:

    New-InboundConnector –Name "Block delivery unless via MX record" -ConnectorType Partner -SenderDomains * -RequireTls:$true -RestrictDomainsToCertificate $true -TlsSenderCertificateName

    Or, if you prefer to use IP address instead of certificate:

    New-InboundConnector –Name "Reject mail not routed through MX" -ConnectorType Partner -SenderDomains * -RestrictDomainsToIPAddresses $true -SenderIpAddresses <static, full list of on-premises IPs, or IP ranges of third-party filtering service their MX may be pointing to>

    Note that by creating a connector like this will cause NDRs to be generated for messages which are submitted directly to your tenant and don’t match the certificate name you provide above.  Certificate is always the preferred method.  Whether you end up using certificates or IP(s), if either certificate or IP(s) changes, you will reject good messages.

    Wednesday, February 12, 2020 10:45 PM
  • Thank you for the reply, that was very informative. However I’m having some translating it to my case. Maybe I’m misreading something? I’m specifically concerned about Exchange Online to On-prem. Ideally, the only thing I want to receive in my on-prem servers from Exchange Online is internal corporate email. Is there anything I can do with my on-prem receive connector to filter connections from tenants other than my own?
    Thursday, February 13, 2020 2:40 AM
  • Yes you can do it via couple of connectors but you need lot of testing to avoid other O365 tenant sending mail to your EXO users

    read here

    https://practical365.com/security/how-to-ensure-your-third-party-filtering-gateway-is-secure/


    Vinny | Freelancer | Microsoft Certified Azure Solutions Architect Expert| Microsoft 365 Certified: Enterprise Administrator | Microsoft 365 Certified: Messaging Administrator Associate| ITILV3 | PMP

    Thursday, February 13, 2020 4:46 AM
  • Hi, I'm here to confirm with you if your issue has been resolved. If the problem is successfully solved, you can share your solution and mark them or the helpful reply as answer, this will make answer searching in the forum easier and be beneficial to other community members as well.


    Regards,

    Beverly Gao


    Please remember to mark the replies as answers if they helped. If you have feedback for TechNet Subscriber Support, contact tnsf@microsoft.com.

    Tuesday, February 18, 2020 1:19 AM