SPF: “Hard Fail” e “Soft Fail”: qual è la differenza?

I risultati dell’SPF possono sembrare semplici finché una scelta relativa alle politiche non inizia a influire sul filtraggio, sulla resistenza allo spoofing e sui risultati di consegna. La presente guida illustra il significato dei termini “hard fail” e “soft fail” nell’ambito dell’SPF, le differenze tra i due, quando è opportuno ricorrere a ciascuno di essi e perché l’SPF funziona al meglio se integrato in una strategia più ampia di autenticazione delle e-mail.

Che cos’è un errore SPF?

SPF verifica se un server di posta è autorizzato a inviare e-mail per un determinato dominio. In questa sezione viene spiegato come si verifica un errore SPF e quale significato assumono solitamente i risultati più comuni dell'autenticazione.

Come si verifica il malfunzionamento dell’SPF

L'SPF, ovvero Sender Policy Framework, funziona confrontando l'indirizzo IP del mittente con il record SPF pubblicato nel DNS per il dominio. Si verifica un errore SPF quando il server ricevente non è in grado di confermare che l'indirizzo IP del mittente sia autorizzato per il dominio utilizzato nel campo "Mail From" della specifica RFC 5321, noto anche come percorso di ritorno.

Tale distinzione è importante perché l’SPF non viene sempre valutato in base all’indirizzo “Da” visibile nella posta in arrivo. Un messaggio può apparire legittimo al destinatario pur non superando il controllo SPF in base al dominio del percorso di ritorno.

Risultati comuni dell'autenticazione SPF

I risultati dell'autenticazione SPF possono variare. Potrebbe comparire il seguente messaggio:

• Superamento del controllo SPF: il server mittente è autorizzato dal record SPF del dominio, pertanto l’autenticazione SPF ha esito positivo.
• SPF assente: per il dominio non è stato pubblicato alcun record SPF, pertanto il server ricevente non dispone di alcun dato da valutare.
• neutro: Il dominio non indica chiaramente se il mittente sia autorizzato o meno, pertanto il risultato è inconcludente.
• Softfail SPF: È probabile che il mittente non sia autorizzato, ma il dominio non richiede ai destinatari di respingere il messaggio in modo definitivo.
• Errore grave SPF: il mittente non è autorizzato in base al record SPF e il dominio adotta un approccio più rigoroso nei confronti del messaggio.
• Errore SPF: non è stato possibile verificare completamente l'SPF a causa di un problema temporaneo, come un timeout DNS o un errore di ricerca.
• permerror: non è stato possibile valutare l'SPF a causa di un problema permanente nel record SPF, come una sintassi non valida o un numero eccessivo di ricerche DNS.

Alcuni risultati indicano un vero e proprio problema di autorizzazione, mentre altri segnalano la mancanza di criteri, criteri inadeguati, problemi di sintassi SPF o problemi relativi al DNS.

Ecco perché è utile verificare il valore esatto dell'SPF prima di procedere alla risoluzione dei problemi. Il risultato specifico indica solitamente se il problema è da attribuire a un mittente non autorizzato, a un record mancante, a un errore SPF più generale o a un problema relativo a un record o a una ricerca.

SPF: errore grave (Hard Fail) e errore non grave (Soft Fail)

Entrambi i risultati indicano che l'SPF non ha confermato che la fonte di invio fosse autorizzata. La differenza sta nell'intensità con cui il proprietario del dominio desidera che i sistemi destinatari interpretino tale errore.

Differenze sintattiche

La differenza tecnica risiede proprio nel record SPF stesso:

• Il "soft fail " utilizza ~all
• Errore grave: utilizzo di -all

Quel single carattere modifica il segnale che il dominio trasmette ai sistemi riceventi.

Differenze semantiche

Un "soft fail" indica che il dominio segnala che il mittente probabilmente non è autorizzato. Esprime preoccupazione, ma non costituisce una dichiarazione politica sufficientemente forte da giustificarne il rifiuto sulla base del solo SPF.

Un "hard fail" indica che il dominio segnala che il mittente non è autorizzato. Si tratta della posizione politica più rigorosa e riflette una maggiore fiducia nel fatto che i flussi di posta legittimi siano già contemplati nel record SPF.

Situazione attuale e orientamenti politici

Sia il "soft fail" che l’“hard fail” sono esiti di un errore SPF, ma i termini “spf softfail” e “spf hardfail” riflettono intenzioni diverse in termini di politica di sicurezza. Il termine “soft fail” viene spesso utilizzato quando un’organizzazione sta ancora verificando tutte le fonti di invio o desidera evitare falsi rifiuti durante la pulizia del proprio inventario dei mittenti. 

Il “hard fail” è più appropriato quando il proprietario del dominio nutre maggiore fiducia nella copertura SPF ed è disposto ad adottare una posizione più rigida nei confronti delle e-mail non autorizzate.

Come vengono gestiti dai sistemi di ricezione

In pratica, i messaggi di errore non grave vengono spesso accettati, ma filtrati, contrassegnati o instradati con maggiore cautela. I messaggi con errore grave hanno maggiori probabilità di essere respinti, messi in quarantena o valutati in modo più severo nell'ambito del sistema di sicurezza della posta elettronica nel suo complesso.

Queste differenze sono rilevanti poiché una modalità di errore errata può causare inutili difficoltà nella consegna oppure un’esposizione non necessaria al spoofing.

Quale modalità di errore SPF è opportuno utilizzare?

La modalità di errore SPF più appropriata dipende dalla completezza del vostro inventario dei mittenti e dal livello di rischio di consegna che la vostra organizzazione è disposta ad accettare. Le sezioni che seguono illustrano in quali casi il “soft fail” rappresenta solitamente la scelta più sicura e in quali casi il “hard fail” risulta più pratico.

Quando utilizzare il "soft fail"

Se la vostra organizzazione non è ancora certa che tutte le fonti di invio legittime siano incluse nel record SPF, l’opzione “~all” rappresenta solitamente il punto di partenza più sicuro. Riduce il rischio di respingere e-mail legittime mentre si procede all'inventario dei mittenti e alla pulizia dei record SPF.

Ciò risulta particolarmente utile durante le transizioni tra piattaforme, quando vengono aggiunti strumenti SaaS di terze parti o quando diverse unità aziendali gestiscono flussi di posta diversi. In tali casi, una politica di “soft fail” offre ai team la possibilità di monitorare i risultati dell’autenticazione SPF senza passare immediatamente a una politica rigorosa di “hard fail”.

Quando utilizzare l’opzione “Hard Fail”

Il passaggio alla directory -all risulta più opportuno una volta che le fonti di invio legittime siano state completamente documentate e convalidate. Ciò comprende l’infrastruttura di posta interna, i servizi di posta elettronica basati su cloud e i mittenti di terze parti.

Una volta che la copertura SPF è completa e stabile, una politica di “hard fail” può garantire una maggiore resistenza allo spoofing con un minor rischio di falsi rifiuti. Per la maggior parte delle organizzazioni, la soluzione più pratica consiste nell’iniziare con un “soft fail” mentre è ancora in corso la verifica della copertura SPF, per poi passare al “hard fail” solo quando il livello di affidabilità del record è elevato.

Casi d'uso comuni relativi agli errori "hard fail" e "soft fail" di SPF

Il caso d'uso più appropriato dipende spesso dal grado di completezza e stabilità della vostra copertura SPF. Il "soft fail" risulta solitamente più pratico durante le fasi di pulizia e individuazione, mentre il "hard fail" è più indicato quando le fonti di invio sono sottoposte a un controllo rigoroso.

In quali casi si verifica comunemente un “soft fail”

I fallimenti lievi sono comuni durante i periodi di transizione. Le organizzazioni ricorrono spesso a ~all mentre stanno ancora individuando i mittenti di terze parti, ripulendo i vecchi meccanismi SPF o consolidando i servizi di posta elettronica a seguito di cambiamenti relativi ai fornitori e alle infrastrutture.

È adatto anche a domini con ecosistemi di mittenti complessi. Se più piattaforme SaaS, reparti o sistemi regionali effettuano invii a nome dello stesso dominio, può risultare più difficile mantenere l’SPF sempre perfettamente aggiornato. In tali contesti, il "soft fail" offre un metodo meno invasivo per monitorare e perfezionare la politica SPF.

I casi in cui si verificano spesso errori irreversibili

Gli errori gravi sono più frequenti in ambienti di invio sottoposti a un controllo rigoroso. Se un dominio invia messaggi esclusivamente tramite Microsoft 365, esclusivamente tramite Google Workspace o tramite un’altra piattaforma soggetta a rigorosi controlli e dotata di un’infrastruttura di invio ben documentata, è più semplice garantire il supporto in tutta sicurezza.

È inoltre una soluzione indicata per le organizzazioni particolarmente attente alla sicurezza, dotate di un sistema maturo di governance dei mittenti e con una bassa tolleranza al rischio di spoofing. In tali contesti, una politica SPF più rigorosa contribuisce a far risaltare maggiormente le e-mail non autorizzate ai sistemi destinatari.

Strategie per garantire un'implementazione sicura dell'SPF

L'SPF funziona al meglio quando viene considerato come un meccanismo di controllo gestito, non come un'operazione DNS una tantum. Le seguenti pratiche contribuiscono a ridurre gli errori di configurazione e a mantenere la politica SPF in linea con il flusso effettivo della posta.

Utilizzi uno strumento per la generazione di record SPF

Uno strumento per la verifica dei record SPF o per la generazione di record SPF può aiutare i team a creare record più accurati, a verificare la sintassi SPF e a individuare eventuali problemi prima che le modifiche vengano rese operative. Ciò risulta particolarmente utile durante le operazioni di pulizia dell’SPF, le migrazioni di piattaforma o l’onboarding dei mittenti.

Utilizzare meccanismi SPF adeguati

Ogni meccanismo SPF dovrebbe corrispondere a una fonte di invio effettiva. L'uso eccessivo delle istruzioni "include", il mantenimento di voci obsolete o l'autorizzazione di ampi intervalli di indirizzi IP possono indebolire la politica di sicurezza e aumentare la complessità della risoluzione dei problemi.

Gestire e ottimizzare il record SPF

I registri dovrebbero essere concisi. Elimini i mittenti obsoleti, eviti inclusioni annidate non necessarie e presti attenzione al limite delle ricerche DNS. Se la valutazione SPF richiede un numero eccessivo di ricerche DNS, potrebbe restituire un errore permanente anziché un risultato di autorizzazione corretto. 

È inoltre importante evitare la presenza di più record SPF, poiché la pubblicazione di più di una politica SPF per lo stesso host può causare problemi di convalida anziché garantire un risultato corretto.

Applicate con attenzione le politiche di gestione degli errori

La scelta tra “soft fail” e “hard fail” dovrebbe rispecchiare l’effettiva copertura dei mittenti. Una politica più rigorosa non è automaticamente migliore se i dati disponibili sono incompleti. La politica SPF più efficace è quella che rispecchia il flusso effettivo della posta.

Monitorare i risultati dell'autenticazione SPF

L'analisi dei risultati dell'autenticazione SPF nel corso del tempo aiuta i team a individuare eventuali scostamenti, mittenti mancanti e configurazioni errate prima che si trasformino in problemi più ampi di deliverability, soprattutto se supportata da uno strumento di reportistica DMARC. Un'attività regolare di verifica degli SPF consente inoltre di individuare più facilmente i casi ricorrenti di non conformità degli SPF prima che si trasformino in problemi più gravi relativi all'autorizzazione dei mittenti.

Abbinare SPF a DMARC

Il solo SPF non è sufficiente. DMARC garantisce l'allineamento e l'applicazione delle politiche, il che rende SPF più efficace negli ambienti di produzione in cui la resistenza allo spoofing è fondamentale. Queste best practice aiutano le organizzazioni a utilizzare l'SPF nell'ambito di una strategia di autenticazione più solida e completa.

Perché il fattore di protezione solare (SPF) potrebbe non essere sufficiente

SPF è utile, ma da solo non risolve tutti i problemi relativi all'autenticazione delle e-mail. I principali limiti indicati di seguito spiegano perché tale approccio dia i migliori risultati se inserito in una strategia più ampia.

L'inoltro può comunque compromettere l'SPF

Uno dei limiti principali è l'inoltro. Un messaggio inoltrato può comunque essere legittimo, ma il controllo SPF potrebbe fallire poiché l’indirizzo IP del server di inoltro non è autorizzato nel record SPF del dominio originale. Se il record TXT DNS pertinente non tiene conto di tale percorso, l’inoltro può comunque compromettere la validità dell’SPF anche quando la fonte originale del messaggio era legittima.

SPF non verifica la validità dell'indirizzo "Da" visibile

SPF verifica l'IP mittente rispetto al dominio "envelope-from", che non sempre corrisponde all'indirizzo "Da" visibile all'utente. Ciò significa che l’SPF, da solo, non risolve completamente le problematiche relative all’identità del mittente e all’allineamento.

SPF funziona al meglio in combinazione con DKIM e DMARC

Ecco perché l’SPF dovrebbe essere considerato come uno dei livelli di una strategia più ampia di autenticazione e di conformità allo standard PCI DSS. DKIM aggiunge una firma crittografica, mentre DMARC introduce regole di allineamento e garantisce l'applicazione delle politiche, contribuendo così a ridurre il rischio di configurazioni errate di DMARC. Nel loro insieme, queste misure di protezione garantiscono una tutela maggiore rispetto a quella che può offrire il solo SPF.

Scegliere la modalità di guasto SPF più adeguata con maggiore sicurezza

La differenza tra un "hard fail" e un "soft fail" nell'ambito dell'SPF dipende dall'intento della politica, dall'affidabilità del mittente e dalla tolleranza al rischio. Un errore non grave indica probabilmente la presenza di posta non autorizzata ed è spesso utile durante le operazioni di pulizia e individuazione. Un errore grave indica inequivocabilmente la presenza di posta non autorizzata e risulta più appropriato una volta che la copertura SPF è completa e rigorosamente controllata.

L'approccio più efficace consiste nel rafforzare la fiducia nella copertura SPF prima di passare al "hard fail", per poi integrare tale politica con DKIM e DMARC al fine di garantire un maggiore allineamento e una protezione più solida. Per le organizzazioni che necessitano di una maggiore visibilità su SPF, DKIM e DMARC in tutte le fonti di invio, Mimecast può contribuire a ridurre gli errori di configurazione e a rafforzare la protezione nell’intero ambiente di posta elettronica.