Inoltro email: SPF fail ed email inoltrate nello spam

Cosa succede durante un inoltro

SPF (Sender Policy Framework) verifica una sola cosa: il server che consegna l'email è autorizzato a inviare per il dominio del mittente? Conta l'indirizzo mittente tecnico nella busta dell'email, non il mittente visibile.

Un esempio: un suo cliente scrive a info@example.com. Il suo hoster inoltra l'email a una casella Gmail privata. Gmail vede ora come mittente il server del suo hoster, ma nella busta c'è ancora il dominio del cliente. Il server del suo hoster non figura nella voce SPF del cliente. Risultato: spf=fail. Il funzionamento di SPF nel dettaglio è spiegato su SPF spiegato: chi può inviare per il vostro dominio?.

DMARC richiede che SPF o DKIM superi il controllo e corrisponda al dominio visibile del mittente (allineamento). Dopo un inoltro, SPF è quasi sempre perso. Il superamento di DMARC dipende quindi solo da DKIM.

Quando DKIM sopravvive all'inoltro

DKIM è una firma digitale su intestazioni e contenuto dell'email. Non è legata al server, ma all'email stessa. Un semplice inoltro che non modifica nulla lascia la firma valida. Il risultato è: SPF fail, DKIM pass, DMARC pass.

DKIM si rompe non appena qualcosa viene modificato lungo il percorso:

• Una mailing list aggiunge un prefisso come «[Comitato]» davanti all'oggetto.
• Una lista o un gateway aggiunge un piè di pagina o una clausola di esclusione di responsabilità.
• Un filtro di sicurezza riscrive i link o contrassegna l'oggetto con «[ESTERNO]».
• Un server ricodifica il testo o gli allegati.

L'intestazione mostra allora di solito dkim=fail (body hash did not verify). Il significato di questi messaggi è spiegato su Firma DKIM non valida: «body hash did not verify» e altri errori. Se falliscono sia SPF sia DKIM, fallisce DMARC. Con p=quarantine l'email finisce nello spam, con p=reject viene respinta.

Gli inoltri più comuni

• Inoltro a una casella privata: info@ o l'indirizzo personale viene inoltrato automaticamente a Gmail, Bluewin o Outlook.com.
• Alias o lista di distribuzione presso l'hoster: contabilita@ distribuisce le email a più indirizzi esterni.
• Mailing list e gruppi: associazioni, federazioni, gruppi di progetto. Qui l'email viene spesso modificata.
• Indirizzi di studio o di ex allievi inoltrati, e vecchi indirizzi dopo un cambio di dominio.

Non è in questione il pulsante «Inoltra» di Outlook. Crea una nuova email con il suo indirizzo come mittente, che viene verificata normalmente.

SRS e ARC spiegati in modo semplice

SRS (Sender Rewriting Scheme) è una soluzione per chi inoltra. Sostituisce l'indirizzo della busta con uno proprio, ad esempio SRS0=…=cliente.example.org=info@inoltro.example.net. Il destinatario verifica allora SPF rispetto al dominio di chi inoltra, e SPF viene superato. Secondo la propria documentazione, Microsoft 365 riscrive così le email inoltrate verso l'esterno. Importante: SRS salva SPF, ma non l'allineamento DMARC, perché il dominio SPF è ora quello di chi inoltra. Per DMARC resta decisivo DKIM.

ARC (Authenticated Received Chain) è una sorta di verbale. Chi inoltra annota i risultati di SPF, DKIM e DMARC rilevati presso di sé e sigilla questa annotazione con intestazioni come ARC-Seal. Il destinatario può fidarsi di questo sigillo, ma non è obbligato. ARC è descritto come standard sperimentale (RFC 8617). Microsoft 365 consente agli amministratori di definire sigilli ARC attendibili. ARC dipende da chi inoltra e dal destinatario: come mittente non può attivarlo.

Se le sue email vengono inoltrate: allineare DKIM

Non può influire su dove i suoi clienti inoltrano le email. Può però fare in modo che DKIM regga.

1. Attivare DKIM per ogni canale di invio: Microsoft 365, Google Workspace, casella presso l'hoster, strumento per newsletter, contabilità, negozio online. Per Microsoft 365 significa ad esempio due voci CNAME selector1._domainkey.example.com e selector2._domainkey.example.com. Guida: Microsoft 365: le e-mail finiscono nello spam, DKIM spesso non è attivato.
2. Firmare con il proprio dominio: la firma deve riportare d=example.com (o un suo sottodominio). Se lo strumento per newsletter firma solo con il proprio dominio, DKIM viene superato, ma non è allineato. Dopo un inoltro, quell'email fallisce quindi DMARC.
3. Verificare: invii un'email di prova a un indirizzo che inoltra a una casella Gmail. In Gmail, alla voce «Mostra originale», dovrebbe leggere: SPF fail o neutral, DKIM pass con il suo dominio, DMARC pass.
4. Solo dopo inasprire: passi a p=quarantine o p=reject solo quando tutti i canali di invio firmano in modo allineato. Una voce appare allora così: v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com.

Se inoltra lei stesso: recuperare invece di reindirizzare

Se reindirizza l'indirizzo aziendale a una casella privata, il problema colpisce le email dei suoi clienti e fornitori. Non può riparare il loro DKIM. Inoltre il filtro antispam della casella di destinazione impara che attraverso il suo server passa anche spam.

• Meglio recuperare: colleghi la casella aziendale via IMAP direttamente al suo programma o alla sua app di posta. L'email resta nella casella aziendale, nulla viene inoltrato. Attenzione: secondo Google, Gmail sul web dismette nel 2026 il recupero di altre caselle via POP. Nell'app Gmail è possibile aggiungere un altro account via IMAP.
• Se l'inoltro è necessario: chieda al suo hoster se gli inoltri vengono riscritti con SRS e se applica sigilli ARC.
• Liste di distribuzione con destinatari esterni: le limiti allo stretto necessario.

Riconoscere gli inoltri nel rapporto DMARC

Nei rapporti DMARC giornalieri (basi: Leggere il rapporto DMARC: cosa c'è nei file XML e cosa farne), gli inoltri mostrano uno schema tipico:

• L'indirizzo IP di origine non appartiene ai suoi canali di invio, ma ad esempio a un grande fornitore di posta, a una scuola universitaria o a un hoster.
• Poche email per origine, ma molte origini diverse.
• SPF fail o SPF pass per un dominio estraneo, e contemporaneamente DKIM pass per example.com: innocuo, DMARC viene superato.
• SPF fail e DKIM fail per un'origine il cui nome inverso sembra quello di un server di liste: una mailing list che modifica le email.
• Alcuni destinatari indicano come motivo forwarded, mailing_list o trusted_forwarder quando non hanno applicato di proposito la sua regola.

A confronto lo spoofing: origini sconosciute senza firma DKIM valida del suo dominio, spesso in gran numero e da Paesi senza legami con lei.

Errori tipici

• Aggiungere il server di chi inoltra alla propria voce SPF: così autorizza server estranei a inviare a suo nome. Non risolve nulla e indebolisce la protezione.
• Ammorbidire SPF da -all a ~all: DMARC fallisce comunque, perché SPF non è allineato.
• Riportare DMARC a p=none: espone il suo dominio alle falsificazioni, invece di riparare DKIM.
• DKIM solo per la casella principale: newsletter e fatture inviate da sistemi terzi restano senza firma allineata.

Cosa fa DomainRadar per voi

DomainRadar analizza automaticamente i suoi rapporti DMARC, attribuisce le origini a fornitori noti e distingue gli inoltri dalle vere falsificazioni. Vede quale canale di invio non ha una firma DKIM allineata, prima di inasprire la regola.

Decodificatore di rifiuti