I hear from quite a lot of people that break their internal Exchange mail flow by configuring receive connectors and send connectors. This issue comes up fairly regularly, so I figured it’s time to write a post about it, as well as some of the other common issues I see in the field.
For the connector issues, I suspect part of the misunderstanding in this area is that back in the Exchange 2003 era there was the concept of routing groups and routing group connectors. The Exchange 2003 servers within a routing group could talk to each other just fine, but you needed to create routing group connectors to get the servers in two different routing groups to talk to each other.
When you upgraded to Exchange 2007 or 2010, additional routing group connectors were required to facilitate the routing of email messages between the legacy routing groups and the new routing group that held the Exchange 2007/2010 servers. However, beyond that coexistence requirement, the Exchange 2007 or later servers don’t use routing groups and routing group connectors to determine how and where they route internal email. Instead, Exchange 2007 and later uses the Active Directory site topology. There’s a few things administrators can do to control or influence that internal routing, but that is not relevant to the main point of this article, which is that no additional connectors are required for any two Exchange 2007 or later servers to communicate with each other.
As I mentioned earlier, I suspect the Exchange 2003 way of doing things, and the experience during the 2003 to 2007/2010 upgrade, left the impression on some people that they needed to:
- Create a send connector to route or relay email from Server A to Server B, or from Server A to the internet via Server B
- Create a custom receive connector on Server B so that Server A can send email to it
Neither of those is the correct way to establish internal mail flow, and in fact you’re more likely to break internal mail flow if you try either of those things. Exchange 2007, 2010, 2013 and 2016 all come pre-configured with the appropriate connectors for internal mail flow.
But wait, what if you’ve installed your new Exchange server, and found that one or more of the following conditions exists:
- Mail flow doesn’t work between mailboxes on the old and new servers
- Trying to route outbound email via the new server doesn’t work, e.g. email gets stuck in the queue on the old server
- Lots of managed availability probe emails are queuing up on one or both of the servers
In those situations the problem is usually a mis-configuration, a fault, or something interfering with communication between the two servers. Here’s my suggestions on how to investigate the problem.
- Draw a picture. You should be able to identify every network hop between the two servers. That includes network devices like switches, routers, firewalls, WAN accelerators, and so on.
- Remove any firewall restrictions. Firewalling two Exchange servers from each other is not supported. If there’s a firewall, insert an Any/Any rule for Exchange servers. Windows Firewall is okay, because Exchange inserts the required rules during setup. In fact, don’t disable the Windows Firewall on Exchange servers.
- Remove any WAN compression/accelerator configurations. In my experience these tend to break server-to-server authentication. A pass-through rule for Exchange IPs to talk to each other without interference should be configured.
- Remove any host-based security products that interfere with SMTP communications. Many such programs default to blocking SMTP to mitigate the risk of mass-mailing worms. Obviously that will kill SMTP for Exchange servers as well. Some of the products are also very invasive, and keep working even if you “disable” them. A full uninstall may be required if you can’t work out a configuration that doesn’t interfere with SMTP.
- If you’ve configured a relay connector on your Exchange server, that may be causing the issue. The configuration of a relay connector isn’t suitable for Exchange server-to-server communications. Configure the SMTP banner on your receive connectors to match the connector name (use Jeff Guillet’s tip here). Telnet from one Exchange server to another. If you see the relay connector name in the SMTP banner, then the issue is likely that the IP address of the Exchange server (or an IP range that includes the Exchange server) has been added to the remote IP range on the relay connector. It will need to be removed for server-to-server communication to work.
The Real Person!
The Real Person!
Hi Paul,
During a migration I was having trouble with internal mail queuing up on the old server rather than flowing freely to the new server. It was stuck in “SMTP Relay in Active Site”
Your comments about the receive connectors was absolutely spot on.
“Neither of those is the correct way to establish internal mail flow, and in fact you’re more likely to break internal mail flow if you try either of those things. Exchange 2007, 2010, 2013 and 2016 all come pre-configured with the appropriate connectors for internal mail flow.”
“If you’ve configured a relay connector on your Exchange server, that may be causing the issue. The configuration of a relay connector isn’t suitable for Exchange server-to-server communications.”
“Then the issue is likely that the IP address of the Exchange server (or an IP range that includes the Exchange server) has been added to the remote IP range on the relay connector. It will need to be removed for server-to-server communication to work.”
This is an excellent intuitive explanation of the issue and ever so helpful.
Thank you for the many hours saved by sharing your insight.
3 days later, i found the problem, kaspersky does a ssl inspection and this was the problem between Exchange 2010 and 2016 internal mail flow
this was the error that i found on logs files in C:\Program Files\Microsoft\Exchange Server\V15\TransportRoles\Logs\Hub\Connectivity
2022-10-05T18:26:41.780Z,08DAA6FEDE772E3D,SMTP,site:nombre-predeterminado-primer-sitio; version:14,-,Messages: 0 Bytes: 0 (Retry : Connection dropped due to ConnectionAborted)
2022-10-05T18:27:41.793Z,08DAA6FEDE772E3E,SMTP,site:nombre-predeterminado-primer-sitio; version:14,+,SmtpRelayToMailboxDeliveryGroup 00000000-0000-0000-0000-000000000000;QueueLength=TQ=1;RN=1;.
2022-10-05T18:27:41.793Z,08DAA6FEDE772E3E,SMTP,site:nombre-predeterminado-primer-sitio; version:14,>,server.dominio.com.py[126.10.10.12]
2022-10-05T18:27:41.839Z,08DAA6FEDE772E3E,SMTP,site:nombre-predeterminado-primer-sitio; version:14,>,Established connection to 126.10.10.12
2022-10-05T18:27:41.925Z,08DAA6FEDE772E3E,SMTP,site:nombre-predeterminado-primer-sitio; version:14,-,Messages: 0 Bytes: 0 (Retry : Connection dropped due to ConnectionReset)
Hi
I have 2 Exchange 2016 with DAG and four DBs. Incoming SMTP trafiic passed with KEMP.
When I shutdown Exchange2 server, all working fine, when I shutdown Exchange1 server- on Exchange2 queue I see error
Delivery Type: SMTP Delivery to Mailbox
Status: Retry
Last Error: [{LED=451 4.4.397 Error communicating with target host. -> 421 4.2.1 Unable to connect -> SocketConnectionRefused: Socket error code 10061};{MSG=};{FQDN=testdb1};{IP=ExchangeServer1 IP})
What Can I do?
Best regards
Tom
hello and thanks for the informative post!
i have a problem in a brand new test lab. 2019 SERVER DC, and 2016 server exchange server (exchange 2016 cu20) everything is fully patched and no other software on either server.
problem is, i can send mail from owa using the “administrator” account, but the mail is never received, and also in the delivery reports, i get error 400 so i can’t even see what is or is not happening. i had the exact same issue in ex 2019, so i rebuilt the entire lab from bare metal on ex2016. many exchange install videos show the same process i use and mail just works right out of the box. also i did ZERO config / mods to my exchange server aside from setting up one user mailbox.
any help will be most appreciated.
Hi Paul, as already said by someone here above: THANK YOU. I followed your tutorials and articles so many times… And also this time you saved me a headache. I was using an IP range a bit wide for my internal relay connector 😛 . Thank youuuu! 😉
Hi Paul,
I’ve tried to migrate the Mail server (Exchange 2010-Server 2008 R2 Enterprise) from Hyper-V to Vsphare 6.7.0 but the VM powered on and was able to receive email internally/externally, send internally, however, Exchange couldn’t send email externally. I culled the logs and tried a lot of things but couldn’t get mail to send externally. Everything looked fine but mail being sent out seems to disappear into the ether without showing up in the logs. Had to revert to Hyper-V version.
Do I need to stop/start some services or it’s something else?
Can you please help here?
Thanks
I have currently midway through an Exchange 2010-2016 migration and have co-existent servers in place.
Mail flow is fine internally and externally until I migration a test mailbox over to the 2016 Exchange Server.
Mail flow works internally to and from the 2016 mailbox and 2010 mailboxes internally and the 2016 mailbox can send externally. However, the 2016 mailbox cannot receive from an external source. Mails to this mailbox are queued on the 2010 Exchange Server with the SMTP Relay to Active Directory error.
I cannot migrate mailboxes between servers to continue the serer migration until I have resolved this issue.
Any ideas where the issue may be?.
Thanks a lot.
First of all thank you for your guides.
I’ve a problem during Exchange 2010-2016 migration.
The Exchange server 2016 cannot send a message to Exchange 2010 mailbox.
The messages from internet or from Exchange 2010 mailbox work like a charm.
This is my scenario, two mailbox server (Exchange 2010), two hub transport/CAS (Exchange 2010) and two new Exchange 2016.
The sent messages are stuck on queue with the error “;[{LED=};{MSG=};{FQDN=};{IP=};{LRT=}];0;;0” if i force an NDR the return message said “at the moment the receiver mail system don’t accept any messsages”.
Any idea?
Thank you.
Solved!
Just add the “Exchange Server Authentication” on Exchange 2010 Receive Connector, and then restart the service with “Restart-Service MSExchangeTransport” power shell command
Thanks, that did it for me on exchange 2007 SP3, add Exchange Server Authentication, you also will need to add in the IP address of new servers on the legacy servers to receive from the newer servers, if they are on a different subnet, during co-existence, which my migration was.
Thank you. This helped with our Exchange 2010 -> Exchange 2016 migration. Mail was not coming into our 2010 server after redirecting the NAT to the 2016. This enabled mail to be sent over to the not-yet-migrated boxes still on 2010.
this worked for me, thanks
Paul you’ve helped me so many times I can’t even count them anymore. Thank you so much for these guides and tips and tricks. I owe you a beer anytime you are in WA state.
Thanks!
Thank you for this article it pointed me in the right direction. I’m upgrading a customer’s Exchange 2010 server to 2016. All went fine until I found I couldn’t send emails between test mailboxes on each server. The issue turned out to be on the Receive Connector on the 2010 server. On the Authentication tab, Exchange Server authentication wasn’t ticked. I ticked this and retried the mail queues and it cured the issue. May not be the case for everyone but it’s worth noting as there was only the one Exchange server before so that setting would have been irrelevant!
I created a delivery rule for outside emails. It is to place a banner indicating the email as external.
I am getting the banner on “some” of the internal emails that are distribution groups? I checked the header and it is not leaving our environment. We are running Exchange 2016 on premise.
Any ideas on what could cause this?
This is caused by unauthenticated SMTP senders. You can add exemptions to your rule to prevent this from happening or switch the device to send authenticated SMTP.
Hi Paul,
Do you have a script to re-create the default receive connectors in exchange 2016?
Best regards,
Oscar
Thanks for this article, which receive connector should be used when mail flow *is* working between two Exchange 2013 servers in the same organization. Thanks!
Paul,
I tried everything on your list and still have emails stuck in the SmtpDeliveryToMailbox queue when trying to email between mailbox servers (2013 & 2016). The NextHopDomain is definitely targeting the correct mailbox database for the recipient. I keep getting the following error:
{LED=441 4.4.1 Error encountered while communicating
with primary target IP address: “Failed to connect. Winsock error code: 10060,
Win32 error code: 10060.” Attempted failover to alternate host, but that did not
succeed. Either there are no alternate hosts, or delivery failed to all alternate
hosts. The last endpoint attempted was
(my domain controller’s ip is here):475};{FQDN=(the recipient mailbox database name is here)};{IP=(domain controler ip again)}]
Any help is much appreciated (keep in mind I have checked the ports, I have checked for any applications that interfere with SMTP, I have checked for any connectors that reference the either mb server’s ip address)
Paul, I’ve inherited a Exchange environment (2016) where an old Exchange Routing Group connector still lingers (which apparently wasnt removed when the environment was Exchange 2010 and causes the periodic Event ID 5016)
Get-RoutingGroupConnetor in EMS isnt available any longer as far as I can see. What would you do to get rid of it?
Best regards
Sassan Karai
Hello there, I have removed my 2007 exchange servers and migrated to 2013 however my internal distribution groups do not work, from what I have read it seems to be with them being linked to an expansion server however I cannot seem to find how to fix this, the powershell commands do not yeild any results and I have more and more messages stuck in the queue to distribution groups.
The errror message sitting on them is : There is currently no route to the distribution group expansion server
hi Paul,
I am a freshman in exchange configuration.
I have some doubts about the routing of mail when exchange and domino coexistence.
1. part of the user exists in the domino system.
2. part of the user exists in the exchange system.
3. When emailing from a domino system to a user who exists in exchange, I can solve this problem by setting up a smart host in the domino system
4. My question is: How do I configure the exchange connector so that exchange can proxy the mail to domino when the recipient does not exist?
What I am looking forward to is:
If the recipient exists in exchange, it is saved directly to the inbox; if the recipient does not exist in exchange, it is proxied to the domino system.
Hope to give me some suggestions, thank you!
Set your domain in Exchange Accepted Domains as internal rely.
I have an issue where when a new mailbox is created internal users can’t email the new mailbox. It sometimes takes until the next day when you can send mail to the mailbox without a bounce back.
However, the new mailbox can send externally and receive externally. Any insight as to why that may be the case?
Thanks!
The Real Person!
The Real Person!
Depends what the bounce message says. But if it fixes itself after a day then my suspicion would be its an Offline Address Book issue. The way to test that is to try emailing the new mailbox from OWA, which uses the live GAL. If that works, then it’s most likely the OAB not updated with the new mailbox yet.
We have Two Exchange 2010 mail-servers in a DAG and two CAS/HUB (2010) with NLB and one 2010 edge. During upgrade to exchange 2016, we have only installed the exchange 2016 sw, but not done any configuration yet. After a few days we discovered that some external e-mails did not arrived to the recipients. Those e-mails had gone to the 2016 server, but this one do not have anything configured yet, only default settings. Why will some e-mails (4-5%) go to this server and not as normal to exchange 2010 servers?
We had to shutdown the new 2016 exchange server to get the mail-flow to work as normal.
The Real Person!
The Real Person!
It’s really impossible for me to say without seeing the environment first hand. Misconfigured connectors is one possibility. But troubleshooting just about any mail flow problem starts with the same basics.
https://www.practical365.com/exchange-server/exchange-server-how-to-find-missing-emails/
To @Chakraborty : if you install multi-role CAS and Mailbox, default receive connector should be 2525 port. You always send message come into draft if leave it deafult SMTP 25.
If Internal mail flow doesn’t require any connector then why mails send through internal users are getting stuck in Drafts.
Can you please help here.
The Real Person!
The Real Person!
There are several possible causes of that, including DNS configuration issues and server health issues. A Google or Bing search for the problem will lead you to many articles about it, and you’ll just need to work through them and do some troubleshooting.
I am slightly confused. From what I understand from your post, internal communication requires connectors not just the default ones, is that correct?
The Real Person!
The Real Person!
No. Internal mail flow does not require you to create or modify any connectors.
Hi Paul,
imagine 2 AD-sites with one DAG and Exchange servers in each site.
Now I want to prevent users from site1 from sending email messages larger that 5 MB to site2. Users from site2 shouldn’t get restricted.
How can I realize that? Configuring the AD-sitelink would affect users in both sites.
Would it here be necessary to create an internal send or receive connector?