One of the types of Accepted Domains you can add to an Exchange Server 2007 or 2010 organization is an Internal Relay domain.

For Internal Relay domains the Exchange servers behave like this:

If I have a local recipient within the organization with the SMTP address that the email is addressed to then deliver it to that mailbox. Otherwise, send it outside the organization.

Internal Relay domains are commonly used in shared SMTP namespace scenarios, where two separate mail systems both use the same domain name for email. If you want to know more about this scenario read How to Share an Email Domain Between Two Mail Systems.

The steps for setting up an Internal Relay domain are usually:

  1. Add the domain name to the Accepted Domains for the organization
  2. Create a Send Connector to route the non-local recipients in that domain to another external mail system

However the fact is that it will work just fine if you only do step 1, and let your main Send Connector for the “*” namespace (ie, all external domains) handle the routing outwards from the organization (either via smart host or DNS).

That is, unless you are using Edge Transport servers.

If you are using Edge Transport servers, have configured an Internal Relay domain, and have not configured a specific Send Connector for that namespace, you may see non-delivery messages when internal senders try to send to external recipients of that namespace.

This happens because an infinite loop is created between the Hub Transport and Edge Transport servers.

  1. The Hub Transport is correctly routing emails for non-local recipients in the Internal Relay domain name out of the organization via the Edge Transport servers.
  2. However the Edge Transport servers recognize the Internal Relay domain as being local to the organization, and therefore route the email back into the Hub Transport server (as they would if they’d received an email sent from an external sender and addressed to a recipient of that domain name).

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Under those conditions you may see non-delivery reports for emails sent to non-local recipients of the Internal Relay domain.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010In the diagnostic information will be the reason, an infinite loop.

#554 5.4.6 Hop count exceeded – possible mail loop ##

You will also see the loop in action in the message headers provided with the NDR.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010The solution for this problem is to configure a Send Connector for the organization that is specifically for that Internal Relay domain name, that is a lower cost than the default Send Connector.

On an Exchange 2010 server in your organization (not the Edge Transport server) open the Exchange Management Console and navigate to Organization Configuration/Hub Transport. Select the New Send Connector task in the Actions pane of the console.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Give the Send Connector a name and click Next to continue.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Add the SMTP address space for the Internal Relay domain. Choose a cost that is lower than the default Send Connector that EdgeSync creates, which is a cost of 100 by default. Click Next to continue.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010You can choose to route via DNS or a smart host, whichever suits your specific scenario. DNS is probably going to be fine if the MX records for that domain already point to where you want the mail to be routed to. Otherwise a smart host may be required. Click Next to continue.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010Set the source server depending on which server you want to send out the emails to that domain. For Internal Relay domains the source server for the Send Connector must be a Hub Transport server, not an Edge Transport server, in order to achieve the desired email routing for all scenarios. This means that the Hub Transport server you choose must be able to make SMTP connections through your firewall to wherever it needs to route the email for the Internal Relay domain.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

Finally, click New to complete the wizard and create the new Send Connector.

With the Send Connector in place you should see the correct routing behaviour in each scenario. Outside senders who send to a non-local recipient in the Internal Relay domain will be correctly routed into the Exchange organization first, and then back out the Send Connector from the Hub Transport server. Meanwhile email sent to local recipients of the Internal Relay domain will be delivered locally.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

 

Email sent from internal senders to non-local recipients of the Internal Relay domain will be correctly routed out the Send Connector as well, while email sent to local recipients of the Internal Relay domain will be delivered locally as expected.

Avoiding Infinite Loops with Internal Relay Domains in Exchange 2007/2010

This configuration achieves the desired message delivery without infinite loop conditions.

Bottom line is, if you are using Internal Relay domains and also Edge Transport servers you must configure a Send Connector for handling non-local recipients in that domain, or else you will create an infinite loop condition.

About the Author

Paul Cunningham

Paul is a former Microsoft MVP for Office Apps and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul no longer writes for Practical365.com.

Comments

  1. Marc

    Hello Paul we are having a similar issue in my organisation our mail flow goes as follow: 0365 > SEG smart host > external domain via dns now the problem happens from time to time for example if I send an email to an external domain and cc to myself and my mailbox is also in 0365 outgoing traffic has to go to our smart host for content inspection so the email goes then 0365 SEG > to my internal domain via dns but my Mx records point to the SEG smart host and so on and so fort and that’s would happens as well if the external domain has also an O365 mailbox the mail will go into a loop why O365 doesn’t send the external email directly to the external O365 mailbox instead 0365 is send this email back to the SEG

  2. Jesus Marin

    I have a hybrid environment, and I get “too many hops” for some relayed emails, I have a transport rule on prem and O365 to send the emails coming to a specific domain routed to a mailbox that lives in O365, I have a connector pointing to an MX for that domain.
    Any suggestions?

  3. Chris

    Hi Paul, I’m having almost the exact same problem as described in your article except (a) we are not using an Edge Transport server, (b) the mail loop is between one server and itself, and (c) I’ve only witnessed it happening to internal e-mails. It’s not every e-mail, only once or twice a week for different end-users (one or two at a time) and has only been happening for about a month now.

    Here’s an example of what I see:
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 14:01:57 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:46:55 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:31:52 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:16:49 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:16:19 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:15:44 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:15:44 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:15:43 -0700
    Received: from mail1.domain.com (x.x.x.224) by
    mail1.domain.com (x.x.x.224) with Microsoft SMTP Server (TLS)
    id 14.3.224.2; Tue, 19 May 2015 13:15:43 -0700
    Received: from mail1.domain.com ([x::x:x:x:f820]) by
    mail1.domain.com ([x::x:x:x:f820%13]) with mapiShadow
    id 14.03.0224.002; Tue, 19 May 2015 13:15:42 -0700

    Any input or suggestions you may have would be greatly appreciated.

  4. David Burridge

    Hi, we have recently been implementing this for a merger but we’ve wanted to route across the internal network. To achieve this we needed to create a send connector. I would suggest that using Accepted Relay Domains, even using the default route send connector used you would still get looping as the logic for an unknown recipient would flow as:

    1. Email comes into primary org.
    2. User doesn’t match, it passes on using send connectors.
    3 Email arrives at partner organisation and it can’t match the recipient.
    4. As its also configured in this environment as a accepted relay domain it will attempt to pass it on (or back) to the primary org.
    5. Email arrives at primary org again and the same logic gets passed again.

    We used X-Loop headers using transport rules to detect and drop messages bouncing around.

  5. Katherine

    What’s this error message mean and how do I fix?
    Transport rules loop count exceeded

  6. Svein Maubach

    Your article put me in the right direction, but I had to improvise since my setup is different:

    When one have one non-authorative Exchange server behind a non-microsoft mailgateway, which sorts out some mail-adresses to be delivered to other servers, one can still have the loop due to no mailbox existing.

    The solution then can be a combination of testing and tagging using private headers in the gateway.
    For instance two rules in the gateway applied to all mail being forwarded to the Exchange server:
    rule #1: test if the X-SomePrivateHeaderEntry header entry exists with value “true”, if it does, reject with a 550 message (Requested action not taken: mailbox unavailable)
    rule #2: set the X-SomePrivateHeaderEntry header entry to value “true”

    Then the loop will be limited to a once around instead of up to 25 times, and a sensible error is returned.

  7. Dario Palermo

    I’m testing a shared namespace and I found an unexpected problem: Exchange is generating NDRs for non existent addresses (I mean, addresses that do not exist on Exchange or the other non exchange server). I was pretty sure Exchange would not generate NDR for a non-authoritative domain, yet it is.

    Did I miss something?

    bye, Dario

      1. Dario Palermo

        Thanks for you prompt reply but no, it’s not my case. First of all, I’m not using and Edge Tranport Server. Second, the NDRs are returned true unexistent addresses. Mail flow between the two servers is ok, and so it is between the two servers and the internet.

        I read about NDRs not being generated by Exchange for Internal Relay domains here:

        http://blogs.technet.com/b/exchange/archive/2011/10/07/accepted-domains-shared-smtp-address-spaces-and-recipient-filtering.aspx#comments

        But maybe it’s not true, also because NDRs could be legit (mailbox full on the last server in the chain are supposed to return an NDR to the sender, for an example).

        Now I’m going for the recipient filtering with some sync as suggested in that post: doing so should solve the problem and strenghten security in one shot…

        bye, Dario

  8. Huseyin Unal

    Yet another good article, thanks Paul.

    “Set the source server depending on which server you want to send out the emails to that domain. For Internal Relay domains the source server for the Send Connector must be a Hub Transport server, not an Edge Transport server, in order to achieve the desired email routing for all scenarios.”

    According to my tests source server doesn’t matter so we can use hub or edge transport servers as a source. In addition if we have edge transport we have to use a send connector for an external relay domain as well.

  9. amit

    Thanks paul on your reply .. and all effort. here i just want to update that while digging into more about the change request SMTP address found that change request is an application which does not support email integration so that’s was the issue.

    I liked your whole explanation about the same .

  10. Amit

    Hi Thanks for the nice info … i am facing the similar issue as described below can you please suggest someting to rectify the same…
    ——————————————-
    One of the user getting approval requests (patch applications) from ChangeRequest@i7.com. However, when he respond, replies are rejected – see below.
    —————————
    From: Microsoft Exchange
    Sent: 29 September 2011 15:32
    To: James bond
    Subject: Undeliverable: RE: To install the MS patches at Saturday 11:00 PM CST to Sunday 01:00 AM CST

    Delivery has failed to these recipients or distribution lists:

    ChangeRequest%i7Tech@i7.com
    A problem occurred during the delivery of this message. Microsoft Exchange will not try to redeliver this message for you. Please try resending this message later, or provide the following diagnostic text to your system administrator.

    The following organization rejected your message: maileme.abc.com.
    _____

    Sent by Microsoft Exchange Server 2007

    Diagnostic information for administrators:
    Generating server: cashub2.abc.corp.local

    ChangeRequest%i7Tech@i7.com
    maileme.abc.com #554 5.4.6 Hop count exceeded – possible mail loop ##rfc822;changerequest@i7.com
    Original message headers:

    Received: from edge2.abc.com (192.168.1.1) by
    cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
    id 8.2.254.0; Thu, 29 Sep 2011 15:31:48 +0100
    Received: from cashub2.abc.corp.local (10.10.1.1) by maileme.abc.com
    (192.168.1.1) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
    2011 15:15:42 +0100
    Received: from Edge1.abc.com (192.168.1.2) by
    cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
    id 8.2.254.0; Thu, 29 Sep 2011 15:16:44 +0100
    Received: from cashub2.abc.corp.local (10.10.1.1) by maileme.abc.com
    (192.168.1.2) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 29 Sep
    2011 15:00:56 +0100
    Received: from edge2.abc.com (192.168.1.1) by
    cashub2.abc.corp.local (10.10.1.1) with Microsoft SMTP Server (TLS)
    id 8.2.254.0; Thu, 29 Sep 2011 15:01:39 +0100

    So while checking the below findings.

    1. There is only mail contact configured for that SMTP address changerequest@i7.com as no mailbox is present.
    2. mailema.abc.com” are the alias used by application or application groups. Maileme and Edge are the different machines and on Edge machine there is only one NIC installed.
    3. Under the accepted domain “i7.com” is configured as an authoritative domain which is set to false by default. Apart from this Under the Send connector there is a send connector configured which is set to disabled; address space is configured with “1” cost and under the network tab i am seeing route mail through the following smart host is there which i am unable to ping the smart host. And Under the source servers are all CASHUB server listed.
    4. Do i need to change the setting under the network TAB to use DNS “MX” record to route email..??? Or do i need to change the setting under the accepted domain from “Authoritative” to “Internal relay Domain.” and enabled ??
    5. Tried sending the mail from external as well getting the similar error stating that Delivery to the following recipient failed permanently: changerequest@i7.com

    Technical details of permanent failure:
    Google tried to deliver your message, but it was rejected by the recipient domain. We recommend contacting the other email provider for further information about the cause of this error. The error that the other server returned was: 550 550 Invalid recipient (#5.1.1) (state 14).

    1. Avatar photo

      Amit, I’m having trouble picturing how your whole setup is configured, but it sounds like two separate issues – one issue is the mail loop, the other is the “invalid recipient” error when you test it externally.

      Is @i7.com and @mailema.abc.com both within the same Exchange organization? Is the user who replies to the emails and gets the mail loop a user within that organization, or a separate one?

Leave a Reply