Configurare notifiche email su VPS senza supporto tecnico: guida pratica per Postfix su Debian e Ubuntu

A maggio 2025 durante un audit su un VPS Hetzner CX21 di un cliente calabrese - studio di commercialisti con gestionale Laravel per fatturazione elettronica e un portale clienti - ho scoperto che il server non inviava email da quattro mesi. Le notifiche di backup fallito, gli alert di spazio disco, gli avvisi di Fail2ban, i report settimanali del gestionale: tutto finiva nella coda Postfix e non usciva. Il titolare non se ne era accorto perché quelle email non le riceveva - e non ricevere email di alert è esattamente il tipo di problema che non noti finché non è troppo tardi. Nel frattempo, il backup giornaliero aveva smesso di funzionare tre settimane prima (errore di autenticazione sulla Storage Box), il disco era al 92%, e Fail2ban aveva bannato l'IP di un collaboratore esterno che aveva sbagliato la password SSH tre volte.

La causa era semplice e comune: l'indirizzo IP del VPS era finito in due blacklist RBL (Realtime Blackhole List) - Spamhaus ZEN e Barracuda BRBL - perché un vecchio script PHP lasciato da un freelance precedente inviava email transazionali senza autenticazione attraverso Postfix direttamente dalla porta 25. L'IP era stato segnalato come fonte di spam, e da quel momento tutte le email - incluse quelle di sistema - venivano rifiutate dai server destinatari. In questo articolo ti racconto come ho risolto il problema e come configuro Postfix su ogni VPS per garantire che le notifiche di sistema arrivino sempre, anche quando l'IP del server è sconosciuto o ha una reputazione compromessa.

Stai cercando un Consulente Informatico esperto per configurare le notifiche del tuo VPS in modo affidabile? Nel mio profilo professionale trovi l'esperienza concreta su Postfix, deliverability e infrastruttura email per PMI. Contattami per una consulenza diretta.

Perché le email dal VPS finiscono in spam o non arrivano affatto?

Quando Postfix su un VPS invia email direttamente - senza relay SMTP esterno - il server destinatario (Gmail, Outlook, PEC) valuta la reputazione dell'IP mittente. Un IP di un VPS cloud appena provisioned ha reputazione zero - non è in blacklist, ma non è nemmeno riconosciuto come mittente legittimo. Senza record SPF, senza firma DKIM e senza policy DMARC, la maggior parte dei provider classifica quelle email come spam o le rifiuta silenziosamente.

Il problema è amplificato dal fatto che gli IP dei VPS cloud - Hetzner, Digital Ocean, OVH, Contabo - appartengono a range noti ai provider email come "hosting/cloud", e ricevono un trattamento di default più restrittivo rispetto agli IP dedicati con reputazione costruita nel tempo. Gmail nel 2025 richiede esplicitamente che i mittenti autentichino le email con SPF e DKIM, e che abbiano una policy DMARC pubblicata - senza queste tre configurazioni, le email da un VPS non raggiungono nemmeno la cartella spam di Gmail, vengono rifiutate a livello SMTP.

La soluzione che uso su ogni VPS è un relay SMTP attraverso un servizio transazionale - SendGrid, Amazon SES, Mailgun o Brevo. Il VPS non invia email direttamente: le passa al servizio esterno che ha IP con reputazione elevata, firma DKIM integrata e infrastruttura ottimizzata per la deliverability. Il costo è zero o trascurabile per volumi di notifiche di sistema (SendGrid offre 100 email/giorno gratuite, SES costa circa 0.10$ per 1000 email).

La configurazione operativa: Postfix come relay SMTP

L'installazione di Postfix su Debian 12 come relay locale - ascolta solo su localhost, inoltra tutto attraverso un servizio SMTP esterno - è la configurazione che installo su ogni VPS:

# Installare Postfix e mailutils
apt install -y postfix mailutils

# Durante l'installazione, selezionare "Internet Site"
# e impostare il nome di sistema come hostname del server

La configurazione chiave è in /etc/postfix/main.cf:

# /etc/postfix/main.cf - configurazione relay SMTP
myhostname = srv01.esempio.it
mydomain = esempio.it
myorigin = $mydomain
inet_interfaces = loopback-only
mydestination = $myhostname, localhost.$mydomain, localhost

# Relay SMTP esterno (esempio: SendGrid)
relayhost = [smtp.sendgrid.net]: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

# Limiti e sicurezza
message_size_limit = 10240000
header_size_limit = 4096000
smtpd_relay_restrictions = permit_mynetworks, reject_unauth_destination

Le credenziali del relay:

# Creare il file con le credenziali SMTP
echo "[smtp.sendgrid.net]:587 apikey:SG.XXXXXXXXXXXXXXXX" > /etc/postfix/sasl_passwd

# Proteggere il file e generare la mappa hash
chmod 600 /etc/postfix/sasl_passwd
postmap /etc/postfix/sasl_passwd

# Riavviare Postfix
systemctl restart postfix

# Test immediato
echo "Test notifiche VPS $(hostname) $(date)" | mail -s "Test Postfix relay" [email protected]

Dopo il test, verificare nel log che l'email sia stata accettata dal relay:

tail -5 /var/log/mail.log
# Output atteso: status=sent (250 Ok: queued as ...)

Il inet_interfaces = loopback-only è fondamentale: Postfix ascolta solo su 127.0.0.1, quindi non è raggiungibile dall'esterno. Nessun rischio di open relay, nessuna porta 25 esposta, nessun punto di attacco. Le email possono essere inviate solo da processi locali sul server - cron job, script di backup, applicazioni PHP.

SPF, DKIM e DMARC: i tre pilastri della deliverability

Anche con un relay SMTP esterno, è necessario configurare i record DNS del dominio per autenticare le email. I tre record - SPF, DKIM e DMARC - lavorano insieme per dimostrare ai server destinatari che le email sono legittime:

SPF (Sender Policy Framework) specifica quali server sono autorizzati a inviare email per conto del tuo dominio:

# Record TXT DNS per il dominio esempio.it
v=spf1 include:sendgrid.net ~all

DKIM (DomainKeys Identified Mail) firma crittograficamente ogni email - quando usi un relay come SendGrid, il servizio firma le email automaticamente con la sua chiave DKIM. Devi solo pubblicare il record CNAME nel DNS come indicato dal provider.

DMARC (Domain-based Message Authentication, Reporting and Conformance) specifica cosa fare con le email che falliscono SPF/DKIM:

# Record TXT DNS: _dmarc.esempio.it
v=DMARC1; p=none; rua=mailto:[email protected]; pct=100

Il p=none iniziale è una fase di monitoraggio: i server destinatari inviano report aggregati all'indirizzo rua senza rifiutare email. Dopo 2-4 settimane di report puliti, puoi alzare a p=quarantine e poi a p=reject.

Cosa fare se l'IP del VPS è già in blacklist

Nel caso calabrese, l'IP era in blacklist e il relay SMTP ha risolto il problema perché le email escono dall'IP del relay (SendGrid), non dal VPS. Ma se devi anche inviare email direttamente dal VPS - per esempio per la PEC o per server SMTP aziendali - devi rimuovere l'IP dalla blacklist.

Il primo passo è verificare su quali blacklist sei finito. Lo strumento più completo è MXToolbox - inserisci l'IP del VPS e ti mostra in quali RBL è elencato:

# Verificare da terminale (query DNS diretta su Spamhaus)
# Invertire l'IP: 1.2.3.4 → 4.3.2.1
dig +short 4.3.2.1.zen.spamhaus.org
# Se restituisce un IP (127.0.0.x), sei in blacklist
# Se non restituisce nulla, sei pulito

Ogni blacklist ha una procedura di delisting diversa. Spamhaus richiede la compilazione di un form su spamhaus.org/lookup con l'IP e una descrizione delle azioni correttive intraprese. Barracuda richiede registrazione su barracudacentral.org. La maggior parte delle RBL rimuove l'IP entro 24-48 ore se il problema è stato risolto. Ma se il VPS continua a inviare email non autenticate o spam, l'IP viene reinserito immediatamente.

Il consiglio che do ai clienti è: non perdere tempo con il delisting se non hai prima risolto la causa. Identifica lo script o il servizio che ha generato le email incriminate, disabilitalo, configura il relay SMTP per tutto il traffico email legittimo, e solo poi chiedi il delisting. Altrimenti è un ciclo infinito.

Troubleshooting: quando le email non arrivano nonostante il relay

Anche con un relay SMTP configurato correttamente, ci sono tre problemi che vedo spesso sui VPS di PMI.

Primo: le credenziali del relay scadono o vengono ruotate. SendGrid e AWS SES ruotano periodicamente le API key o richiedono verifiche del dominio. Se le credenziali in /etc/postfix/sasl_passwd non sono più valide, Postfix accumula email nella coda deferred senza inviarle. Il log mostra status=deferred (SASL authentication failed). La soluzione è aggiornare le credenziali, rigenerare la mappa con postmap, e riavviare Postfix.

Secondo: il file /etc/mailname non corrisponde al dominio SPF. Postfix usa /etc/mailname come dominio di default per il campo From:. Se /etc/mailname contiene l'hostname del VPS (es. srv01.hetzner.com) anziché il dominio del cliente, le email partono con un mittente che non corrisponde al record SPF - e vengono rifiutate. Verifica:

cat /etc/mailname
# Deve contenere il dominio del cliente, es: esempio.it
# Se è sbagliato:
echo "esempio.it" > /etc/mailname
systemctl restart postfix

Terzo: il resolver DNS del VPS non funziona. Postfix ha bisogno di risolvere i record MX dei destinatari (anche quando usa un relay, per alcune verifiche). Se il resolver DNS del VPS è lento o non risponde, le email restano in coda. Verifico sempre:

# Test risoluzione DNS
dig +short MX gmail.com
# Deve restituire i server MX di Gmail in meno di 1 secondo

# Se lento o senza risposta, configurare DNS affidabili
echo "nameserver 1.1.1.1" > /etc/resolv.conf
echo "nameserver 8.8.8.8" >> /etc/resolv.conf

Test di deliverability: verificare che le email arrivino davvero

Dopo la configurazione, il test non è "ho inviato un'email e l'ho ricevuta". Il test corretto verifica che l'email superi tutti i controlli di autenticazione. Invio un'email a un indirizzo Gmail e controllo gli header completi:

# Inviare email di test
echo "Test deliverability $(date)" | mail -s "Test SPF/DKIM/DMARC" [email protected]

Su Gmail, apri l'email > tre puntini > "Mostra originale". Cerca queste righe:

SPF: PASS
DKIM: PASS
DMARC: PASS

Se uno di questi è FAIL, l'email potrebbe arrivare oggi ma finire in spam domani - o essere rifiutata quando Gmail inasprisce le policy. Tutti e tre devono essere PASS per una deliverability affidabile nel tempo.

Il monitoring della coda email: sapere se le notifiche non partono

Il problema del cliente calabrese - email bloccate per quattro mesi - non sarebbe successo con un monitoring della coda Postfix. Lo script che installo:

#!/usr/bin/env bash
# /root/scripts/postfix-queue-check.sh
QUEUE_SIZE=$(mailq | tail -1 | grep -oP '\d+' | head -1)
QUEUE_SIZE=${QUEUE_SIZE:-0}

if [ "$QUEUE_SIZE" -gt 10 ]; then
    # La coda ha più di 10 email in attesa: qualcosa non va
    echo "Postfix queue: ${QUEUE_SIZE} email in coda su $(hostname)" | \
        mail -s "MAIL ALERT: coda Postfix piena" [email protected]
fi

Il paradosso è evidente: se Postfix non funziona, lo script di alert non può inviare l'email di alert. Per questo uso un canale di notifica secondario - un webhook verso Telegram o un healthcheck.io - che non dipende da Postfix:

# Alert via webhook Telegram (non dipende da Postfix)
QUEUE_SIZE=$(mailq 2>/dev/null | tail -1 | grep -oP '\d+' | head -1)
if [ "${QUEUE_SIZE:-0}" -gt 10 ]; then
    curl -s -X POST "https://api.telegram.org/bot${BOT_TOKEN}/sendMessage" \
        -d "chat_id=${CHAT_ID}" \
        -d "text=⚠ Postfix queue: ${QUEUE_SIZE} email bloccate su $(hostname)"
fi

Ho descritto la configurazione urgente dell'SMTP per applicazioni Laravel - inclusa la gestione del driver mail di Laravel e il debugging delle email transazionali - nell'articolo sull'SMTP urgente per VPS Laravel. E il contesto più ampio del monitoring infrastrutturale - di cui le notifiche email sono un componente - nell'articolo sul monitoraggio IT proattivo.

Le notifiche email dal VPS sono il sistema nervoso della tua infrastruttura: quando funzionano, sai in tempo reale se qualcosa va storto. Quando non funzionano, sei cieco - e lo scopri solo quando il danno è già fatto. Se il tuo VPS non invia email da settimane e non lo sai, o se le email finiscono in spam e gli alert critici non arrivano, è un problema che richiede meno di due ore per risolvere e che può evitare settimane di emergenze non rilevate. Contattami e configuriamo un sistema di notifiche che funzioni davvero. La configurazione di Postfix come relay SMTP con SPF/DKIM/DMARC e un canale di alert secondario via Telegram richiede meno di due ore e trasforma il tuo VPS da una scatola nera silenziosa a un'infrastruttura che ti avvisa in tempo reale quando qualcosa va storto - prima che i tuoi clienti se ne accorgano.