Gents:

I am seeing connectivity issues while sending email to Exchange Online.  This domain is using EOP for inbound email and transferring to on-site email.  Outbound email is being sent directly from on premise.  Exchange 2013.

Non Exchange Online domains seem to be fine.

Example:

Remote Server at xxxxx-org.mail.protection.outlook.com (x.x.x.x) returned '400 4.4.7 Message delayed'
7/14/2015 7:16:09 PM - Remote Server at xxx.mail.protection.outlook.com (x.x.x.x) returned '441 4.4.1 Error encountered while communicating with primary target IP address: "421 4.4.2 Connection dropped due to TimedOut." 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 x.x.x.x:25'<o:p></o:p>

Any ideas?

Hi Brain,

Check if  throttling configured causing it, as you must be having lots of emails hitting from single IP of EOP to your server. Look for best practices for EOP configuration.

Do you have additional SPAM filtering on-premises as well?

TLS setting might cause issues sometimes.

Exchange Online Throttling and Limits FAQ

http://blogs.msdn.com/b/exchangedev/archive/2011/06/23/exchange-online-throttling-and-limits-faq.aspx

EOP Mysteries Solved - Mail queuing in EOP which is destined on-premises

http://blogs.technet.com/b/eopfieldnotes/archive/2015/07/08/eop-mysteries-solved-mail-queuing-in-eop-which-is-destined-on-premises.aspx

I think I am not being clear.

The issue is sending SMTP traffic from on-premise Exchange 2013 to O365 hosted domains. This sending domain receives its email at EOP/Microsoft hosted service, which is relayed to on-premise Exchange 2013.

This is not an inbound email issue, rather a sending email to O365 domains issue.

I think I am not being clear.

The issue is sending SMTP traffic from on-premise Exchange 2013 to O365 hosted domains. This sending domain receives its email at EOP/Microsoft hosted service, which is relayed to on-premise Exchange 2013.

This is not an inbound email issue, rather a sending email to O365 domains issue.

Hi Brain,

What I said was this part "which is relayed to on-premise Exchange 2013." is having issues. The Exchange Admin responsible for EOP to On-prem relay of destination should check that.

On-Prem ExchOrg1 ->Internet Domain->(Succesfully accepted and queued)->EOPOrg2->Delayed here->On-Prem ExchOrg2

If "Outbound email is being sent directly from on premise.  Exchange 2013." part is for the receiving domain, then its irrelevant for this issue.

Get the header of the delayed received email and do a Analyze Header in mxtoolbox.com or TestExchangeConnectivity.com, it will clearly show where its getting stuck

Paste the header here if you don't mind after correctly disguising the domain names.

Hi Brain,

What I said was this part "which is relayed to on-premise Exchange 2013." is having issues. The Exchange Admin responsible for EOP to On-prem relay of destination should check that.

On-Prem ExchOrg1 ->Internet Domain->(Succesfully accepted and queued)->EOPOrg2->Delayed here->On-Prem ExchOrg2

If "Outbound email is being sent directly from on premise.  Exchange 2013." part is for the receiving domain, then its irrelevant for this issue.

Get the header of the delayed received email and do a Analyze Header in mxtoolbox.com or TestExchangeConnectivity.com, it will clearly show where its getting stuck

Paste the header here if you don't mind after correctly disguising the domain names.

OK:

Lets remove the issue that the sending domain uses O365 for inbound email and focus on the sending issue to O365 domains.

Testing Exchange connectivity is tested OK.  

Again, this is an on premise domain not being able to send email to O365 domains with this message, other domains are fine.

Remote Server at xxxxx-org.mail.protection.outlook.com (x.x.x.x) returned '400 4.4.7 Message delayed'
7/14/2015 7:16:09 PM - Remote Server at xxx.mail.protection.outlook.com (x.x.x.x) returned '441 4.4.1 Error encountered while communicating with primary target IP address: "421 4.4.2 Connection dropped due to TimedOut." 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 x.x.x.x:25'<o:p></o:p>

OK:

Lets remove the issue that the sending domain uses O365 for inbound email and focus on the sending issue to O365 domains.

Testing Exchange connectivity is tested OK.  

Again, this is an on premise domain not being able to send email to O365 domains with this message, other domains are fine.

Remote Server at xxxxx-org.mail.protection.outlook.com (x.x.x.x) returned '400 4.4.7 Message delayed'
7/14/2015 7:16:09 PM - Remote Server at xxx.mail.protection.outlook.com (x.x.x.x) returned '441 4.4.1 Error encountered while communicating with primary target IP address: "421 4.4.2 Connection dropped due to TimedOut." 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 x.x.x.x:25'<o:p></o:p>

Tell me about your send connectors. On-Prem to the internet or anyothers? Can you post the complete picture get-sendconnector |FL ( change the on-prem domain to something fake of course)

As requested

[PS] C:\Windows\system32>Get-SendConnector | FL


AddressSpaces                : {SMTP:*;1}
AuthenticationCredential     :
CloudServicesMailEnabled     : False
Comment                      :
ConnectedDomains             : {}
ConnectionInactivityTimeOut  : 00:10:00
DNSRoutingEnabled            : True
DomainSecureEnabled          : False
Enabled                      : True
ErrorPolicies                : Default
ForceHELO                    : False
Fqdn                         : v-exmbx01.xxx.com
FrontendProxyEnabled         : False
HomeMTA                      : Microsoft MTA
HomeMtaServerId              : V-EXCH-MBX-1
Identity                     : Outgoing
IgnoreSTARTTLS               : False
IsScopedConnector            : False
IsSmtpConnector              : True
MaxMessageSize               : 19.53 MB (20,480,000 bytes)
Name                         : Outgoing
Port                         : 25
ProtocolLoggingLevel         : Verbose
RequireOorg                  : False
RequireTLS                   : False
SmartHostAuthMechanism       : None
SmartHosts                   : {}
SmartHostsString             :
SmtpMaxMessagesPerConnection : 20
SourceIPAddress              : 0.0.0.0
SourceRoutingGroup           : Exchange Routing Group (DWBGZMFD01QNBJR)
SourceTransportServers       : {V-EXCH-MBX-2, V-EXCH-MBX-1}
TlsAuthLevel                 :
TlsCertificateName           :
TlsDomain                    :
UseExternalDNSServersEnabled : False

Is there an inbound connector (on-prem > EOP) defined in EOP  for this org? 

Yes.

[PS] C:\Windows\system32>Get-ReceiveConnector -Identity "V-EXCH-CAS-1\From FOPE" | FL


RunspaceId                              : 91dda4e5-edfc-4860-bd01-a7b7319b0594
AuthMechanism                           : Tls
Banner                                  :
BinaryMimeEnabled                       : True
Bindings                                : {0.0.0.0:25}
ChunkingEnabled                         : True
DefaultDomain                           :
DeliveryStatusNotificationEnabled       : True
EightBitMimeEnabled                     : True
BareLinefeedRejectionEnabled            : False
DomainSecureEnabled                     : False
EnhancedStatusCodesEnabled              : True
LongAddressesEnabled                    : False
OrarEnabled                             : False
SuppressXAnonymousTls                   : False
ProxyEnabled                            : False
AdvertiseClientSettings                 : False
Fqdn                                    : 209-147-6-54.xxx.com
ServiceDiscoveryFqdn                    :
TlsCertificateName                      :
Comment                                 :
Enabled                                 : True
ConnectionTimeout                       : 00:10:00
ConnectionInactivityTimeout             : 00:05:00
MessageRateLimit                        : Unlimited
MessageRateSource                       : IPAddress
MaxInboundConnection                    : 5000
MaxInboundConnectionPerSource           : 20
MaxInboundConnectionPercentagePerSource : 2
MaxHeaderSize                           : 128 KB (131,072 bytes)
MaxHopCount                             : 60
MaxLocalHopCount                        : 12
MaxLogonFailures                        : 3
MaxMessageSize                          : 35 MB (36,700,160 bytes)
MaxProtocolErrors                       : 5
MaxRecipientsPerMessage                 : 200
PermissionGroups                        : AnonymousUsers
PipeliningEnabled                       : True
ProtocolLoggingLevel                    : Verbose
RemoteIPRanges                          : {64.20.227.0/24, 94.245.120.64/26, 216.32.181.0/24, 216.32.180.0/24,
                                          213.199.180.128/26, 213.199.154.0/24, 207.46.51.64/26, 207.46.163.0/24,
                                          67.203.184.96/28, 65.55.88.0/24}
RequireEHLODomain                       : False
RequireTLS                              : False
EnableAuthGSSAPI                        : False
ExtendedProtectionPolicy                : None
LiveCredentialEnabled                   : False
TlsDomainCapabilities                   : {}
Server                                  : V-EXCH-CAS-1
TransportRole                           : FrontendTransport
SizeEnabled                             : Enabled
TarpitInterval                          : 00:00:05
MaxAcknowledgementDelay                 : 00:00:30
AdminDisplayName                        :
ExchangeVersion                         : 0.1 (8.0.535.0)
Name                                    : From FOPE
DistinguishedName                       : CN=From FOPE,CN=SMTP Receive
                                          Connectors,CN=Protocols,CN=V-EXCH-CAS-1,CN=Servers,CN=Exchange
                                          Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=First
                                          Organization,CN=Microsoft
                                          Exchange,CN=Services,CN=Configuration,DC=xxx,DC=local
Identity                                : V-EXCH-CAS-1\From FOPE
Guid                                    : 913712af-16ad-4803-801e-057e2f4a577a
ObjectCategory                          : xxx.local/Configuration/Schema/ms-Exch-Smtp-Receive-Connector
ObjectClass                             : {top, msExchSmtpReceiveConnector}
WhenChanged                             : 8/6/2013 5:51:07 PM
WhenCreated                             : 8/5/2013 1:59:53 PM
WhenChangedUTC                          : 8/7/2013 12:51:07 AM
WhenCreatedUTC                          : 8/5/2013 8:59:53 PM
OrganizationId                          :
OriginatingServer                       : DC1.xxx.local
IsValid                                 : True
ObjectState                             : Unchanged

Actually, I m thinking of the inbound connectors in EOP. Since they are using EOP, I assume there is one for on-prem to Office365 yes?  Even though they send internet mail straight from on-prem. 

There is one there.

It is on, but not used, the OP Exchange is not using it as smart host.  Do you think this could be the issue?  I should turn it off and then delete it?

There is one there.

It is on, but not used, the OP Exchange is not using it as smart host.  Do you think this could be the issue?  I should turn it off and then delete it?

I can send messages from other O365 domains to the locally hosted domain through EOP.  Even with attachments.  I will post back within 24 hours if customer continues having complaints.

Does the very fact that connector was on do something to routing email within Exchange Online.

 

There is one there.

It is on, but not used, the OP Exchange is not using it as smart host.  Do you think this could be the issue?  I should turn it off and then delete it?

I can send messages from other O365 domains to the locally hosted domain through EOP.  Even with attachments.  I will post back within 24 hours if customer continues having complaints.

Does the very fact that connector was on do something to routing email within Exchange Online.

 

That error indicates to me that EOP inbound connector from on-prem did not have the IPs of the sending on-prem servers set as allowed , yes. 

It had the right IP address of a potential sending connector, but local Exchange does not use it for smart host to send.  The inbound connector on EOP is now off.

If this inbound connector is enabled, does it do something to internal Exchange Online routing, overriding MX record delivery and anti-spam lookups?

I am not sure this solved the entire problem or not, but I will report back.

Never really got an answer here.  Don't know why moderator marked as answered.

"If this inbound connector is enabled, does it do something to internal Exchange Online routing, overriding MX record delivery and anti-spam lookups?"

The inbound connector in EOP should not affect an on-prem send connectors ability to send to other 0365 domains - assuming they are set to send directly to the internet using DNS using a MX lookup, no. 

Unfortunately, I do not have any permisssions to unmark this answer for this forum.