Gestisco diversi siti WordPress. Su ognuno parte un numero di email che nessuno immagina: notifiche di contatto, reset password, conferme d’ordine, avvisi ai gestori. Il log email WordPress di FluentSMTP è lo strumento che controllo appena un cliente mi scrive “non ho ricevuto niente”. Prima guardavo i log del server SMTP a riga di comando. Dovevo far corrispondere a mano grep e timestamp. Ora apro una pagina nel pannello di WordPress e ho tutto davanti.
Perché controllo il log email WordPress prima dei log del server
Il caso tipico è sempre lo stesso. Un modulo di contatto che “non arriva”. Un cliente che non riceve l’email di reset password. Un ordine che resta senza conferma. Senza un log a portata di mano, la prima ipotesi è la cartella spam. Poi i log del server SMTP. Poi magari il firewall. Con FluentSMTP salto quei passaggi. Vedo subito se WordPress ha davvero provato a spedire quell’email. A chi, quando, con quale risposta del server di invio.
FluentSMTP registra ogni chiamata a wp_mail(). Non solo le email dei plugin di terze parti, anche quelle generate dal core: notifiche di nuovo utente, promemoria di aggiornamento, avvisi di errore. Per ogni invio il log mostra mittente, destinatario, oggetto, intestazioni complete, corpo del messaggio. E la risposta del provider SMTP o dell’API usata. Se un’email è finita in errore, quella risposta del server è lì. Non devo indovinarla.
Cosa trovo davvero nel registro degli invii
Il plugin supporta decine di connettori: Amazon SES, SendGrid, Mailgun, Brevo, Postmark, SparkPost. Anche Google Workspace e Microsoft 365 via OAuth, oltre al classico SMTP generico. Sui siti che gestisco uso quasi sempre SMTP autenticato con il dominio del cliente. Qualche volta un’API dedicata, quando il volume di email cresce. In entrambi i casi il log email WordPress non cambia. Ogni riga ha uno stato, inviata o fallita. C’è un pulsante per rivedere il contenuto o rispedire il messaggio, senza che l’utente debba rifare l’azione che l’ha generato.
Il rinvio manuale è la funzione che uso più spesso. Un modulo compilato due volte perché “non arrivava” diventa un clic sul log. Non una nuova segnalazione al cliente. Per i fallimenti ripetuti ho attivato le notifiche su Telegram. Appena una connessione smette di funzionare, lo so prima che me lo scriva qualcuno. Invece di scoprirlo da un ticket di supporto.
Il log non riguarda solo le notifiche dirette a me o al cliente che amministra il sito. Finisce lì ogni email in uscita generata dal sito verso terzi: la conferma d’ordine che un negozio online manda al cliente finale, la ricevuta di un pagamento, la notifica di spedizione. Se quella conferma non arriva, la vedo nel log email WordPress esattamente come una notifica interna, con lo stesso pulsante per rispedirla al destinatario giusto senza fargli ripetere l’acquisto.
Come configuro FluentSMTP sui siti che gestisco
Dopo aver collegato il connettore giusto, cambio la conservazione del log. Di default resta attivo a lungo. Io lo porto a 30-60 giorni, in base al traffico del sito. Serve per risalire a un problema segnalato in ritardo. Senza riempire il database di righe che non consulterò mai. Attivo poi almeno un canale di notifica per i fallimenti, Telegram o Slack secondo il cliente. Il log da solo non avvisa nessuno: va aperto per essere letto.
Sui siti con form di contatto uso anche Cisilino Site Defense Network per il blocco dei bot. Meno spam in ingresso significa meno email generate dai moduli. Il log resta più leggibile, con meno rumore da filtrare quando cerco il messaggio giusto.
Le credenziali SMTP non restano in chiaro nel database
Un dettaglio che controllo sempre prima di salvare una connessione: dove finiscono le credenziali. FluentSMTP le cifra di default con le chiavi SALT di WordPress, quelle già presenti in wp-config.php per sicurezza delle sessioni. Si può disattivare la cifratura, ma il plugin stesso lo segnala come sconsigliato. Sui siti che gestisco preferisco un’altra opzione: salvare la password API o SMTP direttamente in wp-config.php, fuori dal database, definendo le costanti prima che il plugin le legga. Così anche un dump del database o un accesso non autorizzato al pannello non espone la chiave del provider di invio. È lo stesso principio che applico altrove: meno segreti nel database, meglio è.
Più connessioni insieme, non solo una alla volta
FluentSMTP permette di configurare più connessioni insieme, non solo una alla volta. Su un sito imposto quella predefinita e ne aggiungo una seconda come riserva: se il primo provider non risponde, l’invio passa automaticamente alla connessione di riserva, senza che io debba intervenire. La scelta della connessione dipende dall’indirizzo del mittente: ogni connessione ha il suo “From”, il resto passa per quella predefinita, con la riserva pronta solo se la predefinita fallisce davvero (un errore del provider, non un’email finita in spam). È una delle ragioni per cui lo preferisco a un singolo SMTP senza alternative: se SendGrid o Amazon SES hanno un problema per qualche ora, il sito continua comunque a spedire, e lo vedo subito nel log email WordPress. Tutto incluso nella versione gratuita, senza una versione pro a pagamento: si paga solo il provider di invio scelto, non il plugin.
Un controllo di salute ogni giorno, non solo quando qualcosa si rompe
Oltre al log riga per riga, FluentSMTP fa un controllo di salute della connessione ogni giorno, in automatico. Se il provider smette di rispondere, l’avviso arriva prima che un cliente mi scriva “il sito non manda più email”. Lo stesso pannello mostra un grafico con i totali giornalieri di invii riusciti e falliti: utile per capire a colpo d’occhio se un calo è normale o è il sintomo di qualcosa che si sta rompendo, senza dover aprire il log email WordPress riga per riga ogni volta. C’è anche un riepilogo periodico via email, con i totali della settimana: non è un avviso di errore, è un bollettino che leggo di sfuggita per sapere se il volume di invii è nella norma.
Per chi, come me, gestisce più siti da riga di comando, FluentSMTP espone anche dei comandi WP-CLI: un test di invio, un controllo di salute della connessione, le statistiche e la pulizia dei log vecchi. Li uso negli stessi script che già girano sui server per altri controlli di manutenzione, senza dover aprire il pannello di ogni sito uno per uno.
I limiti onesti del log email WordPress
Non è una soluzione magica. La conservazione è basata sui giorni, non su un numero massimo di righe. Su un sito con molto traffico transazionale la tabella del log può crescere in fretta. Conviene tenerla sotto controllo, o impostare una conservazione più breve. Le notifiche di fallimento arrivano solo sui canali di chat configurati, non per email. Ha senso: un’email che avvisa di un’email fallita rischia di fallire a sua volta. Ma va saputo prima di contarci.
Infine il log registra cosa è successo lato WordPress e lato provider. Non garantisce la consegna nella casella del destinatario. Se un’email è segnata come inviata ma finisce in spam, è un problema di reputazione del dominio o di configurazione SPF/DKIM. Non qualcosa che un log può risolvere da solo. Resta comunque il primo posto dove guardo, prima di qualsiasi altra verifica.
Il plugin è gratuito e open source. Pagina ufficiale su wordpress.org, senza funzioni bloccate dietro una versione pro. Per chi gestisce anche un solo sito con un modulo di contatto, vale la pena installarlo solo per il log email WordPress. La prima volta che risolve un “non ho ricevuto l’email” in un minuto invece che in mezz’ora, si è ripagato.
Lascia un commento