Scopri la differenza tra SPF Softfail e Hardfail, le migliori pratiche e come proteggere la tua posta elettronica aziendale con PowerDMARC. Guida completa per responsabili IT e amministratori di posta elettronica.
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 sicurezza ottimale delle e-mail. sicurezza della posta elettronica e prevenire potenziali vulnerabilità.
Con SPF (Sender Policy Framework), hai la possibilità di configurare il tuo sistema in modo che risponda agli errori di autenticazione in uno dei due modi seguenti: Hardfail o Softfail. In questo blog, i nostri esperti di PowerDMARC vi illustreranno le differenze tra SPF hardfail e softfail, come configurarli e alcuni casi d'uso reali per i team IT e di sicurezza. Quindi, tuffiamoci subito nell'argomento!
Che cos'è un errore SPF?
Prima di approfondire le differenze tra hard fail e soft fail, è fondamentale comprendere cosa costituisce un errore SPF e come funziona l'autenticazione SPF.
SPF (Sender Policy Framework) è un protocollo di autenticazione e-mail che consente ai proprietari di domini di specificare quali indirizzi IP sono autorizzati a inviare e-mail per conto del proprio dominio. Quando viene ricevuta un'e-mail, il server ricevente controlla l'indirizzo IP del mittente rispetto al record SPF del dominio per determinare se il mittente è autorizzato.
Il controllo SPF viene eseguito sul dominio del percorso di ritorno, che rappresenta l'identità specificata da autenticare. È fondamentale che il record SPF sia pubblicato correttamente per garantire un'autenticazione SPF adeguata ed evitare problemi di consegna delle e-mail.
Risultati dell'autenticazione SPF
- Pass: l'IP del mittente è autorizzato nel record SPF.
- Fallimento (Hard Fail): l'IP del mittente non è esplicitamente autorizzato (-all)
- Errore soft: l'IP del mittente probabilmente non è autorizzato (~tutti)
- Neutrale: nessuna dichiarazione politica sul mittente (?tutti)
- Nessuno: non esiste alcun record SPF per il dominio
- TempError: Errore temporaneo nella ricerca DNS
- PermError: Errore permanente nella sintassi del record SPF
Ogni risultato SPF è una dichiarazione esplicita sullo stato di autorizzazione del mittente. Un "fail" è una dichiarazione esplicita forte che indica che il mittente non è autorizzato, mentre un "softfail" è una dichiarazione debole che indica una probabile ma non definitiva mancanza di autorizzazione.
Un errore SPF si verifica quando il controllo di autenticazione restituisce un risultato "Fail" o "Soft Fail", indicando che il server di invio potrebbe non essere autorizzato a inviare e-mail per quel dominio.
SPF Hard Fail vs Soft Fail: spiegazione delle differenze principali
La tabella seguente spiega la differenza fondamentale tra SPF hardfail e softfail.
| Sintassi SPF | Tipo di fallimento | Stato | Azione corrispondente del destinatario | Caso d'uso tipico |
|---|---|---|---|---|
| v=spf1 include:domain1.com -all | Hardfail | Mittente non autorizzato | L'e-mail può essere rifiutata | Domini di produzione con sicurezza rigorosa |
| 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. | Fase di test o configurazioni e-mail complesse |
Nota: Il meccanismo hardfail ("-all") è progettato per fornire la massima protezione contro il phishing e le e-mail contraffatte, causando il rifiuto dei messaggi provenienti da mittenti non autorizzati. Tuttavia, una configurazione errata può comportare l'impossibilità di recapitare le e-mail e un tasso di rimbalzo del 100% per le fonti non autorizzate.
Nella sintassi dei record SPF, solo gli indirizzi IP specificati nel record SPF sono autorizzati a inviare e-mail per conto del dominio. Tutte le altre fonti sono considerate mittenti non autorizzati e possono essere bloccate o contrassegnate come sospette, a seconda del tipo di errore.
SPF Hardfail contro 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, è possibile adottare un approccio molto più flessibile configurazione di SPF Softfail, che indica un "probabile" uso non autorizzato del dominio.
Gestione dei guasti del destinatario per Hardfail e Softfail
Nella sezione 8.4, l'RFC definisce i seguenti scenari di gestione dei risultati per i risultati SPF hardfail rispetto a quelli 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.
Quale modalità di errore SPF dovresti utilizzare?
La maggior parte dei domini, compresi quelli delle principali organizzazioni e aziende tecnologiche, utilizza una combinazione di politiche SPF in base alle proprie esigenze specifiche e alle proprie pratiche di posta elettronica. La scelta tra SPF hard fail e soft fail dipende dall'infrastruttura di posta elettronica della vostra organizzazione, dai requisiti di sicurezza e dalla tolleranza al rischio. Ecco un quadro decisionale per aiutarvi a scegliere:
Scegliere SPF Hard Fail (-all) quando:
- Hai il controllo completo su tutte le fonti di invio delle e-mail
- La tua infrastruttura di posta elettronica è matura e ben documentata
- La sicurezza è la priorità assoluta rispetto alla deliverability
- Utilizzi raramente servizi di posta elettronica di terze parti
- Hai implementato un monitoraggio DMARC completo
Scegli SPF Soft Fail (~tutti) Quando:
- Stai implementando SPF per la prima volta
- Utilizzi più servizi di posta elettronica di terze parti
- La deliverability delle e-mail è fondamentale per le operazioni aziendali
- Hai configurazioni complesse di inoltro o trasmissione delle e-mail
- Stai ancora identificando tutte le fonti di posta elettronica legittime
Casi d'uso comuni per SPF Hard Fail e Soft Fail
Casi d'uso di SPF Hard Fail:
- Istituzioni finanziarie: Banche e cooperative di credito che richiedono un'autenticazione rigorosa delle e-mail
- Agenzie governative: Organizzazioni con elevati requisiti di sicurezza
- Domini per la protezione del marchio: Domini utilizzati esclusivamente per la protezione del marchio
- Domini e-mail transazionali: Domini dedicati per email automatizzate
Casi d'uso di SPF Soft Fail:
- Domini di marketing: Domini che utilizzano più piattaforme di email marketing
- Aziende SaaS: Organizzazioni con infrastrutture di posta elettronica complesse
- Istituzioni scolastiche: Università con più dipartimenti e sistemi di posta elettronica
- Ambienti di test: Domini in fase di implementazione SPF
Scenario reale: se sei un responsabile IT che supervisiona la sicurezza della posta elettronica per un'azienda SaaS di medie dimensioni che utilizza Google Workspace, Salesforce e Mailchimp, potresti iniziare con un soft fail per garantire che tutte le e-mail legittime vengano consegnate mentre monitori e perfezioni il tuo record SPF.
Quando è opportuno utilizzare SPF Hard Fail o Soft Fail?
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 dall' politica di gestione dei fallimenti SPF prevaricherà risultati dell'autenticazione DMARC e DKIM . In sostanza, anche se DKIM e successivamente DMARC vengono superati, l'e-mail potrebbe comunque non essere recapitata.
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 la politica 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, ciò potrebbe comportare il rifiuto del messaggio prima che vengano applicate le politiche DMARC o che avvenga qualsiasi elaborazione. Questo rifiuto anticipato può verificarsi indipendentemente dal fatto che l'e-mail possa eventualmente superare l'autenticazione DMARC.
Pertanto, in queste circostanze, il meccanismo SPF Soft fail prevale su quello Hard fail. Si tratta di un approccio a rischio notevolmente basso che lascia spazio alla revisione, semplicemente contrassegnando le e-mail autorizzate invece di rifiutarle.
Vulnerabilità di bypass e inoltro SPF
Comprendere le potenziali vulnerabilità nell'implementazione dell'SPF è fondamentale per mantenere una solida sicurezza della posta elettronica:
Scenari comuni di bypass dell'SPF:
- Inoltro delle e-mail: le e-mail legittime inoltrate tramite servizi di terze parti potrebbero non superare il controllo SPF.
- Server di mailing list: i messaggi inviati tramite mailing list spesso modificano l'IP del mittente.
- Servizi di posta elettronica cloud: gli intervalli IP dinamici nei servizi cloud possono causare errori SPF
- Client di posta elettronica mobili: e-mail inviate da dispositivi mobili attraverso reti diverse
Migliori pratiche di mitigazione:
- Implementare DKIM insieme a SPF per un'autenticazione aggiuntiva
- Utilizza DMARC per gestire con eleganza gli errori SPF
- Controllare e aggiornare regolarmente i record SPF
- Monitorare i rapporti di autenticazione delle e-mail per individuare eventuali anomalie
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 proteggere la comunicazione e-mail da spoofing e phishing . Seguendo le migliori pratiche, le organizzazioni possono migliorare la loro sicurezza e-mail e proteggere la reputazione del proprio marchio. Ecco alcune strategie e linee guida per implementare 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 SPF (Sender Policy Framework) deve essere mantenuto e ottimizzato per evitare malfunzionamenti. L'SPF tende a non funzionare correttamente quando i mittenti autorizzati superano il limite di 10 ricerche DNS sul lato del destinatario. Per mantenere un limite di ricerca ottimale, il nostro soluzione SPF è la soluzione migliore! Aiutiamo i proprietari di domini a ottimizzare SPF con un solo clic, per rimanere al di sotto dei limiti di ricerca e di invalidità e mantenere SPF privo di 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.
Autenticazione avanzata del dominio di PowerDMARC autenticazione del dominio e la piattaforma di reporting di PowerDMARC forniscono soluzioni SPF e DMARC per aziende di tutte le dimensioni.
Prova la piattaforma certificata SOC2 scelta da migliaia di organizzazioni in tutto il mondo. Inizia oggi stesso la tua prova gratuita oggi stesso!
Domande frequenti
1. Qual è il motivo del soft fail dell'SPF?
Il soft fail SPF si verifica quando un'e-mail viene inviata da un indirizzo IP che non è esplicitamente autorizzato nel record SPF del dominio, ma il proprietario del dominio ha configurato un meccanismo "~all" invece di "-all". Ciò indica che il mittente "probabilmente non è autorizzato", ma consente comunque la consegna dell'e-mail con un flag di avviso invece che il suo rifiuto immediato.
2. Che cos'è un errore irreversibile 550 5.7.0 SPF?
L'errore "550 5.7.0 SPF hard fail" si verifica quando un server di posta elettronica rifiuta un messaggio perché l'indirizzo IP del mittente non è autorizzato nel record SPF del dominio che termina con "-all". Si tratta di un errore permanente che impedisce la consegna dell'e-mail e indica che il server di ricezione applica politiche di applicazione SPF rigorose.
3. Quando si verifica un errore irreversibile SPF?
Si ottiene un errore SPF hard fail quando: 1) L'IP mittente non è elencato nel record SPF del dominio, 2) Il record SPF termina con "-all" (politica hard fail), 3) L'e-mail viene inviata da un server o servizio non autorizzato, 4) Sono presenti errori di configurazione nel record SPF, oppure 5) Il dominio ha implementato politiche di autenticazione e-mail rigorose.
4. Che cos'è il simbolo di errore irreversibile in SPF?
Il simbolo di errore grave in SPF è il segno meno "-" seguito da "all" (scritto come "-all"). Questo meccanismo indica ai server di posta elettronica riceventi di rifiutare qualsiasi e-mail che non corrisponda agli indirizzi IP o ai domini autorizzati elencati nel record SPF. Si tratta della politica SPF più rigorosa e fornisce il massimo livello di sicurezza nell'autenticazione delle e-mail.
5. È opportuno utilizzare SPF hard fail o soft fail per la mia attività?
Per la maggior parte delle aziende, è consigliabile iniziare con SPF soft fail (~all) durante le fasi di implementazione e test per evitare di bloccare le e-mail legittime. Una volta identificate tutte le fonti di invio autorizzate e dopo aver effettuato test approfonditi, è possibile passare a hard fail (-all) per ottenere la massima sicurezza. Le organizzazioni con infrastrutture di posta elettronica complesse o servizi di terze parti devono valutare attentamente il rischio di blocco delle e-mail legittime prima di implementare un hard fail.
- Il formato del numero di serie SOA non è valido: cause e soluzioni - 13 aprile 2026
- Come inviare email sicure su Gmail: guida passo passo - 7 aprile 2026
- Come inviare e-mail sicure in Outlook: guida passo passo - 2 aprile 2026
