Ogni sito web invia email. Conferme d'ordine, reimpostazioni della password, messaggi dei moduli di contatto e promemoria delle prenotazioni rientrano tutti nelle email transazionali, una categoria che nessuno pianifica ma da cui tutti dipendono. Di solito viene configurata una volta da chi ha realizzato il sito e poi non viene più controllata.
Poi i clienti smettono di ricevere le conferme d'ordine e si scopre che finiscono nello spam da otto mesi. In questa guida vediamo perché succede su qualsiasi piattaforma e quale configurazione consente di evitarlo.
Perché le email transazionali del sito smettono di funzionare senza avvisare
La configurazione predefinita della maggior parte delle piattaforme invia le email direttamente dal server web, tramite la funzione di posta messa a disposizione dal linguaggio di programmazione. Durante i test sembra funzionare, perché controlli la tua casella e il tuo provider considera attendibili i tuoi messaggi.
In produzione, invece, l'invio fallisce per un motivo che non dipende dal codice. Il server web non ha una reputazione come mittente, il suo indirizzo IP è condiviso con gli altri servizi gestiti dall'hosting e il messaggio dichiara di provenire dal tuo dominio pur partendo da un server che il dominio non ha mai autorizzato. I provider destinatari considerano questo comportamento un tentativo di falsificazione perché, nella maggior parte dei casi, lo è. Proprio per questo le linee guida di Google per i mittenti richiedono l'autenticazione.
Dal tuo punto di vista, il problema non lascia tracce. Il sito segnala che l'email è stata inviata, i log non riportano errori e nulla indica che il messaggio sia finito nello spam del destinatario. Le email transazionali dei siti sono particolarmente incapaci di segnalare i propri problemi, perciò spesso ci si accorge del guasto solo mesi dopo, in seguito al reclamo di un cliente.
Lo stesso problema su ogni piattaforma
Non è un problema esclusivo di WordPress, anche se WordPress viene accusato più spesso perché è la piattaforma più diffusa. Il meccanismo è identico ovunque.
WordPress utilizza per impostazione predefinita la funzione mail di PHP, quindi invia direttamente dal server con tutti i problemi descritti sopra. Un plugin SMTP sostituisce questa funzione ed è la soluzione abituale.
Shopify, Wix e Squarespace inviano le proprie email transazionali da un'infrastruttura generalmente ben gestita. Tuttavia, se non effettui una configurazione specifica, non sempre consentono di inviare dal tuo dominio con un'autenticazione corretta. Di conseguenza, il messaggio dichiara di provenire dalla tua azienda, ma la sua origine non può essere verificata.
Webflow, Ghost e le applicazioni personalizzate funzionano in modi diversi, ma lo schema non cambia: il sistema di invio predefinito raramente è autenticato per il tuo dominio.
La soluzione valida per tutte queste piattaforme consiste nell'instradare le email transazionali del sito attraverso una connessione SMTP autenticata, utilizzando un dominio i cui record DNS autorizzino quella connessione all'invio.
La soluzione in tre parti
Servono tre elementi, tutti indispensabili. Configurarne soltanto due può comunque far finire i messaggi nello spam.
Un account SMTP da utilizzare per l'invio. Anziché spedire direttamente dal server web, il sito si autentica presso un server di posta e gli affida il messaggio. Ogni piattaforma offre questa possibilità, in modo nativo oppure tramite un plugin.
Record DNS che autorizzino l'invio. Occorrono un record SPF che identifichi il server mittente e una firma DKIM che renda verificabile il messaggio. Senza questi elementi, anche un invio autenticato apparirà non autorizzato al destinatario. Le nostre guide dedicate a SPF e DKIM spiegano come configurare entrambi i record.
Un indirizzo mittente esistente. Inviare da noreply@tuodominio.com quando quella casella non esiste rappresenta un piccolo ma concreto segnale negativo e fa sparire ogni eventuale risposta. Qui la creazione della casella non comporta costi aggiuntivi, perché il prezzo non è calcolato per singolo utente.
Separare queste email dalla corrispondenza
Superata una certa quantità di messaggi, conviene dedicare alle email transazionali del sito un percorso di invio separato.
Le email automatiche e quelle scritte dalle persone si comportano in modo diverso e vengono valutate secondo criteri diversi. Cinquecento richieste di reimpostazione della password inviate in rapida successione dopo un incidente di sicurezza non assomigliano affatto alla normale corrispondenza di una persona. Se entrambe passano dallo stesso percorso, la reputazione del traffico automatico diventa anche la reputazione delle email del tuo team.
I profili SMTP per dominio semplificano la separazione: indirizza il dominio usato dall'applicazione su un percorso e quello utilizzato dal personale su un altro. In questo modo, un problema su un lato rimane circoscritto. La procedura è descritta nella guida all'SMTP personalizzato per dominio.
Alcune aziende scelgono persino un sottodominio distinto per tutte le email automatiche. In questo modo isolano completamente la reputazione, accettando però un indirizzo mittente leggermente meno elegante. La convenienza di questa scelta dipende dal volume.
Quando è preferibile un provider di email transazionali
È bene indicare con chiarezza il limite: per volumi davvero elevati, i servizi dedicati alle email transazionali esistono per ottimi motivi.
Se invii decine di migliaia di messaggi al giorno, ti servono eventi di consegna per ogni messaggio, notifiche webhook per i mancati recapiti, gestione dei modelli e statistiche dettagliate. Queste funzioni sono lo scopo principale di tali servizi e nessun provider di hosting email riesce a offrirle altrettanto bene.
I nostri limiti giornalieri sono pensati per la corrispondenza, non per le campagne: 1.000 messaggi per casella al giorno con Starter e fino a 2.500 con Agency. Le email transazionali di un piccolo negozio o di un sistema di prenotazione rientrano facilmente in questi limiti. Una piattaforma ad alto volume, invece, no. In quel caso, l'architettura corretta prevede un provider transazionale collegato tramite un profilo SMTP personalizzato. Così l'hosting della posta e gli invii massivi rimangono separati senza dover ricorrere a due provider per la gestione delle caselle.
Verificare che funzioni davvero
Poiché questo tipo di problema non dà segnali, l'abitudine più utile è verificare il recapito anziché darlo per scontato.
Genera un messaggio reale: effettua un ordine di prova o richiedi la reimpostazione di una password. Invialo a indirizzi gestiti da due diversi provider importanti. Apri le intestazioni e verifica che SPF e DKIM siano stati superati e che DMARC confermi l'allineamento. Se tutti e tre i controlli hanno esito positivo, la configurazione è realmente completa.
Ripeti questa verifica ogni tre mesi e subito dopo qualsiasi modifica al DNS o cambio di hosting. Le email transazionali del sito non smettono di funzionare durante la configurazione iniziale, ma più spesso quando cambia qualcosa nelle vicinanze e nessuno pensa di ricontrollare le conferme d'ordine dopo il trasferimento dei nameserver.
Se i messaggi vengono recapitati ma finiscono nello spam, le statistiche di consegna del dominio e gli eventuali report DMARC indicano quasi sempre la causa molto più rapidamente di tentativi casuali di modifica del contenuto.
