Is your Gmail showing TLS Negotiation failed the certificate doesn’t match the host error? Let’s fix it.
In April 2020, Gmail started enforcing strict email security measures. This error usually happens due to incorrect SSL on the mail server.
At Bobcares, we frequently get requests to fix email errors as part of our Server Management Services.
Today, we’ll see how our Support Engineers figure out SSL email errors and make it work.
What is TLS Negotiation failed the certificate doesn’t match the host error?
Usually, this error happens when a user sends emails from their Gmail securely. In the Gmail interface, many users route their emails via their mail server.
In simple words, TLS negotiation is the process that verifies the server, initiates the secure connection, etc. The actual data transfer will proceed only after this successful handshake.
However, if for some reason this communication fails, it results in an error.
Recently, Gmail has strengthened its security measures to fight against attacks. Since April 2, 2020, the Gmail has started verifying whether the Common Name of the SSL certificate matches the mail server. On finding a mismatch, it simply rejects the email.
Causes for TLS Negotiation failure and certificate mismatch
Now, let’s see the causes that would trigger TLS Negotiation failure and certificate mismatch.
Incorrect mail server
One of the top causes for secure email sending failure is the wrong mail server name. Many times, users put in their domain name as the mail server. However, this mail server will not have a proper SSL certificate.
In shared servers, the SSL will be issued to the hostname of the server. As a result, mails will bounce back with the error:
TLS Negotiation failed, the certificate doesn't match the host., code: 0Wrong mail settings
Similarly, the wrong email settings also can trigger TLS negotiation failure. This often relates to the SMTP port.
For sending emails securely, most email providers use port 587. If there are port blocks, email sending fails.
How we fix TLS Negotiation failed the certificate doesn’t match the host error
Recently, one of our customers reported this problem.
For some reason, I cannot send it from my connected Gmail account. I can send and receive find from my webmail just fine and can send emails from an outside source like Yahoo. It shows up in my Gmail just fine, but when I send anything from Gmail it bounced back this error.
The server returned this error when deleting and adding a new email address in Google: “TLS Negotiation failed, the certificate doesn’t match the host., code: 0“.
Moving on, let’s check how our Support Engineers fix the Gmail sending email error.
Correcting mail server name
As the first step, we verified the settings used by the customer in his Gmail. He was using his domain name as the mail server. However, the certificate for Exim mail service was for the web.servernamexxx.com hostname. So we asked him to change the Outgoing Server and Incoming Server.
To verify the SSL certificate of the mail server, it’s worth to check it via a browser using the https:// link. For instance, in cPanel servers, it can be easily retrieved from the cPanel link.
Choosing the right email settings
Next, we check the settings used in the Gmail interface. Here, we set the correct port, mail server, and email address.
To verify the connection on secure port 587 of the mail server, we use the telnet command. A successful connection result shows up as:
user@myhome:~$ telnet xx.yyy.com 587
Trying 14.xx.yy.34...
Connected to xx.yyy.com.
Escape character is '^]'.
220 xx.yyy.com ESMTP PostfixHowever, when port 587 is not listening, the results will be:
telnet: Unable to connect to remote host: Connection refusedThe final settings on the Gmail interface appear as:
Disable TLS
A third solution to solve SSL email errors will be to send emails via port 25. However, this is not recommended as the mail communication will be unencrypted. We suggest this solution to customers only when the mail server does not support SSL.
[Trouble sending secure emails via Gmail? We can fix it for you.]
Conclusion
In short, the error TLS Negotiation failed the certificate doesn’t match the host happens due to an incorrect mail server or mail settings. Today, we saw the top 3 fixes that our Support Engineers recommend to customers to make secure email work.
PREVENT YOUR SERVER FROM CRASHING!
Never again lose customers to poor server speed! Let us help you.
Our server experts will monitor & maintain your server 24/7 so that it remains lightning fast and secure.
GET STARTED
var google_conversion_label = «owonCMyG5nEQ0aD71QM»;
Ran into a strange problem recently where an Exchange 2016 server could not send mail to Office 365 via hybrid mail flow. What made this situation particularly strange is that other Exchange servers in the environment had no problem sending messages over the hybrid connection. On the problem server, messages would get stuck in the queue and eventually time out.
The queues were filled with retries such as these.
451 4.4.0 Primary target IP address responded with: "421 4.2.1 Unable to connect." Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or deliver failed to all alternate hosts.
This message tells us that the server was unable to connect to Office 365. Unfortunately, it does not give us much detail beyond that. For that level of detail, we need to enable logging on the SMTP send connector used to send mail to Office 365.
Turn up logging on the SMTP Send Connector
To enable logging on a send connector, log into the Exchange Admin Center (EAC) and select the Mail Flow tab and Send Connectors sub-tab. Double click the send connector named Outbound to Office 365 and select Verbose under the General tab. Click Save.
To perform this same action through the Exchange Management Shell (EMS) type the following command.
C:> Set-SendConnector -Identity "Outbound to Office 365" -ProtocolLoggingLevel Verbose
Note: Protocol logging can take some time before it starts creating log files. You can jump-start this process by restarting the Microsoft Exchange Transport service. Keep in mind this will disrupt mail flow on that server while the service restarts. The default location for SMTP send logs in Exchange 2016 is %ExchangeInstallPath%TransportRolesLogsHubProtocolLogSmtpSend.
While we waited for logging to generate some entries we also confirmed that we could successfully make a connection from the problem server to Office 365. For this task, we confirmed that we could telnet over port 25 to Office 365 and send an email message. This confirmed two things. First that this server was not being blocked on outbound port 25. Second that this server could resolve and reach Office 365 servers.
Analyzing the SMTP logs
Once we re-tried a few of the messages in our queue we examined the SMTP logs. Like our telnet test, we could see Exchange was making the initial connection to Office 365. By line 14 we could see our server was transmitting its SSL certificate. However, this was quickly followed with the error TLS negotiation failed with error NoCredentials. This indicated an issue with our certificate. From face value, everything on the certificate looked correct.
Outbound to Office 365,<,"220 BL3FEO12EC057.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Thu, 28 Feb 2017 00:00:00 +0000", Outbound to Office 365,>,EHLO exchangeservergeek.com, Outbound to Office 365,<,250-BL3FEO12EC057.mail.protection.outlook.com Hello [207.46.150.129], Outbound to Office 365,<,250-SIZE 157286400, Outbound to Office 365,<,250-PIPELINING, Outbound to Office 365,<,250-DSN, Outbound to Office 365,<,250-ENHANCEDSTATUSCODES, Outbound to Office 365,<,250-STARTTLS, Outbound to Office 365,<,250-8BITMIME, Outbound to Office 365,<,250 BINARYMIME, Outbound to Office 365,>,STARTTLS, Outbound to Office 365,<,220 2.0.0 SMTP server ready, Outbound to Office 365,*,,Sending certificate Outbound to Office 365,*,"CN=webmail.exchangeservergeek.com, OU=Exchange Server Geek, O=SuperTekBoy, L=Cincinnati, S=Ohio, C=US",Certificate subject Outbound to Office 365,*,"CN=DigiCert SHA2 Secure Server CA, O=DigiCert Inc, C=US",Certificate issuer name Outbound to Office 365,*,07A7C02B0DF809CAB510F58A270A7DE9,Certificate serial number Outbound to Office 365,*,CE3A3D779940A6855B53E2F69EF2DA4BC374D3EE,Certificate thumbprint Outbound to Office 365,*,autodiscover.exchangeservergeek.com,Certificate alternate names Outbound to Office 365,*,,TLS negotiation failed with error NoCredentials
We then attempted to match the thumbprint of the certificate (highlighted in blue) against the working servers. It did not match. We then compared it against the certificate on the problem server. It did not match either. To compound the issue the thumbprint from the logs was not found in either the EAC or EMS. In fact, the thumbprint in Exchange Admin Center across all servers was the same. All servers also had that same certificate bound to SMTP. Yet somehow the thumbprint in the logs did not match.
What we found was that the problem server had two identical certificates with the same common name. One with the correct thumbprint and one with a thumbprint that matched the SMTP logs. We discovered this issue by loading up the Certificates MMC on the problem server.
To do this click Start and type MMC.
From the MMC console select the File menu followed by Add/Remove Snapin. Select Certificates and click Add. From the wizard select Computer account > Local computer > Finish. Click Ok.
Back on the console expand Certificates (Local Computer) > Personal > and select Certificates. Your duplicate is most likely here.
Determine which certificate is incorrect from the thumbprint. Right click on the duplicate and select Delete from the context menu. Click Yes to confirm.
As soon as we removed the incorrect duplicate certificate from the problem server (and retried the messages in the queue) mail started to flow. It’s uncertain why Office 365 does not attempt to match the thumbprint rather than just the common name. Hopefully, we will see this change in the future update to Office 365.
Have you run into this error? What was your solution? Drop a comment below or join the conversation on Twitter @SuperTekBoy.
While testing mail flow in a Exchange 2013 hybrid configuration with a new Office 365 tenant, messages between on premise and Office 365 mailboxes were not being received. However, communication between on premise mailboxes worked, as well as, Office 365 mailboxes and to all external recipients. Eventually, the messages in the queue timed out and NDRs were received, such as this…
Remote Server returned '< #4.4.7 smtp;550 4.4.7 QUEUE.Expired; message expired>'
After confirming the external firewall was configured with the correct rule sets using the listed Exchange Online Protection IP addresses, and enabling logging for all on premise send and receive connectors in Exchange 2013, I contacted support.
Through support’s assistance, we quickly resolved the matter of mail flow from the Office 365 mailboxes to on premise mailboxes by enabling ‘Opportunistic TLS’ for the “inbound” connector from the O365 Exchange Admin Center (EAC). However, that setting change did nothing to resolve the mail flow issues from on premise mailboxes to Office 365 mailboxes. Additional investigation needed to be performed.
From the Exchange 2013 server, we reviewed the transport settings (get-transportserver | fl), the certificates (get-exchangecertificate | fl) and set the ‘Outbound to Office 365’ send connector Delivery option to “Route mail through smart hosts” using the address for the MX record provided in your Office 365 DNS management page (i.e. domainname.mail.protection.outlook.com) and enabled “Use the external DNS lookup setting on servers with transport roles”. Still, mail flow from on premise to Office 365 did not work.
Next, also from the Exchange 2013 server, we installed the telnet client and successfully confirmed access of the Office 365 SMTP servers via telnet (on port 25) using our MX record address. Additional testing of mail from external senders to Office 365 was received successfully.
In the O365 EAC > Mail Flow > Accepted Domains, the default domain was set from “Authoritative” to “Internal Relay” and, still, mail flow from on premise to Office 365 did not work.
Then, in reviewing the SMTP send logs (C:Program FilesMicrosoftExchange ServerV15TransportRolesLogsHubProtocolLogSmtpSend), the following connection was found repeated many times over with this error “TLS negotiation failed with error NoCredentials“.
2014-12-23T20:08:01.137Z,Outbound to Office 365,08D1ECFA4B38037F,0,,207.46.163.215:25,*,,attempting to connect
2014-12-23T20:08:01.231Z,Outbound to Office 365,08D1ECFA4B38037F,1,10.10.10.152:28178,207.46.163.215:25,+,,
2014-12-23T20:08:01.341Z,Outbound to Office 365,08D1ECFA4B38037F,2,10.10.10.152:28178,207.46.163.215:25,<,"220 BL2FFO11FD058.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 23 Dec 2014 20:07:59 +0000",
2014-12-23T20:08:01.341Z,Outbound to Office 365,08D1ECFA4B38037F,3,10.10.10.152:28178,207.46.163.215:25,>,EHLO ex1.domain.local,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,4,10.10.10.152:28178,207.46.163.215:25,<,250-BL2FFO11FD058.mail.protection.outlook.com Hello [X.X.X.X],
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,5,10.10.10.152:28178,207.46.163.215:25,<,250-SIZE 157286400,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,6,10.10.10.152:28178,207.46.163.215:25,<,250-PIPELINING,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,7,10.10.10.152:28178,207.46.163.215:25,<,250-DSN,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,8,10.10.10.152:28178,207.46.163.215:25,<,250-ENHANCEDSTATUSCODES,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,9,10.10.10.152:28178,207.46.163.215:25,<,250-STARTTLS,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,10,10.10.10.152:28178,207.46.163.215:25,<,250-8BITMIME,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,11,10.10.10.152:28178,207.46.163.215:25,<,250-BINARYMIME,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,12,10.10.10.152:28178,207.46.163.215:25,<,250 CHUNKING,
2014-12-23T20:08:01.434Z,Outbound to Office 365,08D1ECFA4B38037F,13,10.10.10.152:28178,207.46.163.215:25,>,STARTTLS,
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,14,10.10.10.152:28178,207.46.163.215:25,<,220 2.0.0 SMTP server ready,
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,15,10.10.10.152:28178,207.46.163.215:25,*,,Sending certificate
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,16,10.10.10.152:28178,207.46.163.215:25,*,"CN=mail.domainname.com, OU=Domain Control Validated",Certificate subject
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,17,10.10.10.152:28178,207.46.163.215:25,*,"CN=Starfield Secure Certificate Authority - G2, OU=http://certs.starfieldtech.com/repository/, O=""Starfield Technologies, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,18,10.10.10.152:28178,207.46.163.215:25,*,XXXXXXXXXXXXXX,Certificate serial number
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,19,10.10.10.152:28178,207.46.163.215:25,*,76CDA7673866A90AF77973AA140621AECE384E66,Certificate thumbprint
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,20,10.10.10.152:28178,207.46.163.215:25,*,mail.domainname.com;www.mail.domainname.com;autodiscover.domainname.com,Certificate alternate names
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,21,10.10.10.152:28178,207.46.163.215:25,*,,TLS negotiation failed with error NoCredentials
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,22,10.10.10.152:28178,207.46.163.215:25,-,,Local
Then, we reset the “inbound” connector in Office 365 back to “Force TLS” and set the Domain Restriction from “None” to “Restrict domains by certificate” using the assigned certificate to Exchange 2013 “<I>CN=Starfield Secure Certificate Authority – G2, OU=http://certs.starfieldtech.com/repository/, O=”Starfield Technologies, Inc.”, L=Scottsdale, S=Arizona, C=US<S>CN=mail.domainname.com, OU=Domain Control Validated“, however, the issue with mail flow was not resolved.
Lastly, we took a deeper look at the SMTP send logs and found a discrepancy with the certificate thumbprint associated with the connection error and the thumbprint of the certificate assigned to the Exchange 2013 server.
2014-12-23T20:08:01.512Z,Outbound to Office 365,08D1ECFA4B38037F,19,10.10.10.152:28178,207.46.163.215:25,*,76CDA7673866A90AF77973AA140621AECE384E66,Certificate thumbprint
The thumbprint of the assigned certificate on the Exchange 2013 server is…
40C17C1A4F34D7468D69388B7E99862DF24EC0BC
This discrepancy appears to have been causing the mail flow issue from on premise to Office 365. With this lead, we reviewed the certificates (from the Exchange 2013 server) via the MMC in Certificates (Local Computer) > Personal > Certificates and found an expired certificate with the invalid thumbprint (40C17C1A4F34D7468D69388B7E99862DF24EC0BC). The expired certificate was then removed and an IISRESET was performed from an elevated command prompt.
As a result, additional mail flow testing from on premise mailboxes to Office 365 mailboxes was successful and all prior test messages were successfully delivered as well.
2014-12-23T20:20:31.254Z,Outbound to Office 365,08D1ECFA4B380387,0,,207.46.163.215:25,*,,attempting to connect 2014-12-23T20:20:31.363Z,Outbound to Office 365,08D1ECFA4B380387,1,10.10.10.152:29551,207.46.163.215:25,+,, 2014-12-23T20:20:31.457Z,Outbound to Office 365,08D1ECFA4B380387,2,10.10.10.152:29551,207.46.163.215:25,<,"220 BL2FFO11FD021.mail.protection.outlook.com Microsoft ESMTP MAIL Service ready at Tue, 23 Dec 2014 20:20:29 +0000", 2014-12-23T20:20:31.457Z,Outbound to Office 365,08D1ECFA4B380387,3,10.10.10.152:29551,207.46.163.215:25,>,EHLO d5-ex1.d5.local, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,4,10.10.10.152:29551,207.46.163.215:25,<,250-BL2FFO11FD021.mail.protection.outlook.com Hello [X.X.X.X], 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,5,10.10.10.152:29551,207.46.163.215:25,<,250-SIZE 157286400, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,6,10.10.10.152:29551,207.46.163.215:25,<,250-PIPELINING, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,7,10.10.10.152:29551,207.46.163.215:25,<,250-DSN, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,8,10.10.10.152:29551,207.46.163.215:25,<,250-ENHANCEDSTATUSCODES, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,9,10.10.10.152:29551,207.46.163.215:25,<,250-STARTTLS, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,10,10.10.10.152:29551,207.46.163.215:25,<,250-8BITMIME, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,11,10.10.10.152:29551,207.46.163.215:25,<,250-BINARYMIME, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,12,10.10.10.152:29551,207.46.163.215:25,<,250 CHUNKING, 2014-12-23T20:20:31.582Z,Outbound to Office 365,08D1ECFA4B380387,13,10.10.10.152:29551,207.46.163.215:25,>,STARTTLS, 2014-12-23T20:20:31.676Z,Outbound to Office 365,08D1ECFA4B380387,14,10.10.10.152:29551,207.46.163.215:25,<,220 2.0.0 SMTP server ready, 2014-12-23T20:20:31.676Z,Outbound to Office 365,08D1ECFA4B380387,15,10.10.10.152:29551,207.46.163.215:25,*,,Sending certificate 2014-12-23T20:20:31.676Z,Outbound to Office 365,08D1ECFA4B380387,16,10.10.10.152:29551,207.46.163.215:25,*,"CN=mail.domainname.com, OU=Domain Control Validated",Certificate subject 2014-12-23T20:20:31.676Z,Outbound to Office 365,08D1ECFA4B380387,17,10.10.10.152:29551,207.46.163.215:25,*,"CN=Starfield Secure Certificate Authority - G2, OU=http://certs.starfieldtech.com/repository/, O=""Starfield Technologies, Inc."", L=Scottsdale, S=Arizona, C=US",Certificate issuer name 2014-12-23T20:20:31.676Z,Outbound to Office 365,08D1ECFA4B380387,18,10.10.10.152:29551,207.46.163.215:25,*,27900F8FCB8B12,Certificate serial number 2014-12-23T20:20:31.676Z,Outbound to Office 365,08D1ECFA4B380387,19,10.10.10.152:29551,207.46.163.215:25,*,40C17C1A4F34D7468D69388B7E99862DF24EC0BC,Certificate thumbprint 2014-12-23T20:20:31.676Z,Outbound to Office 365,08D1ECFA4B380387,20,10.10.10.152:29551,207.46.163.215:25,*,mail.domainname.com;www.mail.domainname.com;autodiscover.domainname.com;domainname.com,Certificate alternate names 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,21,10.10.10.152:29551,207.46.163.215:25,*,,Remote certificate 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,22,10.10.10.152:29551,207.46.163.215:25,*,"CN=mail.protection.outlook.com, OU=Forefront Online Protection for Exchange, O=Microsoft, L=Redmond, S=WA, C=US",Certificate subject 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,23,10.10.10.152:29551,207.46.163.215:25,*,"CN=MSIT Machine Auth CA 2, DC=redmond, DC=corp, DC=microsoft, DC=com",Certificate issuer name 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,24,10.10.10.152:29551,207.46.163.215:25,*,689549F000010000DFBE,Certificate serial number 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,25,10.10.10.152:29551,207.46.163.215:25,*,3DFAEC8A810E8BF2D81D646ED4E11E0FFDF6FA55,Certificate thumbprint 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,26,10.10.10.152:29551,207.46.163.215:25,*,mail.protection.outlook.com;*.mail.eo.outlook.com;*.mail.protection.outlook.com;outlook.com;mail.messaging.microsoft.com,Certificate alternate names 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,27,10.10.10.152:29551,207.46.163.215:25,*,,"TLS protocol SP_PROT_TLS1_0_CLIENT negotiation succeeded using bulk encryption algorithm CALG_AES_128 with strength 128 bits, MAC hash algorithm CALG_SHA1 with strength 160 bits and key exchange algorithm CALG_RSA_KEYX with strength 2048 bits" 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,28,10.10.10.152:29551,207.46.163.215:25,*,,Received certificate 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,29,10.10.10.152:29551,207.46.163.215:25,*,3DFAEC8A810E8BF2D81D646ED4E11E0FFDF6FA55,Certificate thumbprint 2014-12-23T20:20:32.082Z,Outbound to Office 365,08D1ECFA4B380387,30,10.10.10.152:29551,207.46.163.215:25,>,EHLO d5-ex1.d5.local, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,31,10.10.10.152:29551,207.46.163.215:25,<,250-BL2FFO11FD021.mail.protection.outlook.com Hello [X.X.X.X], 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,32,10.10.10.152:29551,207.46.163.215:25,<,250-SIZE 157286400, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,33,10.10.10.152:29551,207.46.163.215:25,<,250-PIPELINING, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,34,10.10.10.152:29551,207.46.163.215:25,<,250-DSN, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,35,10.10.10.152:29551,207.46.163.215:25,<,250-ENHANCEDSTATUSCODES, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,36,10.10.10.152:29551,207.46.163.215:25,<,250-AUTH LOGIN, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,37,10.10.10.152:29551,207.46.163.215:25,<,250-8BITMIME, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,38,10.10.10.152:29551,207.46.163.215:25,<,250-BINARYMIME, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,39,10.10.10.152:29551,207.46.163.215:25,<,250 CHUNKING, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,40,10.10.10.152:29551,207.46.163.215:25,*,,sending message with RecordId 4939212390413 and InternetMessageId <1419366029923.28580@domainname.com> 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,41,10.10.10.152:29551,207.46.163.215:25,>,MAIL FROM:<test3@domainname.com> SIZE=13207, 2014-12-23T20:20:32.223Z,Outbound to Office 365,08D1ECFA4B380387,42,10.10.10.152:29551,207.46.163.215:25,>,RCPT TO:<Todd@domainname.mail.onmicrosoft.com> ORCPT=rfc822;Todd@domainname.com, 2014-12-23T20:20:32.363Z,Outbound to Office 365,08D1ECFA4B380387,43,10.10.10.152:29551,207.46.163.215:25,<,250 2.1.0 Sender OK, 2014-12-23T20:20:32.504Z,Outbound to Office 365,08D1ECFA4B380387,44,10.10.10.152:29551,207.46.163.215:25,<,250 2.1.5 Recipient OK, 2014-12-23T20:20:32.504Z,Outbound to Office 365,08D1ECFA4B380387,45,10.10.10.152:29551,207.46.163.215:25,>,BDAT 10358 LAST, 2014-12-23T20:20:34.286Z,Outbound to Office 365,08D1ECFA4B380387,46,10.10.10.152:29551,207.46.163.215:25,<,"250 2.6.0 <1419366029923.28580@domainname.com> [InternalId=20199231195942, Hostname=BY1PR0401MB1285.namprd04.prod.outlook.com] Queued mail for delivery", 2014-12-23T20:20:34.286Z,Outbound to Office 365,08D1ECFA4B380387,47,10.10.10.152:29551,207.46.163.215:25,>,QUIT, 2014-12-23T20:20:34.379Z,Outbound to Office 365,08D1ECFA4B380387,48,10.10.10.152:29551,207.46.163.215:25,<,221 2.0.0 Service closing transmission channel, 2014-12-23T20:20:34.379Z,Outbound to Office 365,08D1ECFA4B380387,49,10.10.10.152:29551,207.46.163.215:25,-,,Local
Finally, in the O365 EAC, we set the security option for the “outbound” connector to “Recipient certificate matches domain” and assigned our certificate domain…
<I>CN=Starfield Secure Certificate Authority - G2, OU=http://certs.starfieldtech.com/repository/, O="Starfield Technologies, Inc.", L=Scottsdale, S=Arizona, C=US<S>CN=mail.domainname.com, OU=Domain Control Validated
What was eventually determined, is during the original run of the hybrid configuration wizard (HCW) from Exchange 2013 an older (expiring) certificate was used, then a new certificate was assigned to Exchange 2013 with the older one being removed from the Exchange 2013 EAC, and finally the HCW was run again to apply the new certificate. However, the certificate was not removed appropriately during the steps to replace the expiring certificate.