Cannot Send Emails To Office 365 or Exchange Online Protection Using TLS

I have found this is a common issue. You set up an Exchange Online Hybrid or Exchange Online Protection (EOP) stand alone service and follow all the instructions for the creating of the connectors needed, only to find that your emails queue in your Exchange Server. If you turn on protocol logging you get this error in the log “Connector is configured to send mail only over TLS connections and remote doesn’t support TLS” and if you look at the SMTP protocol verbs that are recorded in the log you see that Microsoft’s servers do not offer STARTTLS as a verb.

STARTTLS is the SMTP verb needed to begin a secure and encrypted session using TLS. Communication between your on-premises servers and Microsoft for hybrid or EOP configurations requires TLS and if you cannot start TLS then your email will queue.

If you are not configuring hybrid or EOP standalone and need to send an email to someone on Office 365 then this is not an issue, because Exchange Server does not require TLS for normal email communication and so the lack of a STARTTLS verb means your email is sent in clear text.

The reason why you are not getting STARTTLS offered is that your connecting IP address is on the Microsoft block list. If you change your connector (temporarily) to allow opportunistic TLS or no TLS at all then your emails will leave the queue – but will be rejected by the Microsoft servers. The NDR for the rejection will tell you to email Microsoft’s delisting service. So now you have an NDR with the answer to the problem in, you can fix it! It takes 1 to 2 hours to get delisted from when Microsoft process your email – so they say it takes 48 hours end to end.

Therefore my recommendation when setting up Exchange Online Hybrid or stand alone EOP is to send an email over plain text to EOP before you configure your service. If you are on the blocklist then you will get back the delisting email and you can process that whilst setting up the connectors to Office 365 and so by the time you are ready to test, you are off the blocklist!

To send a test email over Telnet

  1. Install the Telnet Client feature on your Exchange Server that will be your source server for hybrid or connectivity to EOP for outbound email
  2. Type the following. This will send an email to a fake address at Microsoft, but will hit the TLS error before the message is rejected

    telnet 25

  3. You are now connected to Exchange Online Protection and you should get a 220 response
  4. Type the following to send the email by command line. No typo’s allowed in telnet, so type carefully. Replacing your email address where prompted so that you get the NDR back to you.

    mail from:
    rcpt to:
    from: Your Name <>
    subject: testing to see if my IP is blocked

    type something here, it does not matter what, this is the body of the message you are sending

  5. A few points about the above. It must finish with a . (full stop) on a line by itself followed by a carriage return. There must be a blank line between the subject line and the body. And finally, for each line of data you type, the Microsoft SMTP servers will return either a 250 or 354 response.



16 responses to “Cannot Send Emails To Office 365 or Exchange Online Protection Using TLS”

  1. […] « Cannot Send Emails To Office 365 or Exchange Online Protection Using TLS […]

  2. Massimo avatar

    Thank you so much!
    Got the same behaviour! You fixed my problem! 🙂

    Nice to see that I opened an incident with Microsoft 6 days ago and they didn’t give me this solution yet (still investigating….)

  3. Joseph M. Durnal avatar

    Thanks Brian. Once again, your vast knowledge of transport saves the day on my end!

    You should be able to get the failure code through a telnet port 25 session. Go through a mail from: and a sent to: In some orgs, that would be a lot easier than changing the connector, especially for a quick test.

  4. Jake avatar

    I am getting a 500 5.3.3 unrecognized command error.

    Any ideas?


    1. Brian Reid avatar

      No idea – but then I have no idea what you are trying to do or when you get the error. Reply with some more info and I might be able to help.

  5. alexander avatar

    I’m using Postfix instead of Exchange and I’m unable to get TLS working. I’m most certainly not on the blacklist mentioned in the article since I’m able to send email if I don’t require TLS in the Postfix config and sending email over telnet works too. Do I need to talk to someone at Microsoft to solve this perhaps?

    From /var/log/mail.log
    Sep 23 13:07:03 mgmt-mon01 postfix/smtp[40570]: E5FE2420A94: to=,[]:25, delay=1027, delays=1027/0.08/0.58/0, dsn=4.7.4, status=deferred (TLS is required, but was not offered by host[])

    Testing with openssl:
    alexander@mgmt-mon01:~$ openssl s_client -starttls smtp -connect
    didn’t found starttls in server response, try anyway…

    1. Brian Reid avatar

      The above described “feature” no longer exists in Office 365.

      As for the postfix comment, have you got normal mail flow to work first?

  6. SHAMBHU SHARMA avatar

    Hi Brian, I see this behavior in outlook. Mailbox is at O365 and user is not able to send email but he is able to receive it. Mails go from Outbox>> sent Item. But it doesn’t reach at recipient. The same behavior does happen from OWA and Phone too. I did the test from your command and that message has delivered. Do you have any guide on this? There is no recent changes happen in his mailbox, no license change, no plan change etc.

    1. Brian Reid avatar

      This issue you have, and the article you have commented on, are unrelated. This article is on sending to Exchange Online from an on-premises server and TLS being required to send. For your issue, have you looked in message trace to see what is happening?

  7. SHAMBHU SHARMA avatar

    Thanks Brian,
    I have resolve this issue with move mailbox to other database with New-moverequest command.


  8. Aws avatar

    i dont understand how resolve this issue with microsoft server. im facing the same issue now im not able to send emails to any server using microsoft server ( i appreciate your help if you can give me more information.

  9. MetUys avatar

    Thanks for this.
    We had noticed on our one platform (for billing) that requires TLS for the connection to client mail systems.
    as to be excepted there are still some client mail servers that don’t support this yet, but what was really odd is and were also not offering the STARTTLS verb to us.

    When we tested from our other production systems, those servers did get the STARTTLS verb response, (as well as tests from checktls[dot]com)
    After opening a support ticket with MS they removed the billing platform’s IP from a particular list (all secretive, no details on what lists) and after about 2-4hours, we are now seeing the STARTTLS verb from the billing platform and can initiate a TLS connection.

    It seems rather odd to not offer this verb natively, but I’m sure they have their reasons and glad this is resolved for us.

    1. Brian Reid avatar

      IPs with untrusted activity or no previous history are often on lists such as Spamhaus or Microsoft’s own list built from historical activity (the Security Graph). If you are on this list then no TLS support and you need to request a delist.

  10. Ponvannan Ponselvan avatar
    Ponvannan Ponselvan

    hello brian,

    hope you are doing fine for a client we are trying to make a hybrid environment one on-prem Exchange server 2013.

    we have successfully migrated a one user mailbox to cloud.

    But Mail flow not working between onprem to cloud and cloud to on-prem
    on the outbound connector office365 to org i am getting 450 4.4.317 Cannot connect to remote server [Message=451 5.7.3 STARTTLS is required to send mail]
    on the outbound connector to office365 from on-prem SMTP Log: Connector is configured to send mail only over TLS connections and remote doesn’t support TLS.

    any help would be much appreciated.

    1. Brian Reid avatar

      You are either blocking SMTP Enhanced verbs at the firewall or your IP is blocked from securely connecting to Microsoft. For the latter, visit

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.