PrestaShop non invia più email: la diagnosi completa
Conferme d'ordine mai ricevute, modulo di contatto muto: la causa è raramente quella che si pensa. La diagnosi a quattro livelli e la regressione SMTP della 9.

Un guasto silenzioso e costoso
Quando PrestaShop non invia più email, in apparenza non si rompe nulla. Gli ordini arrivano, il back office funziona. Ma il cliente non riceve la conferma, chiama l'assistenza e la fiducia si incrina. Molti commercianti scoprono il problema diverse settimane dopo la sua comparsa.
La diagnosi si fa su quattro livelli, dal più semplice al più tecnico. Non salti passaggi: la causa sta spesso al livello 1.
Livello 1: la configurazione di PrestaShop
Vada in Parametri avanzati > E-mail.
La trappola numero uno si legge direttamente nel database:
SELECT name, value FROM ps_configuration WHERE name LIKE 'PS_MAIL%';
Il parametro PS_MAIL_METHOD accetta tre valori: 1 per la funzione mail di PHP, 2 per SMTP e 3 per disattivato. Il valore 3 è la causa più frequente dei casi «non parte nessuna email». A volte lo imposta un modulo, altre volte viene messo durante una fase di collaudo e poi dimenticato.
Controlli poi l'indirizzo del mittente. Deve appartenere al suo dominio. Un negozio che spedisce da un indirizzo Gmail o Yahoo si vede rifiutare i messaggi dalla maggior parte dei server di ricezione.
Usi infine il pulsante di test presente in questa pagina: restituisce un messaggio d'errore grezzo, molto più utile di una prova fatta dal checkout.
Livello 2: la regressione SMTP di PrestaShop 9
Questo caso merita una sezione a sé, perché colpisce negozi la cui configurazione non è stata toccata.
PrestaShop 9 ha sostituito Swift Mailer con Symfony Mailer, e la cifratura SSL è stata rimossa dal livello di astrazione: restano disponibili soltanto TLS o nessuna cifratura. Conseguenza osservata: la stringa di connessione viene costruita come ssl://serveur:587 là dove la versione 8 usava tcp://serveur:587.
La porta 587 si aspetta però STARTTLS, cioè una connessione in chiaro che passa poi a cifrata, e non SSL implicito. Il server risponde allora con un errore di questo tipo:
SSL operation failed with code 1
error:0A00010B:SSL routines::wrong version number
Il messaggio, davvero fuorviante, non segnala un problema di certificato ma un'incompatibilità di protocollo.
La soluzione immediata è passare alla porta 465 in SSL, che funziona correttamente. Se il suo fornitore non offre la 465, l'alternativa è affidarsi a un servizio di invio transazionale dotato di un modulo dedicato.
Se le sue email hanno smesso di partire esattamente nel momento del passaggio alla versione 9, è la prima pista da seguire.
Livello 3: l'autenticazione del dominio
Le email partono, ma non arrivano. È un problema diverso, ed è oggi il più diffuso.
I provider di posta richiedono tre record DNS:
- SPF: autorizza il server che spedisce per conto del suo dominio. Attenzione al limite di dieci risoluzioni DNS, che si raggiunge in fretta quando si sommano più servizi.
- DKIM: firma i messaggi in modo crittografico. Si configura lato servizio di invio, che fornisce la chiave pubblica da pubblicare.
- DMARC: indica come comportarsi quando i due precedenti falliscono. Parta da una policy
noneper osservare, poi irrigidisca.
Un dominio senza DKIM vede finire nella posta indesiderata una quota importante dei messaggi, senza alcun errore lato server. Verifichi lo stato dei suoi record con uno strumento di test e legga le intestazioni di un messaggio ricevuto: riportano l'esito di ogni controllo.
Livello 4: la coda di invio e i log
PrestaShop conserva uno storico dei messaggi inviati:
SELECT recipient, subject, date_add FROM ps_mail ORDER BY date_add DESC LIMIT 20;
Se compaiono righe recenti, PrestaShop ha davvero tentato l'invio: il problema è a valle, lato server di invio o di ricezione. Se la tabella è vuota, il problema è a monte, nella configurazione o nell'attivazione dell'hook.
Consulti anche var/logs/ e il registro degli errori PHP del suo hosting. Un errore di connessione SMTP vi compare di solito in chiaro.
Caso particolare: le email innescate da un'attività pianificata (solleciti, report) a volte falliscono mentre quelle transazionali funzionano. La causa è quasi sempre l'attività pianificata stessa, non l'invio. Veda il nostro articolo sui cron che non vengono eseguiti.
La configurazione consigliata
Per un negozio in produzione la funzione mail di PHP è da evitare: spedisce dall'IP condiviso dell'hosting, la cui reputazione non dipende da lei.
La configurazione solida consiste nell'usare un servizio di invio transazionale dedicato, in SMTP autenticato, con SPF e DKIM pubblicati correttamente e un monitoraggio del tasso di consegna. Il costo è marginale; la differenza di affidabilità è enorme.
I suoi clienti non ricevono più nulla?
Analizziamo l'intera catena di invio, dalla configurazione di PrestaShop all'autenticazione del dominio. Diagnosi gratuita, risposta entro 1 ora — veda l'assistenza PrestaShop.
Leggi anche
Vulnerabilità ps_facetedsearch: l'aggiornamento PrestaShop da non rimandare
Una falla con punteggio 10 su 10 permette di prendere il controllo di un negozio con un semplice URL. Come capire se il suo è esposto e se è già stato colpito.
Leggi 30 luglio 2026PrestaShop violato: come scoprire e rimuovere uno skimmer di carte
Uno skimmer ruba i numeri di carta per settimane senza rallentare il negozio. I segnali da cercare, i comandi di diagnosi e la procedura di bonifica completa.
Leggi 29 luglio 2026Update Assistant bloccato: riparare un aggiornamento a PrestaShop 9
Cache che non si svuota, servizio Symfony introvabile, processo che si ferma a metà: gli errori reali dell'Update Assistant e il metodo per passare alla CLI.
Leggi