Come evitare che le email inviate finiscano in SPAM

Alcuni utenti, pur scaricando la posta in modo corretto con HTML2POP3, segnalano che le email inviate, a causa di particolari impostazioni di DNS, finiscono nella cartella SPAM o peggio non vengono ricevute dal destinatario. Vediamo come risolvere il problema in modo definitivo.

Alcuni utenti di HTML2POP3 mi hanno segnalato dei problemi con l'invio mail: i messaggi non partono, oppure partono, ma non vengono ricevuti o vengono ricevuti, ma finiscono in SPAM.

Per questo motivo provo a fare un po' di chiarezza su come funziona il servizio di invio della posta tramite SMTP e come poter ottimizzare le proprie impostazioni per ridurre al minimo i problemi.

Proverò ad analizzare il caso in cui, un utente con email targate @libero.it, provi ad inviare della posta su una connessione ADSL non Infostrada.
Il caso può però essere facilmente adattato a qualsiasi situazione nella quale, l'invio delle email è effettuato da un provider diverso da chi ci fornisce il servizio di posta.

Controlli di congruenza
La prima operazione che effettua un server SMTP quando viene interrogato è quella di verificare la congruenza del mittente del messaggio che si prova a inviare, con l'elenco dei domini abilitati all'invio.

In base alle configurazioni del server, l'incongruenza può essere ignorata o utilizzata per scartare il messaggio da inviare.

Oltre a questo, il server può aumentare il livello di sicurezza, obbligando l'utente che intende inviare un'email, ad autenticarsi con lo stesso utente utilizzato per controllare la posta tramite POP3 o IMAP.

Visto il grande numero di casistiche da controllare, alcuni provider tendono semplificare le procedure di invio limitandosi a verificare se, l'IP del client che invia la posta, è nel range degli IP gestisti.

Per questo motivo, se il mio provider è ALICE, posso inviare tramite il server out.alice.it, anche se il mittente dei messaggi è, ad esempio, mail.di.fantasia@libero.it.

Per quanto riguarda i server che ricevono un messaggio, i controlli sono leggermente diversi.
Esistono dei servizi di blacklist in grado di dire se, un particolare indirizzo IP, è stato contrassegnato come indirizzo dal quale vengono inviate notoriamente email di SPAM.
Se il server ricevente implementa un algoritmo di controllo basato su blacklist, il messaggio è subito bloccato.

Oltre a questo, alcuni provider hanno iniziato a gestire in modo più stringente il controllo del record SPF del DNS del dominio mittente delle email.

Il record SPF serve ad indicare se, il server SMTP che invia una particolare email, è autorizzato a farlo.

Ma come funziona il record SPF?
Ipotizziamo di dover inviare una eventuale email dall'indirizzo di posta

mail.di.fantasia@libero.it

Il server ricevente, in caso di controllo di congruenza dell'email, effettua una chiamata al DNS di libero.it per verificare se è presente un record SPF.

Per sapere com'è impostato il record SPF di un certo dominio potete usare il servizio online:

http://www.kitterman.com/spf/validate.html

Per quanto riguarda libero.it, l'attuale risultato è:

v=spf1 ip4:212.48.25.128/25 include:srs.bis.na.blackberry.com include:srs.bis.eu.blackberry.com include:srs.bis.ap.blackberry.com -all

che significa che, i server abilitati a mandare posta "libero.it", sono solo quelli il cui IP o DNS è presente in questo record.

Di conseguenza, se inviamo posta libero.it con un altro gestore, ad esempio smtp.tiscali.it o out.alice.it, il server che riceve l'email controlla il record SPF e si accorge che l'IP o il DNS del server che gli invia l'email non è compreso fra quelli ammessi.

A questo punto verifica le indicazioni che, il gestore del servizio email, suggerisce in caso di IP non corrispondenti.

Per quanto riguarda libero il suggerimento è

-all

che indica che qualsiasi altro indirizzo di spedizione è da considerarsi come non autorizzato.

A questo punto il server ricevente assegna un valore al controllo SPF che, per quanto riguarda libero.it, si traduce in un FAIL, per le email non inviate dai server SMTP ufficiali.

Questo fallimento viene poi gestito in base alle configurazioni del server e si può tradurre in:

1) Non consegna dell'email
2) Consegna nella cartella di SPAM
3) Eliminazione dell'email.

Ultimamente, la pratica del controllo SPF è aumentata parecchio, per contrastare il fenomeno dello SPAM.

Per risolvere il problema vi sono alcune strade percorribili:

1) Usare l'smtp corretto: quello fornito da chi vi da il servizio di posta. In questo caso stiamo parlando dell'SMTP di libero. Attenzione però: per poterlo usare dovete autenticarvi col vostro utente @libero.it, soprattutto se utilizzate la posta di libero.it su connessioni ADSL di altri provider.

2) Utilizzare la Webmail per inviare messaggi

Tutte le altre strade generano un fallimento della congruenza del server di invio, rispetto al record SPF, con conseguente alta probabilità di fallimento dell'invio dell'email.

Per questo motivo, controllare che ci sia sempre coerenza fra mittente e SMTP di invio, per ridurre al minimo le casistiche di fallimento di invio della posta.


Di seguito, un esempio di come configurare l'invio di libero con ADSL Telecom, in modo che passi correttamente il controllo SPF:

Received-SPF: pass (google.com: domain of testplugin@libero.it designates 212.48.25.164 as permitted sender) client-ip=212.48.25.164;




AGGIORNAMENTO 20/10/2016

v=spf1 ip4:212.48.25.128/25 ip4:212.48.14.160/27 include:srs.bis.na.blackberry.com include:srs.bis.eu.blackberry.com include:srs.bis.ap.blackberry.com include:mail.zendesk.com -all

Libero.it ha aggiornato il proprio SPF Record, indicando una serie di nuovi server e le email provenienti da zendesk.com Leggi QUI il post completo