none
Internal mails ending up going to send connector

    Question

  • Hi

    We're experiencing a weird problem that I need a little help troubleshooting.

    We host customers on our Exchange 2013 servers (1 CAS + 1 MBX) and some of those customers need to send all their emails to specific smarthosts. So we have configured a 3rd party product called RouteBySender from Ivasoft which creates sendconnectors that we can target with securitygroups so that members of those groups send all external email to the smarthosts configured on the sendconnectors. If users send internal mail to other users on our server the mails are delivered internally without going through the smarthosts. This I believe is the way it is supposed to work.

    The above configuration works fine for all but one maildomain. Let's call it faultingdomain.com. The problem is that when users with a primary email address belonging to the faultingdomain.com sends internal mail to users with a faultingdomain.com email address, these internal mails are also send through the sendconnector leading to a mail loop that the smarthost configured on the sendconnector detects and rejects the message. External mail from faultingdomain.com is send through the sendconnector to the smarthost and this works as it is supposed to. As I believe then those internal messages should not even reach the sendconnectors as they should be picked up by internal Exchange delivery before the sendconnectors are even considered.

    I have tried deleting the sendconnector and creating a new one but the problem stille exists. Also I have tried using one of the sendconnectors that works for other customers but the problem remains. It seems like it is directly tied to the faultingdomain.com sending domain.

    If I remove the users from the securitygroup that is targeted by RouteBySender they send internal mail fine but external mail is of course not send through the required sendconnector any more.

    If I change the users primary email address domain of faultingdomain.com to non-faultingdomain.com and keeping the old faultingdomain.com email address as a secondary address then internal email is delivered internally as it is supposed to be.

    So I need some help on where to start digging for answers here.

    I have run the below command (adding parameters to fit my test message)

    Get-TransportService | Get-MessageTrackingLog

    And for the faulting messages I get the below output

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname : smarthost01.domain.com
    ConnectorId    : ROUTEBYSENDER1e62b79725c94c0da301719352bee0e3
    Source         : SMTP
    EventId        : SEND

    ClientHostname :
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    :
    Source         : SMTP
    EventId        : HAREDIRECTFAIL

    ClientHostname : INTERNALEXCHANGECAS.INTERNALDOMAIN.local
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    : INTERNALEXCHANGEMBX\Default Receive Connector
    Source         : SMTP
    EventId        : RECEIVE

    ClientHostname :
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    :
    Source         : AGENT
    EventId        : REDIRECT

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname :
    ConnectorId    :
    Source         : AGENT
    EventId        : AGENTINFO

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname : smarthost02.domain.com
    ConnectorId    : ROUTEBYSENDER1e62b79725c94c0da301719352bee0e3
    Source         : SMTP
    EventId        : SEND

    ClientHostname :
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    :
    Source         : SMTP
    EventId        : HAREDIRECTFAIL

    ClientHostname : INTERNALEXCHANGECAS.INTERNALDOMAIN.local
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    : INTERNALEXCHANGEMBX\Default Receive Connector
    Source         : SMTP
    EventId        : RECEIVE

    ClientHostname :
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    :
    Source         : AGENT
    EventId        : REDIRECT

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname :
    ConnectorId    :
    Source         : AGENT
    EventId        : AGENTINFO

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname : smarthost01.domain.com
    ConnectorId    : ROUTEBYSENDER1e62b79725c94c0da301719352bee0e3
    Source         : SMTP
    EventId        : SEND

    Wen I run the same command on a message that doesn't fail I get the below output


    ClientHostname : INTERNALEXCHANGEMBX.INTERNALDOMAIN.local
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    :
    Source         : STOREDRIVER
    EventId        : RECEIVE

    ClientHostname :
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    :
    Source         : SMTP
    EventId        : HAREDIRECTFAIL

    ClientHostname : INTERNALEXCHANGEMBX.INTERNALDOMAIN.local
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    : INTERNALEXCHANGEMBX\Default Receive Connector
    Source         : SMTP
    EventId        : RECEIVE

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname : INTERNALEXCHANGEMBX.INTERNALDOMAIN.local
    ConnectorId    :
    Source         : STOREDRIVER
    EventId        : SUBMIT

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname :
    ConnectorId    :
    Source         : AGENT
    EventId        : AGENTINFO

    ClientHostname : INTERNALEXCHANGEMBX.INTERNALDOMAIN.local
    ServerHostname : INTERNALEXCHANGEMBX
    ConnectorId    :
    Source         : STOREDRIVER
    EventId        : DELIVER

    ClientHostname : INTERNALEXCHANGEMBX
    ServerHostname : INTERNALEXCHANGEMBX.INTERNALDOMAIN.local
    ConnectorId    : Intra-Organization SMTP Send Connector
    Source         : SMTP
    EventId        : SEND

    Can't really see anything myself from this apart from that the faulting message is picked up immediately by the sendconnector.

    Hope that anyone can point me at where to start looking for the problem.

    Best

    Thomas

    Friday, March 16, 2018 9:43 AM

All replies

  • I cant comment on the 3rd party solution but are the accepted domains all configured in the same way? i.e. check this is not setup as a relay or external domain?

    There must be some difference to the domain config in Exchange to manifest different behaviour...


    **Please don't forget to mark as helpful or answer**

    Friday, March 16, 2018 10:21 AM
  • Hi and thanks for replying.

    All domains are authorative on the server, at least viewed through ecp. Cannot see any transport rules pointing at the faultingdomain and that it should always send email through send connectors.

    Friday, March 16, 2018 12:43 PM
  • Was it working earlier or is it the first time you are trying this setup for this particular domain?


    AkashG || For any further queries, please mark an email to akash.g.88@outlook.com ||

    Friday, March 16, 2018 12:51 PM
  • First time.

    Weird thing is that when I remove them from the security group that is targeted by the SendConnector everything works normal, internal mail flows internally and external mail goes through the default sendconnector that is Configured in ECP. Then when the user is added to the security group again to start using the sendconnector that has been configured by the 3rd party software all email from the user goes externally gain. And it is only for this domain. If I give the user a primary email address in another domain it works perfectly. So it is something related to this specific domain.... it seems like it catches all email immediately and just sends it to the sendconenctor but I don't know how to diagnostic this.

    Friday, March 16, 2018 1:14 PM
  • If this issue occurs only after adding the user in security group, then there must be some rule somewhere which is doing this.

    I'd say look for transport rules to figure out what's happening.

    ALso, I am not sure how does RouteBySender works. It looks like there could be some config required in RouteBySender.


    AkashG || For any further queries, please mark an email to akash.g.88@outlook.com ||

    Friday, March 16, 2018 1:19 PM
  • I'll dig in the transport rules.

    RouteBySender creates sendconnectors in Exchange and it also adds a transport agent. But if I create a new sendconnector and tries to at this faulting domain to it it still fails. If I add any other domain (at least those i've tried) it works fine.

    Friday, March 16, 2018 2:20 PM
  • Ok I have done some digging in logs, but I cannot find anything useful.

    But I have found out that the problem only occurs when I try to send from an address of a domain that is newly created on the Exchange server as an Authorative domain (haven't tested with non-authorative). If I change the address to be from an old domain on the Exchange server then internal mail is delivered internally without going to the sendconnector.

    I believe it might be something in the latest couple of CUs doing this. Anyone have any clue to this?

    Friday, March 16, 2018 4:50 PM
  • Hi,

    Try to run the following command and compare with others working domains, check if any difference:

    Get-AcceptedDomain -Identity faultingdomain.com |fl


    Best Regards,
    Niko Cheng


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


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Thursday, March 22, 2018 10:03 AM
    Moderator
  • Hi Niko

    Thanks for helping out.

    Ran the command and the only thing catching my eye was the ExchangeVersion value which was 0.2 for the faulting domains and 0.1 for the working domain I was testing with. Found another domain though which had the same ExchangeVersion value (0.2) as the faulting domains and when testing with this everything works normally and mail is routed internally.

    So still the only thing I have to go after is the CU16->CU19 update and the fact that the new domains was created after the 3rd party software RouteBySender was installed.

    Any other help would be greatly appreciated before I start to reinstall the 3rd party software.


    Monday, March 26, 2018 1:42 PM
  • Hi,

    Does reinstalling the 3rd party software solve the issue?


    Best Regards,
    Niko Cheng


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


    Click here to learn more. Visit the dedicated forum to share, explore and talk to experts about Microsoft Teams.

    Tuesday, April 3, 2018 10:47 AM
    Moderator