SMTP Relay: configurazione affidabile per l’invio email dal server

Un SMTP relay è la via più solida quando il server deve inviare email in modo affidabile senza esporsi ai limiti tipici dell’invio diretto. In pratica, il tuo server prepara il messaggio e lo consegna a un relay esterno o interno, che si occupa di recapitarlo ai destinatari con infrastruttura, reputazione e controlli migliori.

È una scelta utile per siti WordPress, pannelli hosting, applicazioni PHP, script di sistema, notifiche di backup, ticket, ordini e alert tecnici. Se l’invio diretto fallisce, finisce in spam o viene rifiutato per reputazione IP, il relay spesso risolve il problema alla radice.

La logica giusta non è “spedire email e sperare”. La logica giusta è: autenticazione corretta, coda controllata, log leggibili, DNS coerente e test ripetibili.

Quando serve davvero un SMTP relay

Usa un relay se il server è una VPS, un hosting condiviso con limiti stretti, un ambiente con IP nuovo o poco reputato, oppure se invii email applicative e vuoi evitare che il provider blocchi la porta 25 o degradi la consegna. È particolarmente utile quando il mittente è un sito web che genera notifiche automatiche e non una casella interattiva usata da persone.

È anche la scelta giusta se vuoi separare l’infrastruttura del sito dalla posta: il web server resta leggero, mentre il relay gestisce autenticazione, rate limit, retry e reputazione. Questo riduce il rischio di dover inseguire problemi di deliverability su ogni singolo server.

Diagnosi prima della configurazione

Prima di cambiare impostazioni, verifica tre punti: il server riesce a uscire in rete sulla porta SMTP corretta, l’account relay è valido, e il dominio mittente è coerente con SPF, DKIM e DMARC. Senza questi tre elementi, il relay può funzionare solo a metà.

Controlla anche se il tuo software invia email tramite PHP mail(), Postfix, Exim, msmtp, nodemailer, Laravel, WordPress o un altro sistema. Il punto di integrazione cambia, ma il principio resta lo stesso: il server deve autenticarsi verso il relay e presentare un mittente credibile.

Scelta del relay: criteri pratici

Un buon relay deve offrire autenticazione SMTP stabile, TLS, log accessibili, limiti chiari, supporto per domini personalizzati e possibilità di monitorare bounce e reject. Se il tuo obiettivo è affidabilità, non scegliere solo in base al prezzo.

Valuta questi aspetti:

• supporto a STARTTLS o TLS implicito;
• autenticazione con username e password o token dedicato;
• limiti giornalieri e per minuto;
• tracciamento degli invii e degli errori;
• possibilità di usare il dominio del cliente o del progetto;
• presenza di IP reputati e politiche anti-abuso chiare.

Se il relay è esterno, leggi bene le policy su contenuti vietati, bulk email e allegati. Un relay affidabile non deve diventare un punto cieco: deve aiutarti a capire dove si rompe la consegna.

Prerequisiti DNS e reputazione

Il relay non sostituisce DNS corretti. Anche se usi un provider esterno, il dominio deve avere record coerenti per SPF, DKIM e DMARC. Se il mittente è noreply@tuodominio.it, il dominio deve autorizzare chi invia e firmare i messaggi in modo verificabile.

In sintesi:

• SPF: dichiara quali server possono inviare per il dominio;
• DKIM: firma il messaggio in modo verificabile;
• DMARC: indica come trattare i messaggi non allineati;
• PTR/rDNS: utile se invii anche direttamente dal server;
• HELO/EHLO: deve essere coerente con il nome del server.

Se il relay richiede un dominio verificato, completa prima la verifica. Se non lo fai, molti invii partiranno ma il recapito resterà instabile o verrà ridotto a livello di reputazione.

Configurazione consigliata su Linux con Postfix

Se il server usa Postfix, il modo più pulito è configurarlo come smarthost, cioè un inoltratore autenticato verso il relay. Prima di modificare i file, fai un backup della configurazione corrente.

sudo cp /etc/postfix/main.cf /etc/postfix/main.cf.bak.$(date +%F-%H%M%S)

Poi modifica /etc/postfix/main.cf e imposta i parametri principali. I valori esatti dipendono dal provider, ma la struttura tipica è questa:

relayhost = [smtp.relay-provider.tld]:587
smtp_sasl_auth_enable = yes
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_sasl_security_options = noanonymous
smtp_tls_security_level = may
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Ora crea il file delle credenziali, sempre con attenzione ai permessi:

sudo nano /etc/postfix/sasl_passwd

Contenuto tipico:

[smtp.relay-provider.tld]:587 username:password

Compila la mappa e limita i permessi:

sudo postmap /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd /etc/postfix/sasl_passwd.db

Riavvia Postfix e verifica che la configurazione sia valida:

sudo postfix check
sudo systemctl restart postfix
sudo systemctl status postfix --no-pager

L’esito atteso è servizio attivo e senza errori di sintassi. Se compare un errore, controlla subito /var/log/mail.log o /var/log/maillog in base alla distribuzione.

Configurazione con Exim, cPanel o Plesk

Se usi cPanel, in genere conviene lavorare da WHM e dal gestore mail del pannello, perché la configurazione locale può essere sovrascritta dagli aggiornamenti o dalle policy del server. In WHM verifica la configurazione di Exim e il routing della posta in uscita. Se il pannello offre un’opzione per smart host o SMTP relay, usala preferibilmente rispetto a modifiche manuali.

Su Plesk, il percorso più pratico è controllare le impostazioni del server di posta e, se necessario, configurare il relay dalla sezione dedicata al mail server. Anche qui il vantaggio è la persistenza delle impostazioni e la gestione più semplice dei log.

Se il pannello non espone il relay in modo diretto, allora si passa alla configurazione del mail transfer agent sottostante. Prima però salva sempre la configurazione corrente e verifica se il pannello gestisce in automatico i file di servizio. In caso contrario, una modifica manuale può essere persa al prossimo update.

Configurazione per WordPress e applicazioni web

Per WordPress, il relay non si imposta nel core del CMS ma tramite un plugin SMTP affidabile. Il criterio non è “quale plugin è famoso”, ma “quale plugin consente log, test di invio e autenticazione chiara”.

La sequenza corretta è questa:

1. installa il plugin SMTP scelto;
2. imposta host, porta, cifratura e credenziali del relay;
3. forza il mittente con un indirizzo del dominio verificato;
4. esegui un test di invio a una casella esterna;
5. controlla header e log del messaggio ricevuto.

Per applicazioni PHP o framework, è preferibile usare librerie SMTP native o un mailer applicativo invece di affidarsi alla funzione mail() del sistema. Questo riduce le variabili e rende più semplice il debug. Se l’app supporta file di configurazione, conserva host, porta, username e password in variabili d’ambiente o secret management, non nel codice sorgente.

Porta, cifratura e autenticazione

Le porte più comuni sono 587 per submission con STARTTLS e 465 per TLS implicito, se supportato dal provider. La porta 25 è spesso bloccata o sconsigliata per client autenticati. In ambiente moderno, 587 è di solito la scelta più compatibile.

Usa sempre cifratura se il relay la supporta. L’autenticazione in chiaro senza TLS è una cattiva idea, soprattutto su VPS o reti non completamente fidate. Se il provider usa certificati validi, il client deve verificarli; se noti errori TLS, non disattivare la verifica alla cieca, ma controlla catena certificati, hostname e CA del sistema.

Se il relay richiede un nome host specifico, usa quello esatto. Un mismatch tra nome configurato e certificato presentato può bloccare l’invio o generare warning che poi diventano problemi intermittenti difficili da inseguire.

Test di invio e lettura dei log

Un relay non si considera operativo finché non hai fatto almeno un test end-to-end. Il test deve includere invio, consegna, ricezione e analisi degli header. Non basta vedere “messaggio inviato” nel pannello: serve conferma lato destinatario.

Esegui una prova verso una casella esterna e controlla questi elementi:

• timestamp di invio coerente;
• assenza di errori di autenticazione;
• codice SMTP di successo;
• header con Received coerenti;
• presenza, se previsto, di firma DKIM valida.

Se il messaggio non arriva, la sequenza di debug è: log applicativo, log del mailer locale, log del relay, poi analisi del destinatario. Saltare questi passaggi porta quasi sempre a diagnosi sbagliate.

Su Linux, i log principali spesso si trovano in /var/log/mail.log, /var/log/maillog o nei log del pannello. Cerca errori come autenticazione fallita, relay denied, timeout, connessione rifiutata, TLS handshake error o rate limit.

Errori più comuni e come leggerli

Gli errori SMTP più frequenti hanno significati molto concreti. 535 Authentication failed indica credenziali errate, account bloccato o metodo non supportato. 550 Relay denied indica che il server non autorizza quel mittente o quella destinazione. 421 Temporary failure suggerisce un problema transitorio o un limite superato. Timeout o connection refused spesso indicano firewall, porta sbagliata o servizio non raggiungibile.

Se ricevi un errore di reputazione o contenuto, il problema non è il trasporto ma il messaggio. In quel caso controlla dominio mittente, allineamento SPF/DKIM/DMARC, qualità del contenuto, link, allegati e frequenza di invio. Un relay serio non deve essere usato per mascherare un sistema di posta mal configurato.

Quando la coda si accumula, verifica se il relay sta rifiutando in modo temporaneo. Un backlog crescente è spesso il segnale più utile: ti dice che il problema non è un singolo messaggio, ma il canale completo di consegna.

Affidabilità operativa: cosa monitorare

Se il relay è parte della produzione, non basta configurarlo una volta. Va monitorato. Le metriche utili sono poche ma decisive: volume inviato, errori per codice SMTP, tempi di consegna, coda locale, bounce rate, retry rate e percentuale di successo degli invii.

Per il server di origine osserva anche CPU, RAM e I/O, perché una coda di posta bloccata può essere il sintomo di un problema più ampio. Se il web server è sotto carico, le email potrebbero partire in ritardo o non partire affatto. Se l’applicazione usa job queue, controlla che i worker siano vivi e che non ci siano crash silenziosi.

Una soglia utile è semplice: se l’invio di notifica è critico, prepara un alert che segnali la mancata consegna dopo un certo numero di retry. L’obiettivo non è solo inviare, ma sapere subito quando l’invio si rompe.

Sicurezza minima consigliata

Un relay affidabile deve essere usato con credenziali dedicate e privilegi minimi. Non riutilizzare account amministrativi, non condividere password tra ambienti e ruota periodicamente le credenziali. Se il provider supporta token o password applicative, preferiscili alle credenziali principali.

Proteggi i file di configurazione con permessi stretti e conserva i segreti fuori dal repository. Se usi un sistema di deploy, inserisci il segreto nel vault o nelle variabili protette. Se il server è multiutente, limita l’accesso ai file SMTP solo all’account che esegue il servizio.

Completa con backup della configurazione e logging adeguato. Se qualcosa smette di funzionare dopo una modifica, devi poter tornare indietro velocemente. La sicurezza utile è quella che non ti blocca il supporto operativo.

Strategia di rollback

Ogni configurazione relay dovrebbe avere un rollback chiaro. Conserva la configurazione precedente, il file delle credenziali e la data della modifica. Se il relay nuovo introduce errori, torna alla configurazione precedente e verifica subito la coda mail.

Rollback pratico:

1. ripristina il file di configurazione salvato;
2. rimuovi o correggi la mappa credenziali se necessario;
3. riavvia il servizio mail;
4. esegui un test di invio;
5. controlla i log per confermare il ritorno alla normalità.

Se il problema è nato da un cambio DNS o da una firma DKIM errata, il rollback deve includere anche il ritorno ai record precedenti. Non limitarti a sistemare il server: il recapito dipende dal sistema completo.

Checklist finale

• relay configurato con autenticazione e TLS;
• SPF, DKIM e DMARC allineati al dominio mittente;
• test di invio riuscito verso una casella esterna;
• log controllati per errori SMTP e timeout;
• backup e rollback pronti prima di nuove modifiche.

Se il tuo obiettivo è affidabilità reale, il relay non è solo un indirizzo SMTP: è un punto di controllo su trasporto, reputazione e tracciabilità. Quando è configurato bene, il server smette di “provare a inviare” e inizia a consegnare con metodo.