Perché l'email che ti sei inoltrato finisce nello spam

Configura un inoltro automatico dal tuo vecchio account a quello nuovo, e parte di quella posta scomparirà silenziosamente nello spam — non perché il tuo provider è rotto, ma perché l'inoltro riscrìve chi sta inviando il messaggio senza riscrivere la prova crittografica. SPF controlla il server sbagliato, il verdetto DMARC cambia in fallimento, e un'email legittima che ti sei inoltrato finisce in quarantena. La soluzione ha un nome: ARC, definito in RFC 8617 nel 2019.

Perché l'inoltro fa fallire SPF sulla mia posta?

Perché SPF controlla l'ultimo server che ha inoltrato il messaggio, e l'inoltro cambia quel server. SPF — Sender Policy Framework — è un record DNS che elenca quali indirizzi IP sono autorizzati a inviare posta per un dominio. Quando bank.com ti invia una ricevuta, il server ricevente controlla: è arrivato da un IP autorizzato da bank.com? Sì. Passa.

Ora inoltri quella ricevuta da Gmail al tuo nuovo indirizzo. I server di Google la inoltrano oltre. Il server ricevente finale esegue il controllo SPF e chiede: Google è autorizzato a inviare per bank.com? No, non lo è. SPF fallisce. La stessa documentazione di Google Workspace lo spiega chiaramente — i messaggi inoltrati falliscono SPF perché il server di inoltro non è nel record SPF del dominio originale. Niente è stato falsificato. Il controllo sta semplicemente guardando l'hop sbagliato.

Allora perché finisce nello spam?

DMARC. Un tempo il fallimento di SPF da solo era superabile; DMARC lo ha trasformato in un verdetto. DMARC lega insieme SPF e DKIM e dice ai ricevitori cosa fare quando entrambi falliscono: niente, mettere in quarantena, o rifiutare. Nel 2024, i grandi mittenti non avevano scelta — Google e Yahoo hanno iniziato a richiedere DMARC a chiunque invii più di 5.000 messaggi al giorno ai loro utenti.

DKIM, l'altro pilastro, è una firma inserita nel messaggio. In teoria sopravvive all'inoltro, perché firma il contenuto, non il percorso. In pratica, qualsiasi cosa tocchi il messaggio la rompe. Una mailing list che aggiunge un footer "sei iscritto, annulla l'iscrizione qui", un server che riscrìve la riga dell'oggetto, persino un cambio in come una riga va a capo — la firma non corrisponde più, e DKIM fallisce anche lui. Ora entrambi i pilastri sono giù, DMARC dice fallimento, e la tua stessa ricevuta è nella cartella junk.

Cos'è ARC e aggiusta davvero questo problema?

ARC — Authenticated Received Chain, RFC 8617 — consente a un inoltrator onesto di attestare che la posta ha superato l'autenticazione prima di toccarla. Il server di inoltro appone al messaggio un record sigillato dicendo "quando è arrivato da me, SPF e DKIM erano validi — fida sulla mia parola per il tratto che non puoi verificare." Il ricevitore finale, se si fida di quel forwarder, può ignorare il fallimento DMARC e consegnare.

Il trucco sta in "se si fida." ARC non è una password; è un sistema di reputazione. Un ricevitore pesa se il sigillatore ARC è un operatore noto e ben comportato. Google sia appone intestazioni ARC che le onora dai mittenti di cui si fida, per questo un inoltro Gmail-a-Gmail di solito sopravvive mentre un inoltro attraverso qualche antico relay universitario non lo fa.

Se gestisci l'inoltro tu stesso, due mosse concrete aiutano. Usa la riscrittura Server-Side Redirect / SRS-style se il tuo host la offre, che riscrìve il mittente della busta così SPF controlla contro il tuo forwarder invece del dominio originale. E preferisci l'inoltro tra provider che entrambi supportano ARC. Se stai consolidando account e vuoi che la destinazione gestisca per te il disastro dell'autenticazione, è esattamente il tipo di infrastruttura per cui una piattaforma email con AI è costruita per assorbire.

Quando dovrei smettere di incolpare il mio provider?

Quando il pattern è "solo la posta inoltrata fallisce," il provider sta facendo correttamente il suo lavoro — il problema è il protocollo. Ecco l'indicatore: apri l'intestazione del messaggio mancante e cerca la riga Authentication-Results. Se vedi spf=fail insieme a un IP di invio che appartiene a un forwarder piuttosto che al mittente originale, è SPF che controlla l'hop sbagliato. Se dkim=fail appare su posta che è passata attraverso una lista o un relay che modifica i messaggi, è una firma danneggiata, non una falsificazione.

La verità scomoda è che l'autenticazione email è stata aggiunta, strato dopo strato, nel corso di due decenni a un sistema che non ha mai assunto che qualcuno avrebbe mentito. SPF è arrivato nel 2006, DKIM nel 2007, DMARC nel 2015, ARC nel 2019 — ognuno ha rattoppato un buco che il precedente ha aperto. L'inoltro è la cucitura dove tutti e quattro si sfregano l'un l'altro, e la tua inbox è dove senti l'attrito.

@@END@@