Le email del tuo PrestaShop non arrivano (o finiscono in spam): la guida completa
Se le email PrestaShop non arrivano o finiscono in spam, la causa è quasi sempre record DNS mancanti (SPF, DKIM, DMARC), un SMTP condiviso con cattiva reputazione e zero monitoraggio dei bounce. Si risolve configurando i DNS corretti, attivando un SMTP dedicato e controllando i log del mail server con regolarità, non solo dopo il reclamo del cliente.
Il sintomo che nasconde un ordine perso
Un cliente ha appena comprato. Il pagamento è andato a buon fine, l'ordine è nel back office, tutto sembra a posto. Poi ti scrive: "Non ho ricevuto nessuna conferma, è tutto regolare?"
Che cosa succede in quel momento? Il cliente pensa di essere stato truffato. Alcuni annullano l'ordine, altri aprono un contenzioso con la banca, altri semplicemente non tornano più. Ho contato 298 casi simili in un anno di assistenza a negozi PrestaShop, quasi uno al giorno.
Non ti dico che ogni mail persa è un cliente perso per sempre, ma ti dico che è un cliente che ora ha un dubbio invece di una conferma. E un dubbio, nell'e-commerce, costa quanto un carrello abbandonato in un negozio fisico: il cliente è entrato, ha scelto, ha pagato, e poi nessuno gli ha dato lo scontrino.
Nei negozi che seguo, mi capita spesso di vedere store dove la mail di conferma ordine non è mai stata testata dopo l'installazione iniziale. Funziona, finché non smette di funzionare in silenzio.
Email transazionali vs email marketing: perché non sono la stessa cosa
Le mail transazionali PrestaShop (conferma ordine, spedizione, reset password) sono attese dal cliente e hanno tassi di apertura molto più alti delle newsletter. Per questo vanno protette in modo diverso, e non dovrebbero mai passare per lo stesso canale delle mail di marketing.
Se usi lo stesso dominio e lo stesso IP per l'invio massivo di offerte e per la conferma d'ordine, un blocco spam sulla newsletter trascina giù anche la mail transazionale. È come se il postino delle bollette fosse lo stesso che ti riempie la cassetta di volantini: prima o poi lo tolgono dal giro, e con lui sparisce anche la bolletta importante.
Meglio fatto che perfetto: separare i due flussi non richiede un progetto da tre mesi, richiede un pomeriggio di configurazione. Ma va fatto prima che il problema esploda, non dopo che il cliente ha già scritto al customer care.
SPF, DKIM, DMARC: i tre documenti d'identità della tua mail
Quali sono questi aspetti che ogni provider di posta controlla prima di consegnare la tua mail? Tre record DNS. Se anche uno solo manca o è configurato male, la mail rischia lo spam o il rifiuto diretto.
SPF (Sender Policy Framework)
SPF dice quali server sono autorizzati a inviare email per conto del tuo dominio. Un record tipico è questo:
v=spf1 include:_spf.google.com include:sendgrid.net ~all
Stai mandando solo "ordine ricevuto" e "ordine spedito"?
ZIP con 10 sequenze email pronte: carrello abbandonato, post-acquisto, cliente dormiente, win-back. Copia, incolla, modifica nome — funzionano.
Le email automation banali ti costano il 40% di LTV potenziale. Questa ZIP contiene 10 sequenze copy-paste-ready: 4 carrello abbandonato, 3 post-acquisto, 3 win-back. Costruite su test reali con dati di apertura/click.
Gratuito. Arriva in 30 secondi.
L'errore più comune che vedo è il server SMTP di PrestaShop non incluso in questo record. La mail parte già con un sospetto addosso, prima ancora di essere letta.
DKIM (DomainKeys Identified Mail)
DKIM firma digitalmente il contenuto della mail, garantendo che non sia stata alterata nel tragitto. Senza DKIM configurato, Gmail e molti altri provider declassano automaticamente il messaggio, anche se il mittente è legittimo.
DMARC
DMARC dice al provider destinatario cosa fare se SPF o DKIM falliscono. Un record tipo:
v=DMARC1; p=quarantine; rua=mailto:dmarc@tuodominio.it
Senza DMARC, i grandi provider tendono comunque a penalizzare il dominio, indipendentemente da quanto sia pulita la tua reputazione. Ci ho perso settimane, tempo fa, a inseguire un problema di deliverability convinto fosse colpa di PrestaShop, quando in realtà mancava solo il record DMARC. Un controllo di cinque minuti che ho fatto per ultimo invece che per primo.
Come leggere i log del mail server (senza essere un sysadmin)
Il discorso qual è? Il back office di PrestaShop ti dice se una mail è stata "inviata", non se è stata "consegnata". Sono due cose diverse, e la differenza si vede solo nei log del server SMTP.
Se hai accesso SSH al server, un comando semplice per vedere gli ultimi tentativi di invio è:
tail -f /var/log/mail.log
Cerca questi pattern, che indicano problemi concreti:
status=bounce— il destinatario ha rifiutato la mail, spesso per blacklist o SPF fallito.status=deferred— il server ci ha riprovato più volte senza successo, segno di reputazione IP compromessa.status=sent— accettata dal server ricevente, non necessariamente arrivata in posta principale. Può comunque finire in spam.
Se non hai accesso diretto ai log, il pannello del provider SMTP (SendGrid, Mailgun, Amazon SES) mostra le stesse informazioni in forma grafica. Vale la pena guardarli almeno una volta al mese, non solo quando arriva la mail del cliente arrabbiato.
Test di deliverability: scoprire il problema prima del cliente
Testare la deliverability costa cinque minuti, ignorare il problema costa ordini. Strumenti come Mail-Tester o GlockApps danno un punteggio su cento e dicono esattamente cosa manca: SPF assente, DKIM non valido, contenuto troppo simile a spam.
Il test va ripetuto ogni volta che cambi provider SMTP, ogni volta che cambi hosting, e comunque almeno una volta al trimestre. Non ti dico che basta farlo una volta per stare tranquillo per sempre, ma ti dico che un controllo trimestrale evita quasi tutte le sorprese.
Siamo pessimisti apposta: se hai 2000 ordini al mese e anche solo il 5% delle mail transazionali finisce in spam, sono 100 clienti al mese che pensano di essere stati fregati. Cento telefonate al customer care che potevi evitarti con un controllo trimestrale.
Configurare l'SMTP su PrestaShop: cosa fare subito
Quali sono i passi concreti che puoi fare oggi stesso, senza aspettare un tecnico? PrestaShop, di default, usa la funzione mail del server di hosting, che nella maggior parte dei casi ha una reputazione IP pessima perché condivisa con migliaia di altri siti.
- Vai in Parametri di negozio > Notifiche (o "Email" nelle versioni più recenti).
- Attiva l'opzione "Usa SMTP invece della funzione mail() di PHP".
- Inserisci i dati del tuo provider SMTP dedicato: server, porta 587 con TLS, username e password.
- Salva e usa il pulsante "Invia una mail di test" prima di considerare chiusa la configurazione.
- Verifica che il messaggio di test arrivi nella posta principale, non in spam, su almeno due provider diversi (Gmail e Outlook).
Non ti dico che questo risolve automaticamente ogni problema di reputazione accumulata negli anni, ma ti dico che è la base senza la quale nessun'altra correzione funziona. Se il tuo sito ha anche altri sintomi di malfunzionamento, prima di toccare le email conviene mettere in sicurezza tutto il resto: qui trovi come affrontare un sito PrestaShop down o compromesso senza perdere altro tempo.
Il caso di un produttore alimentare: quando il problema non è la mail, è il funnel intero
Ho seguito un cliente storico nel settore alimentare, produttore di riso, che si accorse del problema solo grazie a un commento su Facebook: "Ho pagato ma non ho ricevuto niente." Il controllo dei log mostrò decine di bounce silenziosi nelle settimane precedenti, mai notati perché nessuno guardava quei numeri.
La causa non era un singolo errore, ma tre problemi sommati: DKIM mai configurato, SMTP condiviso con un IP già segnalato, e zero monitoraggio dei bounce. Non un guasto, un sistema mai messo in piedi correttamente fin dall'inizio.
Non è la mail il problema vero, in questi casi. È la mentalità con cui si tratta l'infrastruttura tecnica: qualcosa che si configura una volta e si dimentica, invece di qualcosa che si controlla con la stessa regolarità con cui si controlla il magazzino. Lo stesso principio vale per recuperare i carrelli abbandonati: se non monitori il flusso, il problema cresce in silenzio.
Quando serve un esperto
Che cosa facciamo se hai già controllato SPF, DKIM, DMARC, hai configurato l'SMTP e il problema persiste? A quel punto la causa è quasi sempre più profonda: reputazione IP storica compromessa, conflitti tra moduli PrestaShop che inviano mail per conto proprio, o un mix di configurazioni contrastanti tra hosting e provider terzo.
Non ti dico che serve rifare tutto da capo, ma ti dico che senza una diagnosi strutturata rischi di girare in tondo per settimane, magari cambiando provider SMTP tre volte senza risolvere nulla. Il tempo che ci perdi, moltiplicato per il valore della tua ora, spesso supera già il costo di una diagnosi seria fatta bene la prima volta.
Per questo esiste l'Audit Tecnico Approfondito PrestaShop: 497 euro, causa individuata in 24-48 ore, con analisi completa di log, DNS, configurazione SMTP e moduli coinvolti. Non è la soluzione per chi vuole provare a caso ancora una volta. È la soluzione per chi vuole sapere, con certezza, cosa sta bloccando davvero le proprie email. Se invece il problema email è solo la punta di un problema più ampio di conversioni, vale la pena capire anche dove il tuo funnel perde clienti prima ancora che arrivino a comprare.
Domande frequenti
Perché le email di PrestaShop finiscono in spam anche se il sito funziona bene?
Perché la deliverability dipende dai record DNS (SPF, DKIM, DMARC) e dalla reputazione dell'IP del server SMTP, non dal corretto funzionamento del sito. Un e-commerce può girare perfettamente e avere comunque email transazionali bloccate o filtrate come spam.
Come faccio a sapere se un'email PrestaShop è stata davvero consegnata?
Il back office mostra solo lo stato "inviata", non "consegnata". Devi controllare i log del mail server o il pannello del provider SMTP, cercando pattern come status=sent, status=bounce o status=deferred.
Quanto costa risolvere un problema di email PrestaShop che non arrivano?
Configurare SMTP e record DNS è gratuito e richiede al massimo un pomeriggio di lavoro tecnico. Se il problema persiste dopo questi controlli, un Audit Tecnico Approfondito PrestaShop (497 euro) individua la causa reale in 24-48 ore, evitando settimane di tentativi a caso.
SPF, DKIM e DMARC vanno configurati tutti e tre insieme?
Sì. Configurarne solo uno o due lascia comunque margine ai grandi provider di posta per penalizzare il dominio. Sono tre livelli di verifica complementari, non alternativi.
Devo usare lo stesso SMTP per newsletter e mail transazionali?
No, è meglio separarli. Se il dominio o l'IP usato per la newsletter finisce segnalato come spam, trascina giù anche le mail di conferma ordine, con conseguenze dirette sugli ordini persi.
Il passo successivo
Le email PrestaShop che non arrivano non sono un dettaglio tecnico: sono ordini che rischi di perdere e clienti che iniziano a diffidare del tuo negozio. Se hai già provato SMTP, SPF, DKIM e DMARC e il problema è ancora lì, non serve un altro tentativo a caso.
Vai su francescoingrosso.com e richiedi l'Audit Tecnico Approfondito PrestaShop: causa individuata in 24-48 ore, senza girare in tondo un'altra volta.
