SPF ~all o -all? Softfail e hardfail spiegati in modo semplice

Prima verificare: come termina la sua voce SPF?

Inserisca il suo dominio nella verifica gratuita: Controllo del dominio gratuito. Mostra la sua voce SPF e segnala se la chiusura manca oppure è +all o ?all. Una voce tipica ha questo aspetto:

v=spf1 include:spf.protection.outlook.com include:[include-newsletter] ~all

L'ultima parte, la chiusura, vale per tutti i server non elencati prima. Il segno che la precede si chiama qualificatore e determina il risultato.

Le quattro chiusure e cosa fa il destinatario

SPF verifica l'indirizzo della busta (Return-Path), non il mittente visibile. Se l'e-mail arriva da un server che non è nella voce, si applica la chiusura:

• -all dà fail (hardfail): «Questo server non può inviare per noi.» Lo standard RFC 7208 consente al destinatario di rifiutare l'e-mail, preferibilmente con il codice 550. Molti destinatari la consegnano comunque, ma con una valutazione peggiore.
• ~all dà softfail: «Probabilmente non autorizzato, ma non ci sbilanciamo.» Secondo lo standard il destinatario non deve rifiutare l'e-mail solo per questo motivo, ma può esaminarla più a fondo, ad esempio segnarla come spam.
• ?all dà neutral: nessuna indicazione. Lo standard impone di trattarlo come «nessun SPF». Pensato per i test, non per l'uso corrente.
• +all dà pass per qualsiasi server al mondo. Non è una protezione, è un via libera.

Se la chiusura manca del tutto, il risultato per i server sconosciuti è anch'esso neutral, come se alla fine ci fosse ?all.

Perché DMARC rende la scelta meno decisiva

DMARC non distingue tra softfail e hardfail. Per DMARC conta solo se SPF supera il controllo e corrisponde al dominio del mittente visibile. Entrambi i risultati sono un mancato superamento. Se un'e-mail falsificata viene rifiutata lo decide la sua regola DMARC (p=quarantine o p=reject), non il segno davanti ad all.

Ci sono però due limitazioni:

• Alcuni destinatari verificano SPF prima di DMARC. Lo standard DMARC RFC 7489 lo segnala esplicitamente: con -all un destinatario del genere può rifiutare l'e-mail prima ancora di valutare DMARC e quindi DKIM. L'organizzazione di settore M3AAWG chiede perciò ai destinatari di rifiutare per SPF fail solo dopo la verifica DMARC, salvo per la voce v=spf1 -all.
• Microsoft come destinatario scrive nella sua documentazione che la regola DMARC in pratica non si applica in caso di softfail SPF se l'e-mail non ha una firma DKIM. Nei criteri antispam di Microsoft 365 esiste inoltre l'opzione «SPF record: hard fail». È disattivata per impostazione predefinita. Se un destinatario la attiva, Microsoft 365 classifica le e-mail con SPF fail come spam ad alta attendibilità, indipendentemente da DKIM.

Cosa consigliano i grandi fornitori

Le raccomandazioni divergono, ed entrambe le parti hanno buoni motivi:

• Microsoft consiglia -all per i domini Microsoft 365, perché consiglia anche DKIM e DMARC. I rapporti DMARC devono mostrare se tutti i canali di invio sono coperti.
• Google consiglia ~all nella guida di Google Workspace.
• M3AAWG (Messaging, Malware and Mobile Anti-Abuse Working Group) scrive nelle sue raccomandazioni sull'autenticazione delle e-mail del 2020 che le voci SPF «should end in ~all» (dovrebbero terminare con ~all). I domini che non inviano e-mail devono pubblicare v=spf1 -all.

Tutti concordano su due punti: SPF da solo non basta, servono DKIM e DMARC. E un dominio senza invio di e-mail riceve v=spf1 -all.

Il rischio di -all con gli inoltri

Se un destinatario inoltra la sua e-mail, ad esempio dalla casella di un'associazione a un indirizzo privato, da lì in poi invia il server di chi inoltra. Questo server non è nella sua voce SPF. SPF fallisce quindi per forza, qualunque sia la chiusura.

La differenza: con -all rischia che un destinatario che valuta SPF presto e in modo rigido rifiuti subito l'e-mail. La sua firma DKIM valida avrebbe fatto superare DMARC, ma non viene mai esaminata. Con ~all l'e-mail di norma viene accettata, DKIM viene verificato e salva DMARC.

Importante: ~all non ripara DMARC negli inoltri. Senza una firma DKIM allineata DMARC fallisce comunque. La chiusura decide solo se DKIM ha la possibilità di essere verificato.

Come rendere comunque affidabili gli inoltri: Inoltro email: SPF fail ed email inoltrate nello spam

Perché +all è pericoloso

+all consente a qualsiasi server di inviare a nome del suo dominio. Con DMARC è particolarmente insidioso: un falsificatore inserisce il suo dominio nella busta e nel mittente visibile. SPF passa e corrisponde al dominio del mittente, quindi passa anche DMARC. La sua regola p=reject diventa inutile.

+all nasce perlopiù dall'impazienza: un'e-mail non arriva, qualcuno «apre» la voce e la falla resta per anni. Lo stesso vale per un all senza qualificatore: senza segno vale +.

Raccomandazione per le PMI in base al livello DMARC

1. Il dominio non invia e-mail (domini secondari, vecchi nomi aziendali): v=spf1 -all e DMARC con p=reject.
2. Ancora nessun DMARC o p=none: ~all. Finché non sa con certezza chi invia a suo nome (contabilità, negozio online, scanner, newsletter), -all blocca i canali dimenticati. Configuri prima DMARC con i rapporti, vedi DMARC da p=none a quarantine e reject: quando è sicuro?.
3. p=quarantine o p=reject, tutti i canali firmano con DKIM: qui -all è sostenibile e corrisponde alla raccomandazione di Microsoft. ~all resta altrettanto corretto. Se molti destinatari inoltrano le sue e-mail, ad esempio in associazioni, scuole o liste di soci, resti su ~all.

Passare da ~all a -all non sostituisce DMARC. La protezione dai mittenti falsificati arriva solo con p=reject.

Riconoscere gli errori nell'intestazione

Invii un'e-mail di prova a una casella esterna e apra le intestazioni complete, in Gmail con «Mostra originale». Cerchi Authentication-Results. Esempi abbreviati:

spf=softfail (domain of transitioning info@example.com does not designate 203.0.113.25 as permitted sender) smtp.mailfrom=info@example.com

spf=fail (sender IP is 203.0.113.25) smtp.mailfrom=example.com; dkim=none; dmarc=fail action=quarantine header.from=example.com

Come leggerli:

• spf=softfail o spf=fail, ma dkim=pass e dmarc=pass: perlopiù un inoltro. L'e-mail è in ordine.
• spf=fail e dmarc=fail per una vera e-mail sua: il server di invio manca nella voce SPF. Aggiunga l'include del fornitore. Attenzione al limite di dieci interrogazioni DNS: Errore SPF «too many DNS lookups»: perché il limite di dieci interrogazioni va rispettato.
• spf=permerror: la voce non è valida, spesso a causa di due voci SPF: Due voci SPF per un dominio: perché rendono tutto non valido.
• spf=neutral: la voce termina con ?all o non ha chiusura.

Errori tipici

• all a metà della voce: tutto ciò che segue all viene ignorato. v=spf1 -all include:[fornitore] non autorizza il fornitore.
• -all troppo presto: il negozio online o la contabilità mancano nella voce, le fatture vengono rifiutate.
• +all come soluzione d'emergenza: annulla la protezione di SPF e DMARC.
• Domini parcheggiati senza SPF: i falsificatori ripiegano volentieri sui domini inutilizzati.

Cosa fa DomainRadar per voi

DomainRadar verifica ogni giorno la sua voce SPF e segnala una chiusura mancante, troppo aperta o non valida. Dai rapporti DMARC vede quali fonti non superano SPF e se si tratta dei suoi canali di invio, di inoltri o di falsificazioni. Così decide il passaggio a -all sulla base di dati concreti.