PrestaShop not sending emails: the full diagnosis

A silent, expensive failure

When PrestaShop stops sending emails, nothing visibly breaks. Orders go through, the back office works. But the customer never gets their confirmation, rings customer service, and trust starts to erode. Plenty of merchants only discover the problem weeks after it started.

The diagnosis runs across four levels, from the simplest to the most technical. Do not skip a step: the cause is often at level 1.

Level 1: the PrestaShop configuration

Go to Advanced Parameters > E-mail.

The number one trap can be read straight from the database:

SELECT name, value FROM ps_configuration WHERE name LIKE 'PS_MAIL%';

The PS_MAIL_METHOD setting takes three values: 1 for PHP's mail function, 2 for SMTP, and 3 for disabled. Value 3 is the most common cause of "no emails at all". It sometimes gets set by a module, or during a testing phase, and then forgotten.

Next, check the sending address. It has to belong to your own domain. A store sending from a Gmail or Yahoo address will have its messages rejected by most receiving servers.

Finally, use the test email button on that page: it returns a raw error message, far more useful than a test placed through the checkout.

Level 2: the PrestaShop 9 SMTP regression

This case deserves a section of its own, because it hits stores whose configuration has not changed at all.

PrestaShop 9 replaced Swift Mailer with Symfony Mailer, and SSL encryption was removed from the abstraction layer: only TLS or no encryption remain on offer. The observed consequence: the connection string is built as ssl://server:587 where version 8 used tcp://server:587.

Port 587, however, expects STARTTLS, that is a plaintext connection that then upgrades to encrypted, not implicit SSL. The server replies with an error along these lines:

SSL operation failed with code 1
error:0A00010B:SSL routines::wrong version number

That message is thoroughly misleading: it is not a certificate problem but a protocol mismatch.

The immediate workaround is to switch to port 465 with SSL, which works correctly. If your provider does not offer 465, the alternative is to move to a transactional sending service with a dedicated module.

If your emails stopped going out at exactly the moment you upgraded to version 9, this is the first thing to look at.

Level 3: domain authentication

Your emails are going out, but they are not arriving. That is a different problem, and it is now the most common one.

Mailbox providers expect three DNS records:

• SPF: authorises the server that sends on behalf of your domain. Watch out for the ten DNS lookup limit, quickly reached once you stack several services.
• DKIM: signs messages cryptographically. It is configured on the sending service, which gives you the public key to publish.
• DMARC: tells receivers what to do when the first two fail. Start with a none policy to observe, then tighten it.

A domain with no DKIM sees a large share of its messages filed as junk, with no server-side error at all. Check the state of your records with a testing tool, and read the headers of a message you have received: they show the result of each check.

Level 4: the send queue and the logs

PrestaShop keeps a history of the messages it has sent:

SELECT recipient, subject, date_add FROM ps_mail ORDER BY date_add DESC LIMIT 20;

If recent rows appear, PrestaShop did attempt to send: the problem is downstream, on the sending or receiving server. If the table is empty, the problem is upstream, in the configuration or in the hook that triggers the send.

Also look at var/logs/ and your host's PHP error log. An SMTP connection error usually shows up there in plain language.

One special case: emails triggered by a scheduled task (reminders, reports) sometimes fail while transactional emails work fine. The cause is nearly always the scheduled task itself, not the sending. See our article on cron jobs that never run.

The setup we recommend

For a store in production, PHP's mail function should be ruled out: it sends from the host's shared IP address, whose reputation is out of your hands.

The robust configuration is a dedicated transactional sending service, over authenticated SMTP, with SPF and DKIM correctly published, and deliverability monitored. The cost is marginal; the difference in reliability is enormous.

Customers receiving nothing?

We work through the whole sending chain, from the PrestaShop configuration to domain authentication. Free diagnosis, reply within 1 hour — see PrestaShop emergency support.