BlogAssistenza urgente

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.

Presta Debug21 luglio 2026 5 min di lettura
Buste in volo, una delle quali si stacca e si disgrega

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 none per 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.