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:
- Add the domain name to the Accepted Domains for the organization
- 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.
- 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.
- 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).
Under those conditions you may see non-delivery reports for emails sent to non-local recipients of the Internal Relay domain.
In 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.
The 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.
Give the Send Connector a name and click Next to continue.
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.
You 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.
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. 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.
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.
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.
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.
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
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?
Pingback: 7 things you can do to manage Exchange disk space
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.
The Real Person!
The Real Person!
Look for recipients with forwarding rules pointing to themselves perhaps? Or transport rules that might be causing the same issue.
You should probably also do some message tracking log searches on the offending emails to see what transport actions are taking place to cause the loop.
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.
What’s this error message mean and how do I fix?
Transport rules loop count exceeded
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.
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
The Real Person!
The Real Person!
Is it possible you’re running into the issue describe here:
https://www.practical365.com/exchange-internal-relay-ndr-550
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
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.
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 .
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).
The Real Person!
The Real Person!
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?