Quando le email iniziano a finire nello spam
Qualche giorno fa mi sono trovato a gestire un problema abbastanza classico su un applicativo web di un cliente: le email partivano regolarmente dal sistema, il server non restituiva errori evidenti, ma alcuni messaggi non arrivavano a destinazione oppure finivano direttamente nella cartella spam.
Il primo istinto, quando succede, è controllare il codice dell'applicativo. Magari una funzione PHP che invia male le email, un problema con SMTP o qualche header mancante.
In realtà, non sempre il problema è nell'applicazione.
La deliverability delle email dipende da diversi fattori: reputazione dell'indirizzo IP, configurazione DNS, autenticazione del dominio, presenza nelle blacklist e contenuto del messaggio.
In questa guida vediamo come affrontare il problema con un approccio pratico, partendo dai controlli più semplici fino alla verifica finale con Mail-Tester.
L'obiettivo è capire:
- Se il server di invio è presente in una blacklist
- Come individuare la causa di un eventuale blocco
- Come richiedere la rimozione da una blacklist
- Come configurare correttamente SPF, DKIM e DMARC
- Come verificare che i record DNS siano effettivamente propagati
- Come testare il risultato con Mail-Tester
1. Prima diagnosi: controllare se l'IP è in blacklist
Quando un server invia email che finiscono nello spam, una delle prime verifiche da fare è controllare la reputazione dell'indirizzo IP pubblico utilizzato per l'invio.
Esistono diversi servizi che permettono di verificare se un IP è presente nelle principali blacklist utilizzate dai sistemi antispam.
Quelli che utilizzo più spesso sono:
Il procedimento è semplice:
- Recupera l'indirizzo IP pubblico del server che invia le email.
- Inseriscilo nei servizi di verifica.
- Controlla quali blacklist restituiscono un risultato positivo.
- Annota il nome della blacklist e il motivo dell'inserimento, se disponibile.
Per recuperare l'IP pubblico direttamente dal server Linux puoi utilizzare:
curl -4 https://icanhazip.com
Attenzione: se l'applicativo invia tramite un provider SMTP esterno, l'IP da controllare potrebbe non essere quello del server web. Devi verificare l'IP effettivo utilizzato dal servizio che consegna i messaggi.
Cosa significa essere in blacklist?
Una blacklist è un elenco di indirizzi IP o domini che vengono considerati potenzialmente responsabili dell'invio di spam.
I provider di posta elettronica possono consultare queste liste per decidere se accettare, rifiutare o penalizzare un messaggio.
Non tutte le blacklist hanno lo stesso peso. Alcune vengono utilizzate da molti sistemi di posta, altre hanno una diffusione più limitata.
Per questo motivo non basta trovare un risultato rosso su un qualsiasi servizio di controllo: bisogna capire quale lista ha segnalato l'indirizzo e quanto è rilevante per i destinatari coinvolti.
2. Prima di chiedere il delisting, bisogna trovare la causa
Essere rimossi da una blacklist senza aver risolto il problema che ha causato l'inserimento serve a poco.
Il rischio è ritrovarsi nuovamente nella stessa situazione dopo poche ore o pochi giorni.
Le cause più frequenti sono:
- Un applicativo compromesso che invia email in modo anomalo
- Un account SMTP con credenziali rubate
- Un volume di invio improvvisamente elevato
- Invio di messaggi a indirizzi inesistenti o non più validi
- Configurazione errata del server di posta
- Reputazione negativa dell'indirizzo IP
- Mancanza di autenticazione SPF, DKIM o DMARC
Se utilizzi Postfix, puoi iniziare analizzando i log del servizio.
Su Debian e Ubuntu:
tail -f /var/log/mail.log
Per cercare eventuali errori:
grep -iE "reject|deferred|bounced|warning|error" /var/log/mail.log
Per controllare la coda delle email:
postqueue -p
Se trovi centinaia o migliaia di messaggi in coda, è opportuno capire da dove arrivano prima di continuare a inviare.
Puoi anche verificare se ci sono connessioni SMTP anomale o processi che stanno generando un volume di traffico insolito.
Il principio è semplice: prima si risolve la causa, poi si richiede la rimozione dalla blacklist.
3. Come richiedere la rimozione da una blacklist
Una volta individuata e risolta la causa, puoi procedere con la richiesta di delisting.
Ogni blacklist ha una propria procedura. Non esiste un modulo universale da compilare per tutte.
Per esempio, Spamhaus mette a disposizione un servizio di controllo e gestione delle segnalazioni:
Dopo aver inserito l'indirizzo IP, il servizio mostra l'eventuale presenza nelle proprie liste e, quando previsto, le informazioni necessarie per procedere.
Una distinzione importante riguarda le liste Spamhaus SBL: in questo caso la gestione della rimozione coinvolge normalmente il provider che controlla l'indirizzo IP, quindi il proprietario del server potrebbe dover contattare il proprio hosting provider.
Cosa scrivere in una richiesta di delisting
Quando è possibile inviare una richiesta, evita messaggi generici come:
"Il nostro IP è stato inserito in blacklist, potete rimuoverlo?"
È molto meglio spiegare cosa è successo e quali interventi sono stati effettuati.
Un esempio:
Subject: Delisting request - [IP ADDRESS]
Hello,
We have identified that our mail server IP
[IP ADDRESS] is currently listed.
We investigated the issue and identified
the source of the abnormal email traffic.
The issue has been resolved:
- Compromised credentials have been changed.
- Unnecessary mail processes have been stopped.
- SMTP authentication has been reviewed.
- SPF, DKIM and DMARC records have been configured.
- Mail server logs are now monitored.
We have also reviewed our sending practices
to prevent similar issues in the future.
Could you please review the listing
and let us know if the IP can be removed?
Thank you.
Naturalmente, inserisci solamente gli interventi che hai realmente effettuato.
Non tutte le blacklist prevedono una richiesta manuale e non tutte garantiscono la rimozione immediata. In alcuni casi bisogna attendere la scadenza della segnalazione o coinvolgere il provider.
4. SPF, DKIM e DMARC: l'autenticazione delle email
Questo è probabilmente il passaggio più importante di tutta la procedura.
Un server può essere perfettamente funzionante, avere un IP non presente nelle blacklist e riuscire a consegnare le email, ma avere comunque problemi di deliverability se il dominio non è configurato correttamente.
I tre meccanismi principali da conoscere sono SPF, DKIM e DMARC.
Non sono alternative tra loro: hanno funzioni differenti e lavorano insieme.
SPF: autorizzare i server che possono inviare email
SPF (Sender Policy Framework) è un sistema che permette al proprietario di un dominio di dichiarare quali server sono autorizzati a inviare email utilizzando quel dominio.
La configurazione avviene tramite un record TXT nel DNS.
Un esempio semplificato:
example.com. TXT "v=spf1 ip4:203.0.113.10 -all"
In questo caso:
v=spf1identifica la versione SPFip4:203.0.113.10autorizza l'indirizzo IP indicato-allindica che gli altri server non sono autorizzati
Se utilizzi anche un provider SMTP esterno, dovrai autorizzarlo attraverso la configurazione SPF indicata dal provider.
Per esempio, alcuni servizi richiedono un meccanismo include, ma il valore corretto deve essere quello fornito dal servizio che utilizzi.
Attenzione: un dominio deve avere un solo record SPF. Se hai più servizi che inviano email, devi consolidare le autorizzazioni in un unico record TXT.
Inoltre SPF prevede un limite di 10 lookup DNS durante la valutazione. Una configurazione troppo articolata può quindi causare errori di verifica.
DKIM: firmare digitalmente le email
DKIM (DomainKeys Identified Mail) aggiunge una firma crittografica alle email in uscita.
Il server destinatario può utilizzare questa firma per verificare che il messaggio sia stato autorizzato dal dominio e che alcune parti del contenuto non siano state modificate durante il transito.
Il sistema utilizza una coppia di chiavi:
- Una chiave privata, conservata sul server o sul servizio di invio
- Una chiave pubblica, pubblicata nel DNS
Un record DKIM ha generalmente una struttura simile:
selector1._domainkey.example.com. TXT "v=DKIM1; k=rsa; p=PUBLIC_KEY"
Il valore selector1 è il selettore DKIM e deve corrispondere a quello utilizzato dal sistema che invia le email.
La chiave pubblica non va inventata o generata copiando un esempio: deve essere quella effettivamente associata alla chiave privata utilizzata dal server.
Se utilizzi Postfix con OpenDKIM, la configurazione prevede la generazione delle chiavi, la pubblicazione della chiave pubblica nel DNS e il collegamento tra Postfix e il servizio di firma.
Un messaggio firmato correttamente con DKIM permette al destinatario di verificare l'autenticità della firma attraverso il record DNS.
DMARC: definire cosa fare quando SPF o DKIM falliscono
DMARC (Domain-based Message Authentication, Reporting and Conformance) aggiunge un livello di controllo sopra SPF e DKIM.
Permette al proprietario del dominio di comunicare ai server destinatari come gestire i messaggi che non superano i controlli di autenticazione e di ricevere report sulle verifiche effettuate.
Un record DMARC di partenza può essere:
_dmarc.example.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
Vediamo i parametri:
v=DMARC1: identifica la versione del protocollop=none: monitora senza richiedere un'azione specifica sui messaggirua: indica l'indirizzo che riceve i report aggregati
Le principali policy sono:
| Policy | Comportamento |
|---|---|
none |
Monitoraggio, senza richiedere interventi sui messaggi |
quarantine |
Richiesta di trattare i messaggi non conformi come sospetti |
reject |
Richiesta di rifiutare i messaggi non conformi |
Il mio consiglio è partire da p=none, analizzare i report e verificare che tutti i sistemi legittimi che inviano email siano correttamente autenticati.
Solo dopo aver verificato la situazione ha senso valutare il passaggio a quarantine o reject.
Il concetto fondamentale: l'allineamento
Un dettaglio spesso trascurato è il cosiddetto alignment.
Non basta che SPF e DKIM restituiscano un risultato positivo: per superare DMARC, almeno uno dei due meccanismi deve essere autenticato e allineato con il dominio presente nell'indirizzo From visibile al destinatario.
In pratica:
- SPF deve superare il controllo e utilizzare un dominio allineato
- Oppure DKIM deve superare il controllo e utilizzare un dominio di firma allineato
È questo il motivo per cui configurare correttamente SPF, DKIM e DMARC richiede di considerare anche il provider SMTP e il dominio effettivamente utilizzato nell'invio.
5. Verificare che i record DNS siano corretti
Dopo aver configurato SPF, DKIM e DMARC, non bisogna dare per scontato che tutto funzioni.
Prima di passare al test delle email, conviene verificare che i record siano effettivamente pubblicati e visibili.
Su Linux puoi utilizzare dig.
Per SPF:
dig TXT example.com
Per DKIM:
dig TXT selector1._domainkey.example.com
Per DMARC:
dig TXT _dmarc.example.com
Puoi anche interrogare direttamente alcuni resolver pubblici:
dig @8.8.8.8 TXT example.com
dig @1.1.1.1 TXT example.com
Se i record non vengono restituiti correttamente, controlla:
- Il nome del record
- Il tipo di record DNS
- Il valore pubblicato
- Eventuali errori di sintassi
- Il TTL e i tempi di propagazione
Un errore molto comune è pubblicare il record DKIM sul nome sbagliato, dimenticando il selettore effettivamente utilizzato dal server.
Un altro errore frequente è creare più record SPF anziché aggiornare quello già esistente.
Ricorda che la propagazione DNS non è sempre immediata. Dopo una modifica potrebbe essere necessario attendere prima che tutti i resolver vedano il nuovo valore.
6. Mail-Tester: il controllo finale che non dovrebbe mai mancare
Una volta sistemate le blacklist e configurati i record DNS, arriva il momento di verificare il risultato.
Lo strumento che utilizzo per questo controllo è Mail-Tester.
È uno strumento molto pratico perché non si limita a controllare i record DNS del dominio: analizza una vera email inviata dal tuo sistema.
Il funzionamento è semplice:
- Apri mail-tester.com.
- Il servizio genera un indirizzo email temporaneo.
- Copia l'indirizzo generato.
- Invia un messaggio dal tuo applicativo o dal server che vuoi verificare.
- Torna su Mail-Tester e avvia l'analisi.
Il risultato mostra diversi aspetti importanti:
- Autenticazione SPF
- Firma DKIM
- Configurazione DMARC
- Reputazione e blacklist dell'IP
- Header del messaggio
- Configurazione del server di posta
- Eventuali problemi nel contenuto dell'email
La cosa importante è inviare il messaggio dal sistema reale che presenta il problema.
Se l'applicativo utilizza un server SMTP esterno, il test deve passare attraverso quello stesso server.
Se invece invii direttamente da Postfix, devi effettuare il test usando il percorso di invio effettivo.
Fare il test inviando una semplice email da Gmail non serve a verificare la configurazione del tuo server.
Come interpretare il punteggio
Mail-Tester assegna un punteggio al messaggio analizzato.
Un risultato vicino a 10/10 è generalmente un buon segnale, ma non significa che tutte le email arriveranno sicuramente nella posta in arrivo.
Il punteggio è una fotografia di diversi controlli effettuati sul messaggio e sull'infrastruttura di invio.
Se ottieni un risultato basso, non fermarti al numero: apri le singole verifiche e analizza i problemi segnalati.
Il mio approccio è questo:
- Controllo prima SPF, DKIM e DMARC.
- Verifico eventuali segnalazioni relative all'IP.
- Controllo gli header e la configurazione del server.
- Correggo gli eventuali problemi.
- Ripeto il test dopo le modifiche.
È importante ricordare che Mail-Tester non certifica la consegna nella inbox di ogni provider. Gmail, Outlook, Yahoo e gli altri servizi applicano anche sistemi proprietari di reputazione e filtraggio.
7. Reverse DNS, hostname e HELO: non dimenticarli
C'è un altro controllo che vale la pena effettuare quando si gestisce un mail server dedicato: la configurazione del reverse DNS.
Il reverse DNS, o record PTR, permette di associare un indirizzo IP a un hostname.
Per verificare il PTR di un IP:
dig -x 203.0.113.10
Idealmente, l'indirizzo IP utilizzato per inviare le email dovrebbe avere un record PTR coerente con il nome host del server.
Per esempio:
203.0.113.10 -> mail.example.com
Anche il server SMTP dovrebbe presentarsi con un hostname coerente durante la connessione.
Con Postfix puoi verificare la configurazione del nome host annunciato:
postconf myhostname
Un esempio:
myhostname = mail.example.com
La coerenza tra IP, reverse DNS, hostname e identificazione SMTP contribuisce a rendere l'infrastruttura più credibile e correttamente configurata.
Attenzione: il record PTR è normalmente gestito dal provider che assegna l'indirizzo IP, quindi potrebbe essere necessario modificarlo dal pannello di controllo dell'hosting oppure aprire un ticket di assistenza.
8. Checklist completa per diagnosticare problemi di deliverability
Quando un cliente mi segnala che le email finiscono nello spam, preferisco seguire una procedura ordinata invece di modificare configurazioni a caso.
Questa è la checklist che puoi utilizzare anche sui tuoi server.
Blacklist e reputazione
- Ho identificato l'IP realmente utilizzato per l'invio?
- Ho verificato l'IP con MXToolbox?
- Ho controllato Spamhaus?
- Ho verificato eventuali altre blacklist?
- Ho individuato la causa dell'inserimento?
- Ho controllato i log del server?
- Ho verificato che non ci siano invii anomali?
- Ho richiesto il delisting, se necessario?
Autenticazione DNS
- Il dominio ha un solo record SPF?
- Il record SPF autorizza tutti i sistemi legittimi?
- Il dominio utilizza DKIM?
- La chiave pubblica DKIM è pubblicata sul selettore corretto?
- Il record DMARC è presente?
- Il dominio SPF o DKIM è allineato con il dominio del mittente?
- I record DNS sono visibili attraverso resolver pubblici?
Configurazione del server
- Il server ha un hostname corretto?
- Il record PTR è configurato?
- Il server SMTP utilizza un HELO/EHLO coerente?
- Non ci sono messaggi anomali nella coda Postfix?
- Le credenziali SMTP sono protette?
- I log vengono monitorati?
Test finale
- Ho inviato un messaggio reale tramite l'applicativo?
- Ho eseguito un test con Mail-Tester?
- Ho verificato ogni singola segnalazione?
- Ho ripetuto il test dopo le modifiche?
- Ho verificato la consegna anche verso i principali provider?
Conclusione
Quando le email finiscono nello spam, non bisogna concentrarsi esclusivamente sul codice che le genera.
La prima cosa da fare è capire dove si trova realmente il problema: reputazione dell'IP, blacklist, configurazione DNS, autenticazione o server SMTP.
SPF, DKIM e DMARC non sono più configurazioni da considerare facoltative quando si gestisce un'infrastruttura che invia email. Sono elementi fondamentali per dimostrare ai server destinatari che i messaggi provengono da sistemi autorizzati.
Il controllo con Mail-Tester è poi un passaggio molto utile per verificare il risultato concreto delle modifiche.
La procedura che seguo è abbastanza semplice:
- Controllo blacklist e reputazione dell'IP.
- Individuo e risolvo eventuali cause di spam.
- Configuro SPF, DKIM e DMARC.
- Verifico la propagazione DNS.
- Controllo reverse DNS e configurazione SMTP.
- Invio un messaggio reale e analizzo il risultato con Mail-Tester.
Non esiste una configurazione che garantisca al 100% la consegna nella posta in arrivo, ma partire da queste verifiche permette di eliminare molti dei problemi più comuni e costruire un'infrastruttura email decisamente più affidabile.
FAQ
Perché le email finiscono nello spam anche se il server funziona?
Perché la consegna di un'email dipende da molti fattori oltre al funzionamento del server. Reputazione dell'IP, blacklist, autenticazione SPF/DKIM/DMARC, contenuto del messaggio e policy del provider destinatario possono influenzare il risultato.
Come faccio a sapere se il mio IP è in blacklist?
Puoi utilizzare servizi come MXToolbox, Spamhaus Lookup e MultiRBL. Inserisci l'indirizzo IP effettivamente utilizzato per inviare le email e controlla le liste che restituiscono una segnalazione.
SPF, DKIM e DMARC devono essere configurati tutti?
È fortemente consigliato configurare tutti e tre. SPF identifica i server autorizzati, DKIM firma i messaggi e DMARC definisce come gestire i messaggi che non superano i controlli di autenticazione. I tre meccanismi lavorano insieme.
Mail-Tester garantisce che le email arrivino nella posta in arrivo?
No. Mail-Tester analizza il messaggio e diversi aspetti dell'infrastruttura di invio, ma non può garantire il comportamento dei sistemi antispam proprietari di Gmail, Outlook o altri provider.
Quanto tempo serve per rimuovere un IP da una blacklist?
Dipende dalla blacklist e dalla causa della segnalazione. Alcune prevedono procedure automatiche, altre richiedono una richiesta manuale o l'intervento del provider che gestisce l'indirizzo IP. Prima di chiedere il delisting è importante risolvere la causa del problema.
Posso configurare SPF, DKIM e DMARC se utilizzo un servizio SMTP esterno?
Sì. La maggior parte dei provider SMTP mette a disposizione le istruzioni per configurare i record DNS necessari. È importante autorizzare il servizio tramite SPF, pubblicare la chiave DKIM fornita e verificare l'allineamento DMARC con il dominio utilizzato nell'indirizzo mittente.
Approfondimenti
Se ti occupi di gestione server, applicativi e infrastrutture web, potrebbero interessarti anche:
- Migrazione VPS e configurazione server: un caso pratico di gestione e configurazione di un'infrastruttura server.
- Bot Telegram per monitorare l'error log PHP e i servizi: come monitorare errori e servizi con notifiche automatiche.
- NIS2: adeguamento di siti web e applicazioni per le PMI: sicurezza e gestione delle infrastrutture digitali.