SPF Softfail vs SPF Hardfail: Qual è la differenza?
di
Tempo di lettura: 5 min
Con SPF (Sender Policy Framework), è possibile configurare il sistema in modo che risponda ai fallimenti dell'autenticazione in due modi: Hardfail o SoftfailIn questo blog discuteremo le differenze tra SPF hardfail e softfail, la sintassi per configurarli entrambi e i loro casi d'uso. Quindi, tuffiamoci nel vivo!
I punti chiave da prendere in considerazione
- L'SPF hardfail indica che il mittente di un'e-mail non è autorizzato e spesso comporta il rifiuto dell'e-mail.
- L'SPF softfail suggerisce che l'e-mail potrebbe ancora provenire da un mittente non autorizzato, ma non la rifiuta del tutto, consentendo un'ulteriore verifica.
- L'implementazione di politiche SPF rigorose è essenziale per evitare l'impersonificazione di e-mail non autorizzate e proteggere la reputazione del marchio.
- La combinazione di SPF e DMARC aggiunge un livello essenziale di sicurezza, consentendo una migliore gestione dei fallimenti di autenticazione delle e-mail.
- Il monitoraggio regolare dei risultati dell'autenticazione SPF può aiutare a mantenere una postura di sicurezza ottimale per le e-mail e a prevenire potenziali vulnerabilità.
La differenza tra SPF Softfail e Hardfail
La tabella seguente spiega la differenza fondamentale tra SPF hardfail e softfail.
| Sintassi SPF | Tipo di fallimento | Stato | Azione corrispondente del destinatario |
|---|---|---|---|
| v=spf1 include:domain1.com -all | Hardfail | Mittente non autorizzato | L'e-mail può essere rifiutata |
| v=spf1 include:domain1.com ~all | Softfail | Il mittente potrebbe essere non autorizzato | L'e-mail viene consegnata ma viene contrassegnata come sospetta o potenzialmente fraudolenta. |
SPF Hardfail vs Softfail : Come definito nella RFC
Secondo RFC 7208:
- Un risultato "Fail" per SPF indica direttamente che il mittente dell'e-mail non è autorizzato dal dominio di invio. "Fail" è sinonimo di risultato Hardfail (-all), che indica chiaramente l'utilizzo di un dominio non autorizzato.
- Tuttavia, un approccio molto più rilassato consiste nel configurare SPF Softfail, che indica una "probabile" indicazione di utilizzo non autorizzato del dominio.
Semplificate l'SPF con PowerDMARC!
Gestione dei guasti del destinatario per Hardfail e Softfail
Nella sezione 8.4la RFC definisce i seguenti scenari di gestione dei risultati per SPF hardfail e SPF softfail:
1. SPF Hardfail / Fail
Per il risultato "Fail" o hardfail, il server del destinatario può scegliere di rifiutare l'e-mail non autorizzata. Se si tratta di una transazione SMTP, dovrebbe essere restituito un codice di errore 550 5.7.1 con una descrizione appropriata dell'errore.
Se il server del destinatario non rifiuta l'e-mail durante la transazione SMTP, la RFC raccomanda ai ricevitori di registrare i risultati SPF nell'intestazione Received-SPF o Authentication-Results.
2. SPF Softfail
Come politica più flessibile, Softfail indica che il dominio di gestione amministrativa sospetta che l'e-mail non sia autorizzata, ma non vuole rifiutarla del tutto. In questo caso, il messaggio viene consegnato, ma con un avviso per un'ulteriore revisione.
SPF Softfail Vs Hardfail: Cosa consigliamo?
Nel caso del relaying di e-mail SMTP, si può considerare l'SPF softfail come una scommessa più sicura rispetto all'hardfail. Scopriamo come:
Il relaying delle e-mail SMTP è il trasferimento automatico di messaggi da un server a un altro. Ciò significa che l'e-mail viene consegnata a un server il cui indirizzo IP non è elencato nel record SPF del vostro dominio. Ciò lo rende un mittente non autorizzato per le vostre e-mail, anche se, in pratica, è legittimo.
Avete qualche controllo su questa attività? La risposta è no, poiché l'e-mail viene inoltrata automaticamente dal destinatario. In queste circostanze, l'SPF fallirà per le e-mail inoltrate.
Ecco dove una politica SPF hardfail può mettervi nei guai! Come già sappiamo, i meccanismi di hardfail possono portare al rifiuto dei messaggi falliti. Pertanto, le e-mail inoltrate potrebbero non essere consegnate se il vostro dominio è configurato con un criterio hardfail.
La parte peggiore? L'azione intrapresa dal criterio di gestione dei fallimenti SPF annulla i risultati dell'autenticazione DMARC e DKIM. In sostanza, anche se DKIM e successivamente DMARC passano, l'e-mail potrebbe non essere consegnata.
Come specificato in RFC 7489 Sezione 10.1 se i controlli SPF vengono eseguiti prima delle operazioni DMARC, la presenza di un prefisso "-" nel meccanismo SPF di un mittente, come "-all", potrebbe portare al rifiuto immediato delle e-mail. Questo rifiuto avviene nelle prime fasi del processo di gestione delle e-mail, anche prima di qualsiasi elaborazione DMARC.
Pertanto, se il criterio SPF di un mittente di e-mail include un meccanismo "-all", che indica una politica rigorosa di rifiuto delle e-mail che non superano i controlli SPF, potrebbe comportare il rifiuto del messaggio prima che si verifichi qualsiasi criterio o elaborazione DMARC. Questo rifiuto precoce può avvenire indipendentemente dal fatto che l'e-mail superi l'autenticazione DMARC.
Pertanto, in queste circostanze, SPF Softfail trionfa sul meccanismo Hardfail. Si tratta di un approccio a rischio notevolmente basso che lascia spazio alla revisione semplicemente segnalando le e-mail autorizzate invece di rifiutarle.
Come funzionano i record SPF?
Per implementare l'SPF per le vostre e-mail, dovete creare e pubblicare un record SPF sul DNS del vostro dominio. Un tipico esempio di record SPF è il seguente:
v=spf1 include:_spf.google.com ~all
In questo record SPF, si autorizzano tutte le e-mail provenienti dagli indirizzi IP elencati nel record SPF di Google. Il meccanismo di fallimento è definito alla fine del record (~all), cioè Softfail.
Pertanto, un record SPF definisce la versione del protocollo utilizzata, le fonti di invio autorizzate e il meccanismo di fallimento. Quando si pubblica questo record sul proprio DNS, si garantisce che solo i mittenti autorizzati possano inviare e-mail a nome del proprio dominio. Se una fonte non autorizzata tenta di impersonare l'utente, l'SPF fallisce con il tipo di meccanismo di fallimento definito nel record.
Strategie di implementazione SPF sicure
L'implementazione ottimale dell'SPF è essenziale per salvaguardare le comunicazioni e-mail dagli attacchi di spoofing e phishing non autorizzati. Seguendo le best practice, le organizzazioni possono migliorare la propria posizione di sicurezza delle e-mail e proteggere la reputazione del proprio marchio. Ecco alcune strategie e linee guida per implementare l'SPF in modo sicuro:
1. Utilizzare uno strumento per la generazione di record SPF
Il processo di implementazione dell'SPF inizia con la generazione del record. È possibile creare il record manualmente, conoscendo bene i tag SPF. Questo metodo è tuttavia soggetto a errori umani. L'ideale è utilizzare il nostro generatore automatico generatore SPF che vi aiuta a creare un record SPF senza errori. Questo vi aiuta a creare un record SPF accurato e privo di errori, personalizzato per le esigenze della vostra organizzazione.
2. Utilizzare meccanismi SPF appropriati
Utilizzate i meccanismi SPF come "include", "a" e "IP4" per specificare le fonti di invio consentite. La scelta dei meccanismi deve essere oculata e basata sulla vostra infrastruttura di posta elettronica, in modo da garantire che riflettano accuratamente le vostre pratiche di invio delle e-mail.
3. Mantenere e ottimizzare il record SPF
Il record Sender Policy Framework deve essere mantenuto e ottimizzato per evitarne il malfunzionamento. L'SPF tende a rompersi quando i mittenti autorizzati superano il limite di 10 ricerche DNS sul lato del destinatario. Per mantenere un limite di ricerche ottimale, il nostro soluzione SPF in hosting è la soluzione migliore! Aiutiamo i proprietari di domini a ottimizzare l'SPF con un solo clic, per rimanere al di sotto dei limiti di ricerca e di annullamento e mantenere l'SPF senza errori.
4. Combinare SPF e DMARC
Distribuzione DMARC (Domain-based Message Authentication, Reporting, and Conformance) accanto a SPF fornisce un ulteriore (ma essenziale) livello di sicurezza. Il DMARC consente ai proprietari dei domini di specificare le politiche di gestione delle e-mail, compresa l'azione da intraprendere per le e-mail che non superano l'SPF.
Il DMARC ha dato risultati comprovati nel ridurre al minimo gli attacchi di frode, compromissione e impersonificazione delle e-mail.
5. Implementare politiche rigorose di gestione dei fallimenti SPF
Configurare il record per trattare i fallimenti dell'autenticazione SPF con criteri rigidi, come il rifiuto o il contrassegno delle e-mail provenienti da domini con errori. A tal fine, è possibile implementare SPF hardfail o SPF softfail invece di una politica neutrale.
6. Monitorare i risultati dell'autenticazione SPF
Attuare Rapporti DMARC per monitorare i risultati dell'autenticazione SPF, come SPF pass e fail, nonché gli errori di allineamento. A analizzatore DMARC può aiutarvi ad analizzare i dati di autenticazione SPF in modo organizzato e leggibile.
Parole finali
Non esiste una risposta diretta alla domanda "Quale è meglio? SPF hardfail o softfail". Sebbene il tag hardfail possa garantire una maggiore sicurezza, la scelta della soluzione corretta per il monitoraggio delle fonti di invio diventa fondamentale.
La piattaforma avanzata di PowerDMARC per l 'autenticazione dei domini e la reportistica fornisce soluzioni SPF e DMARC complete per aziende di tutte le dimensioni. Iscrivetevi oggi stesso per una prova gratuita!
Esperto di sicurezza dei domini e delle e-mail presso PowerDMARC
Yunes è un Operations Team Lead di PowerDMARC, esperto di autenticazione e sicurezza delle e-mail. Yunes è un Azure Administrator Associate certificato da Microsoft con certificazioni in CompTIA A+ e molte altre.
Ultimi messaggi di Yunes Tarada (vedi tutti)
- Spiegazione del meccanismo neutro dell'SPF: Quando e come usarlo - 23 giugno 2025
- Errori di allineamento dei domini DKIM - Correzioni RFC 5322 - 5 giugno 2025
- DMARCbis spiegato: cosa sta cambiando e come prepararsi - 19 maggio 2025
