SMTP Relay, come configurare Relay di terze parti

Cos’è un relay SMTP di terze parti

Un relay SMTP di terze parti è un servizio esterno che riceve le mail dal tuo server e le recapita ai destinatari finali. Si usa quando vuoi migliorare affidabilità, reputazione IP, deliverability, gestione delle code o quando il provider del server blocca l’uscita sulla porta 25.

In pratica il tuo server non consegna più direttamente alle mailbox remote, ma passa tutto a un provider come SendGrid, Mailgun, Amazon SES, SMTP2GO, Mailjet, Brevo o simili. Il vantaggio principale è avere una piattaforma già pronta per autenticazione, reputazione e monitoraggio. Il rovescio della medaglia è che devi configurare bene autenticazione, TLS, limiti e fallback, altrimenti rischi bounce, code bloccate o invii non autorizzati.

Quando conviene usarlo

• Se il VPS o il server ha la porta 25 bloccata in uscita.
• Se il tuo IP ha cattiva reputazione o è nuovo e fatica a raggiungere Inbox.
• Se invii mail transazionali da WordPress, CRM, ticketing o applicazioni web.
• Se vuoi centralizzare log, statistiche e retry su un provider esterno.
• Se preferisci non gestire direttamente rDNS, reputazione e warm-up IP.

Non è invece la soluzione giusta se vuoi un server completamente indipendente o se hai esigenze particolari di compliance che impongono il controllo totale del flusso. In quel caso il relay può restare un supporto, ma non l’unico canale.

Diagnosi prima della configurazione

Prima di cambiare la configurazione, verifica tre cose: il MTA installato, la porta di uscita e il tipo di autenticazione richiesto dal relay. La maggior parte dei problemi nasce qui, non nel file di configurazione in sé.

• Se usi Postfix, la configurazione del relay è semplice e molto stabile.
• Se usi Exim, il principio è lo stesso ma cambiano i file e la sintassi.
• Se sei su un pannello come cPanel, Plesk o FastPanel, spesso è meglio partire dalla GUI e usare il terminale solo per verifica.

Controlla anche se il provider richiede:

• porta 587 con STARTTLS, oppure 465 con TLS implicito;
• username e password SMTP;
• sender verificato o dominio autenticato;
• limiti di invio per minuto o per giorno.

Scelta del relay: criteri pratici

La scelta non va fatta solo sul prezzo. I punti che contano davvero sono deliverability, supporto TLS, reputazione degli IP, log, webhooks, limitazioni e facilità di integrazione.

• Deliverability: il relay deve avere buona reputazione e supportare SPF, DKIM e DMARC.
• Trasparenza log: devi vedere accettazione, rifiuto e motivi di bounce.
• Autenticazione: meglio SMTP con credenziali dedicate o API key segregate per applicazione.
• Integrazione: utile se devi collegarlo a WordPress, Laravel, Magento, sistemi ticket o newsletter.
• Scalabilità: conta la gestione di volumi medio-alti senza rate limit troppo stretti.

Se il tuo obiettivo è invio transazionale, un relay SMTP con autenticazione classica è spesso la scelta più semplice. Se invece invii grandi volumi, valuta anche API HTTP del provider, ma quella è un’altra architettura.

Configurazione base su Postfix

Postfix è il caso più comune su Linux. La configurazione standard prevede relayhost, autenticazione SASL e TLS verso il provider esterno.

Prima di modificare i file, fai un backup della configurazione.

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

Ora imposta il relay host. Esempio con provider su porta 587:

relayhost = [smtp.provider.tld]:587

Nel file /etc/postfix/main.cf devi anche abilitare l’autenticazione e il TLS. Una base tipica è questa:

relayhost = [smtp.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 = encrypt
smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt

Se il provider richiede la porta 465, il principio resta identico, ma spesso conviene usare un relayhost con TLS implicito e verificare la documentazione del servizio, perché non tutti i relay gestiscono allo stesso modo questa modalità.

File delle credenziali

Crea il file /etc/postfix/sasl_passwd con formato:

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

Proteggi il file e genera la mappa hash:

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

Riavvia Postfix solo dopo il controllo della sintassi:

sudo postfix check
sudo systemctl restart postfix

Esito atteso: nessun errore in output e servizio attivo.

Verifiche immediate

1. Controlla che Postfix sia attivo: systemctl status postfix. Esito atteso: stato active (running).
2. Controlla la configurazione effettiva: postconf -n. Esito atteso: vedi relayhost, smtp_sasl_auth_enable e le opzioni TLS impostate.
3. Verifica che il file delle password sia leggibile solo da root: ls -l /etc/postfix/sasl_passwd*. Esito atteso: permessi restrittivi, senza lettura pubblica.
4. Invia una mail di prova con mail o sendmail. Esito atteso: il messaggio entra in coda e viene accettato dal relay.

Esempio di test minimale:

printf "Subject: test relay\n\nprova relay smtp" | sendmail -v destinatario@example.com

Nel log di Postfix cerca una riga che confermi autenticazione e inoltro verso il relay, non un tentativo diretto verso il dominio finale.

Configurazione su Exim

Su alcuni server, soprattutto in ambienti con pannelli hosting tradizionali, il MTA è Exim. Il concetto è uguale: definisci un router che invii tutto al relay esterno e una transport con autenticazione.

Qui è più facile sbagliare se il pannello gestisce Exim automaticamente. Prima di toccare i file, verifica se il provider del pannello offre una sezione dedicata ai relay SMTP. Quando esiste, è preferibile usarla rispetto alla modifica manuale, perché riduce il rischio di sovrascrittura agli aggiornamenti.

Se devi intervenire a mano, identifica almeno questi elementi:

• host e porta del relay;
• credenziali SMTP;
• obbligo di TLS;
• eventuali domini autorizzati a spedire.

Il principio operativo resta sempre lo stesso: autenticazione, cifratura, test e controllo dei log.

Configurazione da cPanel, Plesk e FastPanel

Se hai un pannello, parti dalla GUI. È la via più sicura quando il sistema modifica in automatico la configurazione del mail server.

cPanel

In cPanel cerca la sezione legata al mail routing o alla configurazione del server di posta. Se il tuo hosting usa Exim, spesso il relay viene impostato lato amministrazione WHM o tramite plugin specifici. Dopo la modifica, fai un test di invio dal dominio interessato e controlla /var/log/exim_mainlog o i log accessibili dal pannello.

Plesk

In Plesk il percorso tipico è Tools & Settings o le impostazioni di Mail Server. Se il relay è previsto dal provider, puoi inserire host, porta, autenticazione e TLS direttamente nell’interfaccia. Dopo il salvataggio, prova un invio e verifica i log mail di Plesk, che sono molto utili per capire se il problema è di autenticazione o di rete.

FastPanel

In FastPanel la logica è simile: cerca le impostazioni del mail server o del dominio e controlla se esiste un campo per SMTP relay esterno. Quando il pannello non espone il relay in modo nativo, conviene installare e configurare il MTA sotto controllo manuale solo se sai esattamente come il pannello gestisce i servizi.

Autenticazione, SPF, DKIM e DMARC

Il relay SMTP non sostituisce l’autenticazione del dominio. Anzi, la rende più importante. Se invii mail con un provider terzo ma il dominio non è allineato, molte caselle finiranno in spam o verranno rifiutate.

• SPF: autorizza il relay a spedire per il tuo dominio.
• DKIM: firma i messaggi con una chiave del tuo dominio o del provider.
• DMARC: definisce la policy e richiede allineamento tra From, SPF e DKIM.

Se il relay firma con DKIM proprio, controlla che il dominio mittente sia supportato e che il record DNS sia stato pubblicato correttamente. Se invece devi firmare tu dal server, verifica che la chiave privata sia protetta e che il processo di firma sia coerente con il flusso del relay.

Un errore frequente è impostare il relay correttamente ma lasciare SPF incompleto. In quel caso il server invia davvero, ma i destinatari classificano male il messaggio perché il dominio non è autorizzato a spedire da quel percorso.

Problemi tipici e come riconoscerli

• Authentication failed: username o password errati, oppure il provider richiede un formato diverso.
• Relay access denied: il relay non accetta il mittente o il dominio non è autorizzato.
• Connection timed out: porta bloccata in uscita, firewall, routing o provider non raggiungibile.
• SSL/TLS error: CA mancante, SNI non supportato o porta sbagliata.
• Mail in coda: il relay accetta a tratti, ma il server non riesce a completare la consegna.

Per leggere i log in modo efficace, cerca sempre tre elementi: destinatario, stato SMTP e codice di errore. Il codice è più utile del messaggio generico, perché ti dice se il problema è autenticazione, trasporto o policy del relay.

Comandi utili di verifica

Questi controlli aiutano a capire rapidamente se il problema è locale o esterno.

postconf -n

Esito atteso: mostra solo le opzioni effettivamente attive.

systemctl status postfix

Esito atteso: servizio attivo e senza restart continui.

tail -f /var/log/maillog

Esito atteso: vedi il tentativo di invio e l’esito del relay.

openssl s_client -starttls smtp -connect smtp.provider.tld:587 -crlf

Esito atteso: handshake TLS valido e certificato presentato dal relay.

Se il provider usa la 465, il test cambia e va eseguito con connessione TLS implicita. Se il test fallisce già qui, il problema non è Postfix ma rete, DNS o porta bloccata.

Hardening minimo consigliato

Un relay SMTP va trattato come una credenziale sensibile. Non lasciare password in file leggibili da utenti non privilegiati, non riutilizzare account tra più sistemi e ruota le credenziali quando sospetti esposizione.

• Usa un account SMTP dedicato per ogni progetto o server.
• Limita i permessi dei file di configurazione.
• Abilita TLS obbligatorio verso il relay.
• Monitora code, bounce e rifiuti SMTP.
• Tieni aggiornato il MTA e il sistema operativo.

Se il server invia mail critiche, aggiungi alert su coda mail, saturazione disco e errori di autenticazione ripetuti. Una coda piena o un relay non raggiungibile possono trasformarsi in un incidente operativo nel giro di pochi minuti.

Fallback e piano di rollback

Se la nuova configurazione non funziona, il rollback deve essere immediato. Prima di cambiare file, conserva sempre una copia della configurazione precedente. Se il relay terzo va giù, puoi temporaneamente tornare a una consegna diretta solo se il tuo IP ha reputazione adeguata e la porta 25 è disponibile.

Per Postfix, il rollback tipico consiste nel ripristinare main.cf e il file sasl_passwd salvati prima della modifica, rigenerare eventuali mappe e riavviare il servizio. Dopo il rollback, ripeti un invio di test e verifica che il flusso sia tornato stabile.

Checklist finale

1. Relay host, porta e autenticazione sono corretti.
2. Il TLS verso il provider è attivo e verificato.
3. SPF, DKIM e DMARC sono coerenti con il dominio mittente.
4. I log mostrano accettazione dal relay, non errori di autenticazione.
5. Esiste un backup della configurazione e un rollback pronto.

In un ambiente Linux ben gestito, il relay SMTP di terze parti non è solo una scorciatoia per “far partire le mail”: è un componente da trattare come infrastruttura critica, con test, log e manutenzione esattamente come un web server o un database.