Qualcuno compila il tuo modulo di contatto. La pagina lo conferma: “Grazie, ti ricontatteremo presto.” Chiude la scheda e aspetta di sentirti.
Tu non chiami mai, perché il messaggio non ti è mai arrivato. Nessuna e-mail, né quel giorno né dopo. Il potenziale cliente resta lì in silenzio, poi va a cercare la prossima attività il cui modulo funziona davvero. Niente sullo schermo ha mai avvisato nessuno dei due che qualcosa era andato storto.
Come WordPress invia davvero questa e-mail
Ecco l’impianto, in parole semplici. Quando qualcuno invia un modulo WordPress, il sito chiama una funzione chiamata wp_mail, che per impostazione predefinita passa il messaggio alla funzione integrata mail() di PHP invece che a un servizio di posta dedicato. PHP mail non fa l’accesso da nessuna parte, non dimostra che sei davvero tu a inviarlo e non passa per il tipo di infrastruttura verificata che Gmail o Outlook si aspettano da un mittente legittimo. Chiede semplicemente al tuo server web di spingere fuori un’e-mail e spera che vada tutto bene. Un tempo bastava. Oggi quasi mai, perché i provider di posta hanno alzato la guardia proprio contro questo tipo di invio non autenticato e poco curato, e una semplice chiamata a mail() supera raramente il filtro.
L’e-mail finge di arrivare da te, e nessuno ci crede
Il tuo modulo di contatto di solito è configurato per inviare “da” un indirizzo come you@yoursite.com, o da qualcosa che non esiste nemmeno, come wordpress@yoursite.com. Il campo Da dice che sei tu, ma il server che invia davvero il messaggio non è mai stato autorizzato a inviare posta per conto del tuo dominio. Oggi tutti i principali provider di posta controllano questa autorizzazione. Quando manca, non ti rimandano indietro il messaggio con un errore chiaro che potresti notare. Lo scartano in silenzio, o lo archiviano in un posto che non aprirai mai. Il tuo sito non è rotto in nessun modo che potresti notare guardandolo. Sta facendo un’affermazione che non può dimostrare, e i provider hanno smesso di crederci sulla parola.
Il tuo hosting non invia la posta, o ne invia poca
Non tutti i piani di hosting permettono a un sito di inviare e-mail liberamente. L’hosting condiviso in particolare spesso limita quanti messaggi un dominio può inviare all’ora, o blocca del tutto la funzione mail di PHP, perché un altro cliente dello stesso server una volta l’ha usata per mandare spam e il provider ha bloccato l’intera funzione. Se il tuo provider è uno di quelli rigidi, il tuo modulo può sembrare perfettamente a posto (la pagina conferma, il codice gira senza errori) mentre l’invio vero e proprio viene inghiottito prima ancora di uscire dall’edificio. Non vedrai nessun messaggio di errore, perché il problema avviene su un’infrastruttura in cui non puoi guardare dentro.
Il tuo dominio non può dimostrare che la posta è legittima
Anche quando la posta viene effettivamente inviata, i provider che la ricevono controllano dei record DNS chiamati SPF e DMARC per decidere se fidarsi. Insieme, sono il modo in cui il tuo dominio dichiara quali server possono inviare posta a suo nome e cosa deve fare un server ricevente con un messaggio che non supera quel controllo. Su un sito WordPress dove nessuno li ha configurati di proposito, spesso mancano o sono configurati male, e la posta del tuo dominio finisce per somigliare esattamente al tipo di messaggio che questi sistemi esistono per filtrare.
Funzionava, finché un aggiornamento non ha cambiato qualcosa
Il core di WordPress, il tuo tema e ogni plugin del sito si aggiornano ciascuno con i propri tempi, e uno qualsiasi di loro può cambiare in silenzio il modo in cui viene inviata la posta. Un aggiornamento del plugin dei moduli cambia la sua libreria di invio. Un plugin di sicurezza inizia a bloccare una connessione in uscita che prima permetteva. Un plugin di cache continua a mostrare la vecchia pagina di conferma anche dopo che l’invio lato server ha iniziato a fallire. Niente di tutto questo compare come errore nella tua Bacheca, perché dal punto di vista di WordPress il modulo è stato inviato correttamente. È lo strato sottostante ad aver smesso di funzionare in silenzio, e un aggiornamento è il motivo più comune per cui quello strato cambia senza che nessuno lo tocchi di proposito.
Il test di 10 minuti
Prima di sistemare qualcosa, verifica cosa sta succedendo davvero. Ci vogliono circa dieci minuti e ti dice con quale dei problemi descritti sopra hai a che fare.
- Fai un vero invio di prova, usando un indirizzo e-mail che non sia Gmail: un indirizzo di lavoro, un account Outlook, quello che hai. Il filtro antispam di Gmail è già abbastanza aggressivo da solo, tanto che un test fatto solo con Gmail può nascondere un problema che un altro provider avrebbe individuato.
- Controlla la cartella spam o posta indesiderata, non solo la posta in arrivo, dell’indirizzo che hai usato per il test. Un messaggio finito nello spam è un problema diverso da un messaggio che non è mai arrivato, e ti indirizza verso la sezione su SPF e DMARC qui sopra invece che verso un blocco dell’hosting.
- Guarda il vero registro delle e-mail, non il messaggio di conferma. La maggior parte degli hosting ha un registro delle e-mail in cPanel o nel pannello di controllo, oppure puoi installare un plugin gratuito come WP Mail Logging, che registra ogni e-mail che WordPress prova a inviare e se ci è riuscito. Questo solo passaggio ti dice se WordPress ci ha almeno provato.
- Invia una seconda prova a un provider diverso. Se arriva su Outlook ma non su Gmail, è un segnale forte che si tratta di un problema di autenticazione legato al modo in cui un provider valuta il tuo dominio, non di un blocco generale dell’hosting.
- Passa il tuo dominio al Check-up del sito. Controlla i tuoi record SPF e DMARC (non DKIM, che richiede un tipo di verifica diverso) e ti dice in meno di un minuto se il tuo dominio è configurato per dimostrare che la sua posta è legittima. Un avviso lì di solito spiega tutto quello che c’è sopra.
Le soluzioni oneste
Una volta capito con quale problema hai a che fare, la soluzione di solito è una tra poche. Nessuna è un trucco; ognuna è un modo reale per risolverlo.
Installa un plugin SMTP. È la risposta standard degli sviluppatori, ed è una risposta corretta. Un plugin SMTP fa passare la tua posta in uscita attraverso un vero servizio di posta invece che dalla funzione mail() di PHP, e questo risolve il problema di autenticazione alla radice, perché ora la posta arriva davvero da un’infrastruttura di cui i provider già si fidano. Ci vogliono una ventina di minuti se ti senti a tuo agio a creare una chiave API e incollarla in una schermata di impostazioni. Altrimenti, è un’ora di lavoro ragionevole da affidare a uno sviluppatore.
Passa a un servizio per i moduli. Gli strumenti creati apposta per gestire gli invii dei moduli, invece di un plugin agganciato a wp_mail, spesso inviano le notifiche attraverso la propria infrastruttura di invio verificata, aggirando del tutto il problema. Rinunci a un po’ di controllo sull’aspetto e sul comportamento esatti del modulo. In cambio ottieni un servizio il cui unico compito è assicurarsi che il messaggio arrivi.
Fai gestire il sito a qualcun altro. Se preferisci non imparare cosa significa SPF, è una posizione legittima, non una tua mancanza. È esattamente il tipo di manutenzione che sfugge su un sito WordPress gestito in autonomia: nessuno se ne accorge finché un potenziale cliente non chiama un concorrente. Se preferisci smettere di essere tu a controllare un registro delle e-mail ogni volta che un aggiornamento rompe qualcosa, passa all’opzione per non pensarci mai più.
Perché continua a rompersi
Un sito WordPress non è qualcosa che si finisce. È una pila di componenti che si aggiornano ciascuno per conto proprio (il core, il tema, una dozzina di plugin, l’hosting sotto a tutto) e ognuno può spostare il terreno su cui poggiano gli altri. Un aggiornamento di un plugin tra sei mesi può rompere di nuovo questo stesso modulo in un modo completamente diverso, e non sarà colpa tua, così come non lo è adesso. È il prezzo di un software che nessuno sta sorvegliando attivamente. La versione più estrema che abbiamo visto non riguardava nemmeno un modulo: 32 link di spam nascosti erano stati iniettati nel codice WordPress di un’impresa di traslochi fondata da veterani, invisibili sulla pagina, e ne affossavano in silenzio il posizionamento nei motori di ricerca finché un audit non li ha scoperti. Un modulo di contatto rotto è il problema che noti, perché i potenziali clienti smettono di chiamare. Molti guasti di WordPress non vengono mai notati.
Se non vuoi più dover risolvere questo problema
Se preferisci non essere tu a controllare i registri delle e-mail e leggere i record DNS ogni volta che questo si rompe, è proprio ciò di cui Surmado Sites si occupa come parte della gestione del sito: hosting e consegna della posta, più la manutenzione che impedisce a una correzione di sfaldarsi al prossimo aggiornamento. Lo chiedi una volta, in parole semplici, e resta sistemato.
Domande frequenti
Perché il modulo dice “inviato” se non arriva niente?
La conferma “messaggio inviato” viene generata da WordPress nel momento in cui il modulo viene inviato e viene chiamata wp_mail. Non aspetta che un server di posta confermi se il messaggio è stato davvero consegnato, perché la maggior parte delle configurazioni dei moduli di contatto non è pensata per verificarlo. La conferma significa che WordPress ha tentato l’invio. Non significa che qualcuno l’abbia ricevuto.
Gli invii finiscono nello spam?
A volte, ma non sempre. Se i tuoi record SPF o DMARC sono configurati male, la posta che viene effettivamente inviata finisce spesso nello spam, perché i provider che la ricevono non possono verificare che arrivi davvero dal tuo dominio. Se il tuo hosting blocca del tutto l’invio, o un conflitto tra plugin lo ferma prima che esca dal server, la posta non viene mai inviata, quindi non è nemmeno nello spam. Controllare un registro delle e-mail, o il risultato del tuo Check-up del sito, ti dice in quale delle due situazioni ti trovi.
Perché ha smesso di funzionare dopo un aggiornamento?
Perché qualcosa in quella catena di aggiornamenti ha cambiato il modo in cui la posta viene inviata, o se viene inviata del tutto, e nessuno di questi cambiamenti compare come errore visibile da qualche parte in WordPress. Raramente è il plugin che sospetteresti per primo. Per questo vale la pena controllare il registro delle e-mail subito dopo ogni aggiornamento: bastano due minuti, prima di cominciare a cercare il problema alla cieca.
Mi serve un plugin SMTP?
Non sempre, ma spesso sì. Se i record SPF e DMARC del tuo dominio sono a posto e il vero problema è un hosting che blocca o limita la posta di PHP, un plugin SMTP che fa passare la posta per un vero servizio di posta è la soluzione più diretta. Se il problema sono i record DNS, sistema prima quelli; un nuovo metodo di invio non servirà a nulla se il dominio stesso non riesce ancora a dimostrare di essere legittimo. In ogni caso, un plugin SMTP è una soluzione reale e diffusa, non un ripiego, ma è anche una cosa in più da configurare e mantenere funzionante, ed è proprio questa la parte che un servizio per i moduli o un sito gestito ti tolgono di dosso.