Perché la tua casella di posta trabocca di rapporti di mancata consegna per campagne che non hai mai lanciato? La dashboard del tuo strumento di email marketing mostra zero invii. Eppure gli NDR si accumulano dal giorno prima. Questo fenomeno ha un nome preciso: il backscatter. Uno spammer ha usato il tuo dominio come indirizzo di ritorno sui suoi invii fraudolenti; i server che rifiutano questi messaggi a posteriori ti rimandano il conto sotto forma di rimbalzi. Niente a che vedere con un attacco al tuo account né con una fuga della tua lista contatti.
Il meccanismo del backscatter: From visibile e Return-Path, due indirizzi distinti
Il client di posta mostra un mittente. Il comando SMTP MAIL FROM ne porta un altro, invisibile nell’interfaccia. Questo secondo indirizzo, il Return-Path, serve da destinazione per i rimbalzi. Uno spammer usurpa questo campo tecnico, non necessariamente il From visibile che vede il destinatario finale nella sua casella di posta. Inserisce il tuo dominio nella busta SMTP al momento del comando MAIL FROM, senza che il corpo del messaggio mostri mai il tuo nome. Questa distinzione conta anche più avanti, per il tipo di impostazione che interrompe il flusso. Il meccanismo completo dell’usurpazione, dal From falsificato alla contraffazione d’identità completa, lo trattiamo nel nostro articolo su come funziona l’email spoofing. Qui il bersaglio è più circoscritto: la busta tecnica, quella che il protocollo usa per instradare i rapporti di errore, distinta dal messaggio che legge realmente il destinatario finale.
Perché il server del destinatario rimanda il rimbalzo a te
Perché spedisce il rapporto di errore all’indirizzo indicato nella busta. Questo indirizzo porta il tuo dominio. Nessun elemento del protocollo gli permette di sapere che è stato falsificato. Un server che riceve un’email fraudolenta può comportarsi in due modi. Il primo rifiuta la connessione in diretta, durante la transazione SMTP, con un codice di errore immediato; nessun rimbalzo viene mai generato, il problema si ferma di netto lato server mittente dello spam. Il secondo accetta il messaggio. Lo scopre troppo tardi: la casella è piena o il destinatario non esiste. È questo secondo caso a produrre il backscatter: il server genera un NDR (Non-Delivery Report), nel formato definito dalla RFC 3464 (IETF, 2003), per poi inviarlo in buona fede al Return-Path usurpato.
Un ricercatore che ha ricevuto 49.000 messaggi di backscatter in quattro mesi ha passato i suoi rimbalzi al vaglio di quattro liste nere: su 4177 rimbalzi con IP mittente identificabile, il 19% di queste IP non vi figurava ancora, con SpamCop che ne segnalava il 73% e CBL il 69% (Christopher Fuhrman, École de technologie supérieure de Montréal, 2008).
Questa vecchia osservazione resta attuale. I server mal configurati che accettano per poi rifiutare, invece di respingere all’ingresso, formano un parco residuo che continua a funzionare, spesso caselle di posta aziendali amministrate da team che non seguono più le raccomandazioni SMTP correnti. La tipologia completa dei diversi motivi di email non consegnate è trattata altrove. Il backscatter si aggiunge come un caso particolare, generato da terzi e senza legame con il tuo invio.
Leggere gli header del bounce per confermare che l’invio non viene da te
Arriva un rimbalzo sospetto. Tre verifiche bastano di solito a chiarire la situazione, in quest’ordine:
- La catena Received, in cima al messaggio grezzo, elenca ogni server attraversato dal primo all’ultimo. Se nessuno di essi corrisponde alla tua infrastruttura di invio abituale, IP, MTA, piattaforma di email marketing identificata, l’origine è esterna.
- Il Message-ID del messaggio originale, generalmente incluso nel corpo del bounce sotto forma di citazione parziale. Un Message-ID che i tuoi log di invio non hanno mai generato conferma che il messaggio non è mai partito da te.
- L’Enhanced Status Code del rapporto, nel formato 5.x.x, precisa la causa esatta del rifiuto lato server destinatario: casella inesistente o quota superata.
Un bounce da backscatter si riconosce dall’assenza totale di corrispondenza tra il suo Message-ID e i log di invio del mittente legittimo, indipendentemente dalla piattaforma di invio usata, Twilio SendGrid, Mailjet o un SMTP proprietario. Senza questa corrispondenza, non serve alcuna indagine ulteriore.
Cosa non significa: né attacco, né fuga di lista
La prima reazione, scoprendo decine di NDR sconosciuti, tende spesso verso l’ipotesi dell’account compromesso. Si capisce. Ma un backscatter non presuppone alcun accesso al dominio né alla casella di posta, nessuna fuga di database contatti, nessuna compromissione dello strumento di email marketing. Lo spammer ha bisogno solo di un’informazione pubblica, il tuo nome di dominio, per inserirlo nella busta di un invio che non coinvolge mai i tuoi server. Si potrebbe anche pensare che un ESP basti a coprire questo rischio, dato che gestisce già l’autenticazione degli invii in uscita. SPF e DMARC si dichiarano però a livello del DNS del dominio, non a livello dello strumento di invio: cambiare ESP non chiude quindi nulla finché questi record restano assenti o permissivi.
Una preoccupazione torna poi sistematicamente: questo flusso mi farà finire in blacklist? Backscatterer.org, la lista nera dedicata a questo fenomeno, censisce i server che emettono backscatter, mai i domini usurpati che lo ricevono. Ci si entra rimandando rimbalzi verso terzi innocenti. Riceverne migliaia non cambia nulla.
Cosa si può fare davvero: pubblicare un SPF in hard fail
Un record SPF pubblicato in -all è l’unica impostazione che agisce sulla fonte del backscatter. Questo hard fail chiede al server ricevente di rifiutare, durante la transazione SMTP, ogni messaggio che indica il tuo dominio in MAIL FROM senza provenire dai tuoi server autorizzati. Il messaggio muore alla porta, nessun NDR viene generato, nulla riparte verso di te. La sintassi completa è dettagliata nel nostro articolo su cosa succede quando l’SPF è assente. Il rischio del superamento è trattato in questa guida sulla limite delle 10 ricerche DNS. Ciò che nessuna configurazione farà, invece: impedire a uno spammer di scrivere il tuo dominio in una busta o costringere un server terzo mal configurato a rispettare SPF.
DMARC interviene su un altro piano. La sfumatura decide cosa puoi aspettartene qui. Una policy in p=quarantine o p=reject si valuta sul dominio del campo From di intestazione, quello che vede il destinatario, dopo aver verificato che una firma DKIM o un controllo SPF autentichi effettivamente questo dominio. È la regola di allineamento. Quando lo spammer si limita a usurpare la busta e firma il suo messaggio con un From estraneo al tuo dominio, la tua policy DMARC non viene quindi mai consultata dal server ricevente. Protegge il tuo brand dall’usurpazione visibile, non ferma da sola i rimbalzi smarriti: quel ruolo spetta a SPF, con DMARC che subentra non appena lo spammer usurpa anche il From visualizzato.
Sul lato ricezione, BATV (Bounce Address Tag Validation) risolve il filtro alla radice. Il tuo server firma l’indirizzo di ritorno di ogni invio in uscita con un token datato, poi rifiuta qualsiasi NDR indirizzato a un indirizzo non firmato. Un backscatter non può portare questo token, dato che risponde a una busta che non hai mai emesso. Monitorare i rapporti aggregati DMARC (rua) offre inoltre un’immagine del volume e dell’origine dell’usurpazione, senza mai fermarla alla fonte, con la stessa riserva vista sopra: questi rapporti riportano solo i messaggi che portano il tuo dominio nel From di intestazione. Un’usurpazione limitata alla busta non vi comparirà. La lettura di questi file XML è spiegata per intero nella nostra guida per leggere un rapporto DMARC aggregato.
Questo irrigidimento ha un limite. Un SPF hard fail non zittisce i server che ignorano la policy, che non hanno aggiornato il proprio resolver o che applicano una valutazione parziale dei record DNS. Questo residuo continua a produrre rimbalzi smarriti, anche dopo una distribuzione corretta lato dominio. Il -all ha inoltre un costo collaterale da conoscere: un messaggio legittimo inoltrato tramite un alias o una casella di reindirizzamento fallisce il controllo SPF presso il destinatario finale, poiché l’IP che presenta il messaggio non è più la tua. I server di redirect ben gestiti riscrivono la busta via SRS per evitare questo; gli altri romperanno i tuoi inoltri.
Verificare che il tuo server non ne produca
Il ragionamento si ribalta. Questa metà dell’argomento è quasi sempre passata sotto silenzio. Un server che accetta tutto per poi rimandare un NDR fabbrica esattamente il rumore descritto sopra, presso qualcun altro. Le impostazioni che producono questo comportamento sono note:
- un indirizzo catch-all che assorbe qualsiasi destinatario prima di scoprire che la casella non esiste;
- un autorisponditore di assenza che risponde meccanicamente a una busta usurpata;
- un gateway antispam che filtra dopo l’accettazione, invece di rifiutare durante la transazione SMTP.
La correzione sta in una regola: convalidare l’esistenza del destinatario al momento del RCPT TO e rifiutare lì, con un codice 5.x.x, invece di accettare per poi scusarsi. È questo che separa un server che protegge gli altri da un server che finisce su Backscatterer.org.
Non confondere backscatter e vera lista sporca
Un picco improvviso di rimbalzi nelle statistiche di invio somiglia, a prima vista, a un degrado della sender reputation. Nella maggior parte dei casi non è così, se i rimbalzi riguardano campagne mai lanciate. La confusione costa cara quando spinge a ripulire una lista contatti sulla base di un segnale che non viene da essa: gli errori di consegna segnalati da Google Postmaster Tools, così come i contatori di hard bounce della tua piattaforma di invio, restano sordi ai backscatter mai transitati dalle tue campagne, dato che nessun invio reale li ha innescati. Prima di concludere per una list hygiene carente sulla base di un flusso di NDR, verifica tramite gli header descritti sopra se questi rimbalzi corrispondono a un invio reale o a una busta usurpata: ripulire la lista contatti non risolverà nulla se il problema viene da altrove.
L’adozione di DMARC progredisce, spinta dalle regole imposte ai grandi mittenti da Google e Yahoo da febbraio 2024, che richiedono come minimo una policy pubblicata in p=none. La revisione dello standard uscita nel 2026 sotto il nome di DMARCbis (RFC 9989) non alza questa soglia: riformula il protocollo e sostituisce l’elenco dei suffissi pubblici con una risalita dell’albero DNS, senza imporre a nessuno una policy rigorosa. Il parco residuo di caselle di posta mal configurate, invece, segue un calendario molto più lento, quello degli aggiornamenti DNS che nessuno ha pianificato.
