PrestaShop verstuurt geen e-mails meer: de volledige diagnose

Een stille en dure storing

Wanneer PrestaShop geen e-mails meer verstuurt, gaat er zichtbaar niets kapot. Bestellingen komen binnen, de back-office werkt. Alleen krijgt de klant zijn bevestiging niet, belt hij de klantenservice en brokkelt het vertrouwen af. Veel webshopeigenaren ontdekken het probleem pas weken nadat het is ontstaan.

De diagnose verloopt in vier niveaus, van eenvoudig naar technisch. Sla geen stap over: de oorzaak zit vaak al op niveau 1.

Niveau 1: de PrestaShop-configuratie

Ga naar Geavanceerde instellingen > E-mail.

Valkuil nummer één leest u rechtstreeks in de database af:

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

De parameter PS_MAIL_METHOD kent drie waarden: 1 voor de mailfunctie van PHP, 2 voor SMTP en 3 voor uitgeschakeld. Waarde 3 is de meest voorkomende oorzaak van "er gaat helemaal niets uit". Soms zet een module die waarde, soms gebeurt het tijdens een testfase, waarna niemand er nog aan denkt.

Controleer daarna het afzenderadres. Dat moet bij uw eigen domein horen. Een webshop die vanaf een Gmail- of Yahoo-adres verstuurt, ziet zijn berichten door de meeste ontvangende servers geweigerd worden.

Gebruik tot slot de testknop op deze pagina: die levert een ruwe foutmelding op die veel bruikbaarder is dan een test via het bestelproces.

Niveau 2: de SMTP-regressie van PrestaShop 9

Dit geval verdient een eigen paragraaf, want het treft webshops waarvan de configuratie ongewijzigd is gebleven.

PrestaShop 9 heeft Swift Mailer vervangen door Symfony Mailer, en de SSL-versleuteling is uit de abstractielaag gehaald: alleen TLS of helemaal geen versleuteling zijn nog beschikbaar. Het waargenomen gevolg: de verbindingsstring wordt opgebouwd als ssl://server:587, waar versie 8 nog tcp://server:587 gebruikte.

Poort 587 verwacht echter STARTTLS, dus een onversleutelde verbinding die daarna omschakelt naar versleuteld, en geen impliciete SSL. De server antwoordt dan met een fout in deze trant:

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

Die zeer verwarrende melding duidt niet op een certificaatprobleem, maar op een protocolconflict.

De directe workaround is overstappen op poort 465 met SSL, die wel goed werkt. Biedt uw provider geen 465 aan, dan is het alternatief een dienst voor transactionele e-mail met een eigen module.

Zijn uw e-mails precies bij een upgrade naar versie 9 gestopt, dan begint u hier.

Niveau 3: de authenticatie van uw domein

Uw e-mails gaan wel weg, maar komen niet aan. Dat is een ander probleem, en tegenwoordig het meest voorkomende.

E-mailproviders eisen drie DNS-records:

• SPF: geeft de verzendende server toestemming namens uw domein. Let op de limiet van tien DNS-lookups, die snel wordt bereikt zodra u meerdere diensten stapelt.
• DKIM: ondertekent de berichten cryptografisch. U stelt dit in bij de verzenddienst, die de te publiceren publieke sleutel aanlevert.
• DMARC: bepaalt wat er moet gebeuren als de twee voorgaande controles falen. Begin met beleid none om te observeren en scherp daarna aan.

Een domein zonder DKIM ziet een flink deel van zijn berichten in de spammap belanden, zonder ook maar één foutmelding aan de serverkant. Controleer uw records met een testtool en lees de headers van een ontvangen bericht: daarin staat het resultaat van elke controle.

Niveau 4: de verzendwachtrij en de logs

PrestaShop houdt een overzicht bij van de verstuurde berichten:

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

Staan er recente regels in, dan heeft PrestaShop de verzending wel degelijk geprobeerd: het probleem zit verderop, bij de verzendende of de ontvangende server. Is de tabel leeg, dan zit het probleem ervoor, in de configuratie of in het aanroepen van de hook.

Raadpleeg ook var/logs/ en het PHP-foutenlogboek van uw hostingpartij. Een SMTP-verbindingsfout staat daar meestal onverbloemd in.

Bijzonder geval: e-mails die door een geplande taak worden aangestuurd (herinneringen, rapporten) mislukken soms terwijl de transactionele e-mails wel aankomen. De oorzaak ligt dan vrijwel altijd bij de geplande taak zelf, niet bij het verzenden. Zie ons artikel over cronjobs die niet draaien.

De aanbevolen instelling

Voor een webshop in productie is de mailfunctie van PHP af te raden: die verstuurt vanaf het gedeelde IP-adres van uw hostingpartij, waarvan de reputatie buiten uw invloed ligt.

De robuuste opzet is een aparte dienst voor transactionele e-mail, via geauthenticeerde SMTP, met correct gepubliceerde SPF- en DKIM-records en bewaking van de afleverpercentages. De kosten zijn marginaal; het verschil in betrouwbaarheid is groot.

Krijgen uw klanten niets meer binnen?

Wij onderzoeken de volledige verzendketen, van de PrestaShop-configuratie tot de authenticatie van uw domein. Gratis diagnose, reactie binnen 1 uur — zie PrestaShop-noodhulp.