Migrated Mailbox Able to Send but not Receive

[Unit2777]

Hello,

We have recently setup a full hybrid exchange environment using Microsoft's Hybrid Exchange tool.

I've created a test mailbox, setup some calendar items, sent and received some email before I migrated it.

After migrating it, everything is still there (calendar, emails etc), and the mailbox can send emails, however any emails sent to this mailbox are not received.

After a few hours, the sending mailbox will receive a postmaster email saying that "Delivery is delayed".

One idea I had that I thought might be the issue is the send connector on EOP.

Delivery is currently set to "MX record associated with recipient domain".

The MX record is currently set to Mimecast which then only redirects to EOP (no other transport rules).

Should this not be set to forward to Office 365? Would we need to configure the "Route mail through smart hosts settings"?

Any help would be much appreciated.

[#2]

@Unit2777 your Hybid configuration has not been done correctly in this case. You should leave mail coming to EOP for the time being (until most users are migrated, I would typically switch at around the half way mark at which point you tell Mimecast to send email to Office 365 and not on-prem).

Email is obviously not being sent from on-prem to Exchange online which means that there is an issue with your send connectors, I would review the connector configuration to see what the issue is. The Hybid configuration wizard should have created new connectors: new and existing Send and Receive connectors in the on-premises organization and Inbound and Outbound connectors in Exchange Online (see https://docs.microsoft.com/en-us/exchange/hybrid-configuration-wizard). So check if they are there.

[#3]

@CloudHalyou are indeed correct that the Hybrid Configuration Wizard has created the send and receive connectors in both Office 365 and EOP.

I am not too sure how they should be setup. Initially I chose the "Configure my Client Access and Mailbox servers for secure mail transport (typical)" option, however there is another option for "Configure my Edge Transport servers for secure mail transport"

Should I be using the second option to have mail flow through EOP?

On the second page it has me choose EOP to host receive connectors for secure mail transport, and I picked the only option available:

Everything else goes through fine and it doesn't show any sign of error, however the mailbox is still unable to receive.

Looping back to my original point, might it have anything to do with the send connector in EOP (Outbound to Office 365 rule)?

The MX record is set to Mimecast, which then directs to EOP, however if it's trying to use the send connector, won't it just create an infinite loop of sending to itself?

Would I need to set a smart hosts to Office 365 instead?

Thanks again!

[#4]

Hi there, you need an understanding of how mail routing between on-prem users, and migrated online users works. It doesn't create a mail loop because it uses an internal routing domain which is @yourtenant.mail.onmicrosoft.com. This is explained here https://docs.microsoft.com/en-us/exchange/transport-routing in the section called Route incoming Internet messages through your on-premises organization.

So the outbound connector to O365 is limited to this domain, and your migrated user should have a TargetAddress @yourtenant.mail.onmicrosoft.com. So if you send an email to this user, Exchange knows the user has been migrated due to the target address, and sends the email through the O365 send connector. I would look at your migrated user to see if they have been migrated correctly, if so the targetaddress attribute will be set. You should also see them in the ECP on-prem showing as Office 365 mailbox.

[#5]

@CloudHalthanks for taking the time to respond.

I forgot I had this thread open, but I have managed to resolve the issue.

I was getting a connection refused error when trying to validate the connectors even when I had whitelisted all of the IPs from the list of Office 365 IPs.

(Note: I was unable to add the hostnames to our firewall as I was told it doesn't support it and/or wildcards.)

In the end, we opened up ports 25 and 443 to all IP ranges, and it worked.

Not ideal but at least it is working for the time being, so I guess I just have to get this migration done quickly!

Thanks again.