Email deliverability su server Linux: SPF, DKIM, DMARC e troubleshooting vero

Quando un cliente dice “le email arrivano in spam”, quasi sempre parte la caccia al colpevole sbagliato. Si guarda il contenuto del messaggio, si cambia un subject, si ritenta. Ma la deliverability è infrastruttura prima ancora che copy.

Questo playbook serve a controllare l'ordine giusto: identità del dominio, autenticazione, reputazione tecnica e comportamento del server.

Se stai migrando provider e vuoi evitare di rompere anche la posta, leggi anche Migrazione zero-downtime: runbook per web agency. Se hai un problema urgente su un nodo già in produzione, c'è SOS. Per gestione continuativa del nodo, invece, guarda Server Management.

TL;DR

Prima controlla questi 7 punti:

1. record A e MX coerenti
2. reverse DNS corretto
3. SPF valido
4. DKIM firmato davvero
5. DMARC presente
6. hostname e banner SMTP coerenti
7. IP non già compromesso di reputazione

Se ne manca uno, stai già partendo male.

Step 1: capisci da dove parte la mail

Non tutte le email “del sito” partono dallo stesso posto.

Possibili origini:

• Postfix locale sul server web
• relay SMTP esterno
• provider transactional tipo Mailgun o SES
• pannello hosting
• plugin WordPress con configurazione custom

Prima di tutto devi sapere chi sta inviando davvero.

postconf -n
hostname -f

E lato applicazione verifica:

• plugin SMTP attivo
• credenziali relay
• envelope sender
• from header reale

Step 2: DNS base

Controlli minimi:

dig +short A mail.dominio.it
dig +short MX dominio.it
dig +short TXT dominio.it
dig +short TXT _dmarc.dominio.it

Domande pratiche:

• il dominio ha un MX valido?
• il server che invia ha nome coerente?
• esiste un sottodominio mail. o equivalente?
• SPF e DMARC sono pubblicati davvero?

Step 3: reverse DNS

Il reverse DNS è uno dei controlli più banali e più dimenticati.

dig -x IP_SERVER +short

Cosa vuoi vedere:

• un PTR valorizzato
• idealmente coerente con hostname e HELO/EHLO

Se il reverse punta a un valore generico del provider o non esiste, molte mail partiranno già sospette.

Step 4: SPF corretto, non mostruoso

Esempio semplice:

v=spf1 a mx ip4:203.0.113.10 include:relay.esempio.net -all

Cose da evitare:

• troppi include
• record duplicati
• record multipli SPF sullo stesso dominio
• ~all lasciato per sempre in produzione senza sapere perché

Controlla anche il limite di lookup DNS complessivi. SPF troppo complesso rompe la validazione.

Step 5: DKIM che firma davvero

Avere il record DNS non basta. Devi verificare che i messaggi siano firmati.

Con OpenDKIM, controlli base:

systemctl status opendkim
opendkim-testkey -d dominio.it -s default -vvv

Poi guarda un messaggio ricevuto e verifica gli header:

• DKIM-Signature
• Authentication-Results

Se il DNS è giusto ma la mail non viene firmata, il problema è nel percorso di invio o nell'integrazione con MTA.

Step 6: DMARC minimo subito

Record minimo sensato:

v=DMARC1; p=none; rua=mailto:[email protected]; adkim=s; aspf=s

Per iniziare va bene p=none, ma non deve restare lì per sempre se stai cercando controllo serio.

Percorso tipico:

• p=none per osservare
• p=quarantine quando SPF e DKIM sono stabili
• p=reject quando hai certezza del flusso

Step 7: hostname, banner e coerenza SMTP

Controlla che il server si presenti in modo sensato.

postconf myhostname
postconf smtp_helo_name
openssl s_client -connect mail.dominio.it:25 -starttls smtp

Cose da evitare:

• hostname locali tipo srv1.localdomain
• HELO non coerente col reverse
• certificati TLS sbagliati o scaduti

Step 8: reputazione IP

A volte la configurazione è corretta ma l'IP è già sporco.

Controlla:

• blacklist note
• storico del provider
• eventuale riuso dell'IP
• volumi di invio anomali

Segnali brutti:

• IP nuovo ma con cattiva reputazione
• server compromesso che invia spam in uscita
• code mail gonfie o bounce strani

mailq
postqueue -p
grep -i "status=bounced" /var/log/mail.log | tail -20

Step 9: il contenuto conta, ma dopo l'infrastruttura

Una volta sistemata la parte tecnica, allora guardi:

• subject aggressivi
• link shortening strani
• allegati pesanti
• volume improvviso troppo alto
• from incoerente con dominio o reply-to

Ma se SPF, DKIM e reverse sono rotti, il copy non ti salverà.

Errori frequenti

1. WordPress che invia via mail() locale senza controllo

Comodo all'inizio, fragile in produzione.

2. SPF con troppi include

Sembra completo, in realtà è ingestibile.

3. DKIM pubblicato ma mai testato

Errore molto comune.

4. DMARC assente

Nessuna governance del dominio.

5. Reverse DNS dimenticato

Classico nei VPS nuovi.

Procedura pratica di troubleshooting

# 1. DNS
dig +short MX dominio.it
dig +short TXT dominio.it
dig +short TXT _dmarc.dominio.it
dig -x IP_SERVER +short

# 2. servizio mail
systemctl status postfix
systemctl status opendkim

# 3. coda e log
mailq
postqueue -p
tail -100 /var/log/mail.log

Poi manda un messaggio verso:

• Gmail
• Outlook
• una casella del dominio stesso

E leggi gli header, non solo la cartella finale.

Quando questa guida non basta

Questa guida basta per la maggior parte dei server Linux che inviano mail transazionali o operative. Non basta se:

• hai volumi marketing o newsletter
• stai uscendo da blacklist importanti
• hai più relay e più domini in gioco
• il server è stato compromesso e ha inviato spam
• la deliverability è solo un sintomo di una configurazione mail completamente disordinata

In questi casi serve un assessment tecnico più ampio. Parti da audit gratuito o da Server Management.

Checklist finale

• MX verificato
• PTR presente
• SPF valido
• DKIM firmato
• DMARC pubblicato
• hostname coerente
• reputazione IP controllata
• log e coda puliti

La deliverability non è fortuna. È coerenza tecnica. Quando il dominio, il server e i record raccontano la stessa storia, la posta smette di sembrare casuale.