Home » Exchange Server » Configuring the TLS Certificate Name for Exchange Server Receive Connectors

Configuring the TLS Certificate Name for Exchange Server Receive Connectors

Consider a scenario in which you’re trying to do the right thing by ensuring that authenticated SMTP client connections to your Exchange server are protected by TLS encryption. Most commonly this will be when you have IMAP or POP clients configured with the Exchange server (or a DNS alias that points to the Exchange server) as the SMTP server for sending email.

If the client tries to authenticate over an unencrypted connection, a message is received with words to the effect of:

The outgoing server (SMTP) mail.exchangeserverpro.net does not support the selected authentication method.

After Googling around you learn that your SMTP client should use STARTTLS in order to authenticate securely. Here’s an example of how that is configured in Mozilla Thunderbird’s outgoing server settings.


Notice also the use of port 587. Exchange servers are pre-configured by setup with a receive connector that is designed for use by SMTP clients, named “SERVERNAMEClient Frontend SERVERNAME”. This is the port and connector that you should be using for your authenticated SMTP clients.

When you next attempt to send an email you get a different error. Depending on the email client you may get a certificate trust warning, a prompt to add a security exception to trust the untrusted certificate, or it may just fail completely with a certificate error. In all cases, clearly something is still not right.

The solution here is in the configuration of the receive connector that authenticated SMTP clients will be connecting to. Even though you have enabled a valid SSL certificate for SMTP, the connector needs to be configured with the “TLS certificate name” that you want to use. The first time I ran into this problem I found lots of articles and blog posts telling me that was the solution, but none of them told me how to actually configure that. And if you look at the Set-ReceiveConnector documentation, you still get confusing (and wrong) advice.

The TlsCertificateName parameter specifies the X.509 certificate to use with TLS sessions and secure mail. Valid input for this parameter is [I]Issuer[S]Subject. The Issuer value is found in the certificate’s Issuer field, and the Subject value is found in the certificate’s Subject field. You can find these values by running the Get-ExchangeCertificate cmdlet.

The above would probably be more useful if it provided an example, but more importantly, the “[I]” and “[S]” are not correct. If you try to use them, your Set-ReceiveConnector command will fail.

Here’s an example of using the correct syntax for TlsCertificateName. First, determine the thumbnail value for the certificate you want to use. In this example I’m going to use my wildcard certificate, which is already enabled for SMTP.

Next, capture the certificate as a variable.

Now, declare a new variable for the certificate issuer and subject values.

Now we can set the receive connector’s TlsCertificateName property without having to type out a long string containing the issuer and subject values.

Repeat that for every server and connector that will be handling the authenticated SMTP connections, i.e. if you’re using a load balanced SMTP namespace.

Your SMTP clients should now be able to securely authenticate without any warnings or errors appearing.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Exchange Server


  1. Howell Strain says:

    Thanks for tracking this down. Looks like the MS documentation needs a little work.

    Once the cert was configured I got a error “530 5.7.1 Client was not authenticated” even though both Outlook and Thunderbird are configured for SMTP user authentication. I can get a success by enabling Anonymous Users” permissions but won’t because it is a very bad idea. Following https://community.office365.com/en-us/f/148/t/176699 led me to explicitly add the mailbox user to the Send As list on the same user through ECP to fix it. I’m not sure why that was required but there you go. I also didn’t have to include the NETBIOS domain name with the user ID.

  2. Kevin Haydon says:

    this also fixed a STARTTLS issue with a front end connector at one of our clients. A valid cert was in place for SMTP but STARTTLS would not initiate.

    this procedure cured cracked it. Now responding to STARTTLS.


  3. Bobby says:

    Many thanks for sharing – used the information you provided to get certificate validation working between my on-premises Exch 2013 Server and O365 EOP. It’s now working both ways (relaying out, and receiving filtered mail in) via using my trusted wildcard certificate 🙂

    Having looked everywhere on the web, I eventually stumbled across your post and it has worked a charm – thanks very much! 🙂

  4. Mirek says:

    It seems so shortsighted that Microsoft would create a GUI and cmdlets to set a certificate, but then overlook a component that is so critical to have the cert applied.

    This fixed my issue, and it was only after many hours of searching! I knew it was using the wrong cert I just didn’t understand WHY.

  5. Tony says:

    Hi Paul,

    Would i need to make this change for all receive connectors on Exchange 2013 server?

    Identity Bindings Enabled
    ——– ——– ——-
    CEGEXCH2013Default CEGEXCH2013 {, [::]:2525} True
    CEGEXCH2013Client Proxy CEGEXCH2013 {[::]:465,} True
    CEGEXCH2013Default Frontend CEGEXCH… {[::]:25,} True
    CEGEXCH2013Outbound Proxy Frontend … {[::]:717,} True
    CEGEXCH2013Client Frontend CEGEXCH2013 {[::]:587,} True
    CEGEXCH2013Copiers {,} True
    CEGEXCH2013UPS {} True

  6. Collin says:

    Once again your site has solved a problem that was driving me crazy after deploying a Ex2016 server to accept inbound email.

    Thanks very much Paul.

  7. The_Doctor46 says:

    Thank you. I have been struggling to get STARTLS working with Exchange 2013 and Mimecast. I was puzzeled on why Exchange kept presenting a self signed cert that was not even assigned to SMTP service instead of the wildcard cert.

    This did the trick!

  8. sajith k j says:

    Thank you.I was also struggling to solve this issue .This trick helped me to stop certificate prompt while using tls encryption

  9. Szymon says:

    Hi Paul,

    With new version of your page there is bug in command ‘[PS] C:>$tlscertificatename = “<i>$($cert.Issuer)<s>$($cert.Subject)” ‘. As you know, it should be ‘[PS] C:>$tlscertificatename = “$($cert.Issuer)$($cert.Subject)” ‘.


  10. Hans Heiser says:

    Dear Paul,

    once again you rocked the Exchange – Thank you very much for this guide (and all the others) – Much appreciated.

    Cheers mate,

  11. Joshua says:

    This does not appear to work on Exchange 2010. When attempting to run:

    Set-ReceiveConnector “ConnectorName” -TlsCertificateName $tlscertificatename

    I receive the following result:
    “A positional parameter cannot be found that accepts this agrument ‘-TlsCertificateName’.

    Looking up Set-ReceiveConnector with Get-Help does not show a parameter available called TlsCertificateName.

    Is there another way to associate a certificate with a receive connector?

  12. Shawn Barnhart says:

    My question is why doesn’t the normal certificate enablement process just do this by default? IMHO, it’s a bug that Exchange 2013/2016 don’t use the certificate explicitly enabled for assigned services and continue to leave default self-signed certificates assigned and in use by SMTP and IIS (back-end port 444 binding). Enabling a certificate for a named service (SMTP, IIS, POP, IMAP) should by default make it the active certificate in use.

    I appreciate that MS may be trying to ensure STARTTLS availability and back-end SSL use out of the box for connections where certificate trust are less of an issue. And it’s great that TLS certificate assignment is possible to specific connectors for unusual corner cases where unique names/certificates are assigned on a per connector basis.

    But it’s bad and nonsensical to install default certificates and leave them active after PKI certs have been installed and enabled for the assignable high level services.

    • My understanding is that SMTP is a little different because it needs to cater for both server to server communications (servers address each other by their real names, and the self-signed certs are used for TLS) and client to server communications, as well as other scenarios like hybrid mail flow, partner connections, and so on, that all might use different certificates and namespaces.

  13. Dazzler says:

    Is there any solution to get this working on Exchange 2010 SP3 ?

    I get the same error as Joshua.

    receive the following result:
    “A positional parameter cannot be found that accepts this agrument ‘-TlsCertificateName’.

    Looking up Set-ReceiveConnector with Get-Help does not show a parameter available called TlsCertificateName.

    Please let me know the best way to achieve this ?

  14. TK says:

    Hi Paul,

    Having issues with 2010 sp3 as well, going by the article you linked – if you change the FQDN to match the name of the external cert, it should then use that cert for SMTP rather than the self signed?

    If not that simple, is there another way of achieving the same outcome?


  15. LouHarle says:

    Hi Paul, do any services need to be restarted after doing this? I implemented on Exchange 2016 for the “default frontend” connector for both servers and it is still happening.

  16. Raed says:

    Hi Paul,

    I am setting up a hybrid office 365 with a third party email filtration (proofpoint). MX points to proofpoint and office365 is authorized as a receiving and sending server.

    Mail flow to office365 Mailboxes works fine, but mail flow to the on-premises mailbox is deferred with below error.

    Reason: [{LED=450 4.4.317 Cannot connect to remote server};{MSG=451 5.7.3 STARTTLS is required to send mail};{FQDN=mail.mydomain.com};{IP=xxx.xxx.xxx.xxx};{LRT=5/2/2017 12:55:45 PM}]. OutboundProxyTargetIP: xxx.xxx.xxx.xxx. OutboundProxyTargetHostName: mail.mydomain.com

    Later on, emails may get released from office365 queue to the on premise MB when office365 forwards the email to proofpoint MX records!

    I do have a valid SSL certificate.

    is this related to my receive connector on my clustered EX2013 DAG? my cluster is as the following:
    2 x on-prem CAS server
    2 x on-prem MB server
    1 x remote CAS server (remote disaster center)
    1 x remote MB server (remote disaster center)

    how can solve this issue?

  17. Eder Silva says:

    I did exactly what is on your blog, but in my case it did not work. It continues to present a prompt with my certificate, which in the case is a wildcard. My certificate is a * .domain.com and the FQDN name of the Connector is mail.domain.com.

  18. Eder Silva says:

    I did exactly what is on your blog, but in my case it did not work. It continues to present a prompt with my certificate, which in the case is a wildcard. My certificate is a * .domain.com and the FQDN name of the Connector is mail.domain.com.

  19. Mark Needham says:

    Hi Paul, We have a scenario where we have two certificates installed on Exchange (one that is expiring and one that has just been issued) and both those certs have the same Issuer and Subject name. Will this process ensure a specific certificate is definitely used (via the Thumbprint) or does Exchange just look at the Issuer / Subject name to match things up.

    • Good question, and I’m not 100% sure, but last time I updated my Exchange certs I didn’t need to reset the TLS config on the receive connector, it just kept working, so I suspect that if the issuer and subject are the same it will just keep working.

Leave a Reply

Your email address will not be published. Required fields are marked *