locked
Teaming Send and Receive connectors RRS feed

  • Question

  • Hi all,

    We have a newly built Exchange 2016 server running in co-existence with an Exchange 2010 server. We have default send and receive connectors setup and they're all working 100%. We also have an Anonymous Relay receive connector setup which is also working well.

    Our outgoing mailflow goes through MailRoute. We have a legacy system in house that sends mails to customers from random domains (i.e. it's not coming from our domain name), and this is now a problem as MailRoute only allows mails from your domain. 

    Is there a way that we can team a receive connector (coming from that specific server) to a send connector that send to MX and not to MailRoute as a smarthost? Or could there possibly be another way to resolve this on Exchange 2016?

    Thanks in Advance!


    Quintus du Bruyn

    Wednesday, May 11, 2016 11:02 AM

All replies

  • Hi all,

    We have a newly built Exchange 2016 server running in co-existence with an Exchange 2010 server. We have default send and receive connectors setup and they're all working 100%. We also have an Anonymous Relay receive connector setup which is also working well.

    Our outgoing mailflow goes through MailRoute. We have a legacy system in house that sends mails to customers from random domains (i.e. it's not coming from our domain name), and this is now a problem as MailRoute only allows mails from your domain. 

    Is there a way that we can team a receive connector (coming from that specific server) to a send connector that send to MX and not to MailRoute as a smarthost? Or could there possibly be another way to resolve this on Exchange 2016?

    Thanks in Advance!


    Quintus du Bruyn

    No, there isnt a way to "tie" them together. If its not required that you go through MailRoute for those messages sent from the legacy system, why not simply send them directly out to the internet and avoid Exchange all together? Note that sending as other domains from your own will probably land your sending IPs on blocklists and not make it past most anti-spam systems.

    Another option is 3rd party software that will allow you choose what send connector to send out based on some criteria:

    http://ivasoft.com/routebysender2013.shtml


    Blog:    Twitter:   

    • Proposed as answer by Allen_WangJF Thursday, May 12, 2016 9:39 AM
    Wednesday, May 11, 2016 11:16 AM
  • Hi Andy,

    Thanks for that! Is it possible to create either a send connector to MX DNS and specifying the source server (i.e. via powershell); or to create a receive connector and specifying MX DNS as destination via powershell?

    Thanks again!


    Quintus du Bruyn

    Thursday, May 12, 2016 9:43 AM
  • Hi Andy,

    Thanks for that! Is it possible to create either a send connector to MX DNS and specifying the source server (i.e. via powershell); or to create a receive connector and specifying MX DNS as destination via powershell?

    Thanks again!


    Quintus du Bruyn

    No, not with on-prem Exchange. You would need to use the software linked above or use EOP in Office 365 and apply conditional transport rules. 


    Blog:    Twitter:   

    Thursday, May 12, 2016 11:46 AM
  • Yes You Can create different send connector with different name space and route emails to different smart host or DNS, 

    sachin hodge

    Thursday, May 12, 2016 1:45 PM
  • Yes You Can create different send connector with different name space and route emails to different smart host or DNS, 

    sachin hodge

    If hes trying to route based on a source, then that is not possible. You can only create send connectors that route based on destination SMTP Address Spaces.


    Blog:    Twitter:   

    Thursday, May 12, 2016 1:50 PM
  • Yes we can add source server Names into send connector and different SMTP Name space

    sachin hodge

    Thursday, May 12, 2016 3:24 PM
  • Yes we can add source server Names into send connector and different SMTP Name space

    sachin hodge

    The source server in Exchange is one running the transport service. The poster is trying to route based on the server that is sending the mail, not the source transport server.

    Blog:    Twitter:   

    • Proposed as answer by Allen_WangJF Tuesday, May 17, 2016 1:55 AM
    Thursday, May 12, 2016 4:43 PM
  • Hi all,

    Thanks for all your replies. From what I'm seeing then, it seems that it won't be possible to achieve my goals with Exchange alone and 3rd party tools will need to be considered to get the job done, which isn't really ideal.

    Thanks again for all your advice!


    Quintus du Bruyn

    Friday, May 13, 2016 9:20 AM