Guida Red Sift alla configurazione dei protocolli email

Un fallimento SPF si verifica quando l'indirizzo IP del mittente non è presente nel record SPF pubblicato. I fallimenti influenzano significativamente la consegnabilità delle tue email poiché comportano che l'email venga inviata nello spam o addirittura eliminata. Questo può essere catastrofico per le aziende che si affidano alle email per raggiungere i clienti. Con i principali fornitori di caselle di posta che dal 2026 richiederanno l'autenticazione obbligatoria, i fallimenti SPF avranno conseguenze dirette sulla consegna delle email.

Esistono due tipi di fallimenti SPF: softfail SPF e hardfail SPF. Un hardfail indica che una email non è autorizzata, mentre un softfail significa che una email probabilmente non è stata autorizzata. Per il destinatario dell'email, ciò determina il trattamento della stessa; un hardfail indica al destinatario di rifiutare l'email, mentre un softfail suggerisce che debba essere indirizzata nello spam.

Utilizzeremo due esempi per mostrare visivamente la differenza tra le due modalità.

v=spf1 ip4:192.168.0.1 -all

Nell'esempio sopra, il simbolo meno (davanti a all alla fine del record) significa che qualsiasi mittente non incluso in questo record SPF deve essere trattato come hardfail, cioè non è autorizzato, e le email inviate da loro dovrebbero essere eliminate. In questo caso, solo l'indirizzo IP 192.168.0.1 è autorizzato a inviare email e nessun altro.

v=spf1 include:spf.protection.outlook.com ~all

Nell’esempio sopra, il simbolo tilde (davanti a all alla fine del record) significa che qualsiasi mittente non incluso in questo record SPF deve essere trattato come softfail, cioè la posta può essere consegnata ma dovrebbe essere contrassegnata come spam o sospetta. In questo caso, il meccanismo include:spf.protection.outook.com autorizza Microsoft 365 a inviare email. Qualsiasi email proveniente da server diversi dovrebbe essere marcata come spam dai destinatari.

Non sei sicuro della configurazione SPF? Usa il nostro verificatore gratuito per iniziare.

Dal momento che l’hardfail (“-all”) indica di rifiutare tutti i mittenti non autorizzati presenti nel record SPF, potrebbe sembrare la scelta migliore. Tuttavia, la decisione è più sfumata.

Nell’era pre-DMARC, i record SPF utilizzavano comunemente il meccanismo “-all” per applicare rigorosamente le politiche dei mittenti, senza il livello aggiuntivo di DKIM e DMARC per aiutare ad autenticare le email legittime.

Tuttavia, le attuali linee guida del settore nel 2026 privilegiano “~all” per bilanciare sicurezza e deliverability, evitando rifiuti non necessari di email valide che potrebbero fallire SPF ma superare DKIM e DMARC.

Anche l’industria sottolinea che serve attenzione nell’uso delle modalità SPF; la specifica DMARC (RFC 7489) dichiara che:

“Alcune architetture dei destinatari potrebbero implementare SPF prima di qualsiasi operazione DMARC. Questo significa che un prefisso "-" sul meccanismo SPF del mittente, come in "-all", potrebbe far scattare il rifiuto già nelle prime fasi di gestione, causando il rifiuto del messaggio prima di qualsiasi processo DMARC. Gli operatori che scelgono di utilizzare "-all" devono esserne consapevoli.”

Per questi motivi, suggeriamo quanto segue:

• Utilizza "-all" per domini inattivi, che non inviano email: Applica "-all" solo se il dominio non invia mai email. Questa impostazione blocca rigorosamente le email non autorizzate ma rischia di rifiutare anche quelle legittime se il record SPF non è aggiornato.
• Utilizza "~all" per domini attivi che inviano email: Scegli "~all" se usi SPF in combinazione con DKIM e DMARC per contrastare phishing e spoofing. Questo perché “~all” - quando implementato insieme a DMARC (a p=reject) - respingerà comunque le email non autenticate se falliscono sia SPF sia DKIM. Questa modalità non blocca la posta legittima, migliorando così la deliverability generale.

In sintesi, il softfail rappresenta un equilibrio tra sicurezza rigorosa (che potrebbe bloccare email legittime) e una maggiore flessibilità nella consegna delle email, garantendo che la posta possa comunque essere consegnata anche in caso di non corrispondenze occasionali nel record SPF.

È possibile che alcune società di rating ti penalizzino se i tuoi domini sono configurati con softfail SPF. Tuttavia, riteniamo che declassare il punteggio di sicurezza di un dominio basandosi sulla presenza di un softfail possa rappresentare erroneamente il reale profilo di rischio del dominio e penalizzare involontariamente le organizzazioni che seguono le pratiche raccomandate dal settore per una gestione e una sicurezza email responsabili. Nel 2026, una corretta implementazione DMARC a p=reject offre lo strato di enforcement che risolve qualunque problema di softfail SPF.

D’altra parte, servizi di rating come Security Scorecard riconoscono che DMARC (quando è impostato su quarantena o reject) rappresenta un controllo “compensativo” per il softfail SPF.

Se ricevi una penalizzazione per aver implementato il softfail SPF in un audit di sicurezza informatica, confrontati direttamente con la società di rating per spiegare la tua strategia di autenticazione email e il suo allineamento con le migliori pratiche del settore. Sostieni un approccio più articolato alla valutazione della postura di sicurezza, che consideri tutto il contesto delle tue misure di protezione email anziché penalizzare singole configurazioni in modo isolato.

Indipendentemente dalla modalità di fallimento che specifichi nel tuo record SPF, i server riceventi difficilmente rispetteranno la policy richiesta. Per questo motivo DMARC è diventato obbligatorio presso i principali provider di posta dal 2026. Questo perché SPF presenta delle limitazioni:

1. Non richiede l’allineamento tra il dominio presente nel campo From e l’indirizzo Return-Path che viene controllato. Da un punto di vista SPF non devono necessariamente combaciare.
2. SPF non offre funzionalità di reportistica, quindi il destinatario non restituisce report al mittente con i risultati dell’autenticazione email.
3. SPF non sopravvive all’auto-forwarding e ai flussi mail indiretti, causando potenziali problemi di autenticazione.

A causa di queste limitazioni, DMARC (Domain-based Message Authentication, Reporting, and Conformance) è stato introdotto come standard aggiuntivo di autenticazione email. DMARC supera le carenze dello SPF e apporta i seguenti miglioramenti:

1. DMARC si concentra sull’intestazione visibile From, quella vista dagli utenti finali.
2. DMARC richiede l’allineamento tra il dominio utilizzato da SPF e quello visibile nel campo From dell’email.
3. DMARC ignora le sfumature tra soft fail e hard fail nella configurazione SPF, trattandoli entrambi come fallimenti SPF.
4. DMARC fornisce funzionalità di reportistica, consentendo ai risultati dell’autenticazione di essere restituiti al proprietario del dominio From. Questo aiuta a identificare l’abuso del dominio e risolvere eventuali errori di configurazione con i mittenti legittimi.
5. DMARC include una policy che istruisce i destinatari su come gestire le email che hanno fallito l’autenticazione, policy che viene effettivamente applicata. Al contrario, SPF da solo non prevede meccanismi di enforcement.

DMARC è ormai ampiamente adottato come requisito di autenticazione perché supera i limiti di SPF e DKIM, blocca l’impersonificazione esatta tramite email e migliora la deliverability generale. Dal 2026 DMARC è obbligatorio per tutti gli invii massivi di email tramite Google, Yahoo e Microsoft, consolidando il suo ruolo di standard di autenticazione email.