Configure SPF fail all

È sempre corretto usare il prefisso -all (hard fail) nei record SPF?

Il record SPF (Sender Policy Framework) serve a dichiarare quali server sono autorizzati a inviare email per conto di un dominio. L'uso del meccanismo all con i prefissi - (hard fail) o ~ (soft fail) stabilisce la policy per i mittenti non esplicitamente elencati.

Differenze tra -all e ~all

Significato operativo

• ~all (soft fail): il server ricevente considera il mittente come **sospetto**, ma generalmente accetta il messaggio (con penalizzazione nel punteggio antispam).
• -all (hard fail): il server ricevente **può rifiutare direttamente** l'email se l'IP non è tra quelli autorizzati nel record SPF.

Rischi di -all

• Può causare **falsi positivi**, ad esempio con inoltri (forwarding) o relay esterni.
• Blocca il messaggio **prima** che vengano eseguite eventuali verifiche DKIM o DMARC.
• L'effetto dipende comunque dalle **politiche del server ricevente**, che può ignorare o mitigare il significato di -all.

Quando è corretto usare -all?

L’hard fail è **opportuno solo** quando:

• Il dominio non deve mai inviare email (domini “di parcheggio” o “difensivi”).
• Tutti i mittenti autorizzati sono stati identificati e il sistema è stabile.
• È già attivo un sistema DMARC con monitoraggio (reporting `p=none`) o enforcement (`p=quarantine` / `reject`).

Esempio: Il dominio bancarossa.ch registra i domini bancarossa.net e bancarossa.com solo a scopo difensivo. In tal caso, un record SPF come:

v=spf1 -all

comunica ai server che **nessun IP è autorizzato a inviare email**, riducendo il rischio di spoofing su quel dominio.

Strategia di transizione consigliata

Per un dominio mittente è raccomandata la seguente strategia:

1. Iniziare con ~all per raccogliere dati tramite DMARC (policy `p=none`).
2. Analizzare i report aggregati per identificare tutti i mittenti legittimi.
3. Aggiungere i relativi IP/meccanismi (A, MX, include, ip4/6).
4. Solo quando il dominio è completamente mappato, passare a -all.

Questo approccio progressivo evita blocchi involontari e consente un deployment sicuro.

Considerazioni aggiuntive

• **DKIM e DMARC** offrono protezione più robusta, in particolare per l’header “From”.
• L’SPF autentica il mittente SMTP (MAIL FROM), che può essere diverso da quello visibile.
• In ambienti come **Microsoft 365**, l'effetto di -all è spesso ridotto al solo impatto sullo spam score.

Riferimenti esterni

Linee guida

• Microsoft – Email authentication: SPF
• PowerDMARC – SPF Softfail vs Hardfail
• EasyDMARC – SPF All Mechanisms Explained
• RFC 7208 – Sender Policy Framework (SPF) for Authorizing Use of Domains in Email