PrestaShop 9 not sending emails over SMTP: the port 587 bug

Monday morning. A customer writes to ask whether their Saturday order went through, because they haven't received anything. You open the back office and there it is, paid. So is Sunday's, and every order from the whole week. Your shop is selling, but since you moved to PrestaShop 9 not a single email has reached anyone.

If you send through your own mail server —OVH, Microsoft 365, Gmail or your hosting provider's— on port 587, you haven't set anything up wrong. It's a PrestaShop 9 bug present in every version from 9.0.0 to 9.1.5, and it wasn't fixed until 9.2, released on 30 September 2026.

How to tell if this is your problem

Go to Advanced Parameters → Logs. If every order has left a line like this one, it's your case:

Mailer Error: Connection could not be
established with host
"ssl://ssl0.ovh.net:587":
stream_socket_client(): SSL operation
failed with code 1. OpenSSL Error
messages: error:0A00010B:SSL
routines::wrong version number

The server name will be yours. What gives the bug away is the ssl:// in front and the :587 at the end. You get the same message straight away if you click "Send a test email" under Advanced Parameters → E-mail.

The nasty part is everything that doesn't happen. The customer sees no error, the order is saved and the payment goes through. That's why it takes days to notice, and it's almost always a customer who tells you, asking about their invoice or their tracking number.

What changed in PrestaShop 9

There are two ways to encrypt the conversation with a mail server. In one, everything is encrypted from the very first second, and that's what port 465 expects. In the other, you say hello unencrypted first and then ask to switch to an encrypted conversation: that's port 587. They are two different doors, and each one expects you to knock its own way.

Up to PrestaShop 8, the "TLS" option in the back office knocked on the 587 door the way that door expects. PrestaShop 9 replaced the component it sends email with (from SwiftMailer to Symfony Mailer) and, along the way, changed what that option does: "TLS" now encrypts from the first second. It knocks on 587 as if it were 465, the server answers with a plain hello, and PrestaShop, which was expecting an encrypted reply, can't make sense of it. That's the "wrong version number".

That's why it breaks right when you upgrade from 8 to 9: the same settings that worked stop working without you touching anything. And that's why the "SSL" option you used to have is gone: in PrestaShop 9 the encryption drop-down only offers "None" and "TLS".

How to fix it today, without touching code

You change it under Advanced Parameters → E-mail, with "Set my own SMTP parameters" selected. What you need to enter depends on the ports your provider accepts, and we've checked them one by one against the servers of eleven providers:

• If your provider accepts port 465 —the mail that comes with OVH hosting (MX Plan, ssl0.ovh.net), Gmail, IONOS, Hostinger, Brevo or Mailjet—: encryption TLS and port 465. That's how our own shop is set up, and it runs on PrestaShop 9.
• If your provider only accepts port 587 —Microsoft 365 (smtp.office365.com), OVH Email Pro (pro1, pro2 or pro3.mail.ovh.net) and OVH Exchange—: encryption None and port 587. With these, on 9.0 and 9.1, "TLS" doesn't work on any port.

We know the second one feels wrong, because it says "None". But it doesn't mean your password travels in the clear. With that option, PrestaShop 9 says hello unencrypted and, as soon as the server offers encryption —all of these do—, it encrypts the conversation before sending the username and password. We checked it against the Microsoft 365 and OVH servers: the connection is encrypted (TLS 1.3 at Microsoft, TLS 1.2 at OVH) before any data leaves.

Save, send the test email and, if it arrives, you're done: orders placed from now on send their emails. The ones that got stuck along the way won't be resent on their own. On each order's page, in the status history, the "Resend email" button sends that status's email again, such as payment accepted or order shipped.

The trap if you're coming from PrestaShop 8 with SSL

If you had "SSL" with port 465 selected in PrestaShop 8, it keeps sending after the upgrade: PrestaShop 9 keeps that value and treats it as its "TLS". The problem comes the day you open that page and save, even to change something else. Since "SSL" is no longer in the drop-down, the back office shows "None", and that's what gets saved. With "None" and port 465 the shop sits waiting for a reply that never comes, and the log says Connection to "…:465" timed out.

We reproduced it on our test shop. Before saving anything on that page, check that the encryption says what you want it to say.

And in PrestaShop 9.2

9.2 fixes it properly: "TLS" works on port 587 again, as it did in PrestaShop 8. It's change 42197 in the project, which closes an issue opened in August 2024. It didn't make it into 9.1.5, the last of the 9.1 line: if you're on any 9.0 or 9.1, you have the bug.

Whatever you set today following this article keeps working after the upgrade —"TLS" with 465 and "None" with 587 both send just the same on 9.2—, so there's nothing to undo. Fix your email now and upgrade when it suits you, without rushing: 9.2 brings big changes, such as the new one-page checkout, and your payment and shipping modules need to be ready for it. An upgrade like that gets tested first on a copy of the shop.

If you send through Microsoft 365, mark December

Microsoft has announced that at the end of December 2026 it will switch off, by default, sending from applications with a username and password, which is exactly how PrestaShop sends. Your Microsoft account administrator will be able to turn it back on, and the final removal date will be announced in the second half of 2027. If your shop relies on Microsoft 365 to send its emails, this is a good moment to move it to a transactional email service such as Brevo or Mailjet and take that date off your plate.

Still not sending?

The log tells you where to look next. If it says Failed to authenticate, it's the username or the password: the username is always the full address, and in Microsoft 365 the mailbox needs authenticated SMTP turned on. If it says timed out, either that port doesn't exist at your provider —Microsoft 365 and OVH Email Pro have no 465—, or the drop-down trap got you, or your hosting doesn't let traffic out on that port.

And if you'd rather have it looked at by someone who has already solved it, send us the message from the log and your PrestaShop version. We'll tell you what to set in your case and, if there's something else behind it, we'll get it working.

Once your emails are going out again, make them worth opening: that's what we covered in the order confirmation is the worst page of your shop.

Tell us about your case