Guida Red Sift alla configurazione dei protocolli email
Fallimenti SPF: Hardfail vs Softfail
Cos'è un fallimento SPF?
Un fallimento SPF si verifica quando l'indirizzo IP del mittente non è presente nel record SPF pubblicato. I fallimenti hanno un impatto significativo sulla consegnabilità delle tue email, poiché comportano che l'email venga inviata nella posta indesiderata o addirittura scartata. Questo può essere catastrofico per le aziende che fanno affidamento sull'email per raggiungere i clienti. Con i principali provider di caselle di posta che introdurranno requisiti di autenticazione nel 2026, i fallimenti SPF hanno conseguenze dirette sulla consegnabilità.
Esistono due tipi di fallimenti SPF: softfail SPF e hardfail SPF. Un hardfail indica che un'email non è autorizzata, mentre un softfail significa che un'email probabilmente non è stata autorizzata. Per il destinatario dell'email, questo determina il trattamento dell'email; un hardfail dice al destinatario di rifiutare l'email, mentre un softfail suggerisce che dovrebbe essere indirizzata nello spam.
Utilizzeremo due esempi per mostrare la differenza visiva tra i due.
Esempio di hardfail SPF
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 elencato in questo record SPF deve essere considerato un hardfail, cioè non autorizzato, e le email provenienti da essi dovrebbero essere scartate. In questo caso, solo l'indirizzo IP 192.168.0.1 è autorizzato a inviare email e nessun altro.
Esempio di softfail SPF
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 elencato in questo record SPF deve essere considerato un softfail, cioè la posta può essere lasciata passare ma deve essere contrassegnata come spam o sospetta. In questo caso, il meccanismo include:spf.protection.outook.com autorizza Microsoft 365 all'invio di email. Tutte le email provenienti da server diversi dovrebbero essere contrassegnate come spam dai destinatari.
Non sei sicuro della configurazione del tuo SPF? Utilizza il nostro verificatore gratuito per iniziare.
Quale modalità di fallimento SPF dovresti usare?
Poiché l'hardfail ("-all") indica di rifiutare qualsiasi mittente non autorizzato non incluso nel record SPF, potrebbe sembrare la modalità preferibile. Tuttavia, la decisione è più sfumata.
Nel periodo precedente a DMARC, i record SPF utilizzavano frequentemente il meccanismo "-all" per applicare in modo rigoroso le politiche sui mittenti, senza lo strato aggiuntivo di DKIM e DMARC per aiutare ad autenticare le email legittime.
Tuttavia, le indicazioni attuali del settore (2026) preferiscono "~all" per bilanciare sicurezza e consegnabilità, evitando il rifiuto non necessario di email valide che potrebbero fallire SPF ma superare DKIM e DMARC.
L’industria raccomanda cautela con le modalità SPF; la specifica DMARC (RFC 7489) afferma che:
“Alcune architetture di ricezione possono implementare SPF prima di qualsiasi operazione DMARC. Questo significa che un prefisso "-" su un meccanismo SPF del mittente, come "-all", potrebbe far sì che tale rifiuto entri in vigore prematuramente, causando il rifiuto del messaggio prima che abbia luogo la verifica DMARC. Gli operatori che scelgono di usare "-all" devono esserne consapevoli.”
Per questi motivi, suggeriamo quanto segue:
- Usa "-all" per domini inattivi, che non inviano email: Applica "-all" solo se il dominio non invia alcuna email. Questa impostazione blocca rigorosamente le email non autorizzate, ma rischia di rifiutare anche email legittime se il record SPF non è aggiornato.
- Usa "~all" per domini attivi che inviano email: Scegli "~all" se utilizzi SPF in combinazione con DKIM e DMARC per combattere phishing e spoofing. Questo perché “~all”, quando implementato insieme a DMARC (con p=reject), respingerà comunque le email non autenticate se sia SPF che DKIM falliscono. Questa modalità non blocca la posta legittima, migliorando quindi la consegnabilità complessiva delle email.
In sintesi, il softfail trova un equilibrio tra sicurezza rigorosa (che potrebbe bloccare email legittime) e la flessibilità nella consegna, garantendo che le email possano essere comunque consegnate anche in caso di occasionali errori nel record SPF.
Come viene trattato il softfail SPF dalle aziende di rating di cybersecurity?
È possibile che alcune aziende di rating ti penalizzino se i tuoi domini sono impostati con softfail SPF. Tuttavia, riteniamo che penalizzare il punteggio di sicurezza di un dominio solo a causa della presenza di un softfail possa rappresentare in modo errato il reale profilo di rischio del dominio, penalizzando involontariamente organizzazioni che seguono le pratiche raccomandate dal settore per una gestione e sicurezza responsabile delle email. Nel 2026, una corretta implementazione di DMARC con p=reject fornisce lo strato di enforcement necessario a coprire eventuali preoccupazioni relative al softfail SPF.
D'altro canto, servizi di rating come Security Scorecard riconoscono che DMARC (se configurato con policy di quarantena o reject) è un controllo "compensativo" per il softfail SPF.
Se durante un audit di cybersecurity vieni penalizzato per aver implementato un softfail SPF, ti suggeriamo di interfacciarti direttamente con l'azienda di rating per spiegare la tua strategia di autenticazione email e il suo allineamento con le best practice di settore. Richiedi un approccio più articolato nella valutazione della postura di sicurezza, che consideri il contesto complessivo delle misure di sicurezza email adottate, invece di penalizzare singole configurazioni isolate.
Perché SPF non basta e hai comunque bisogno di DMARC
Indipendentemente dalla modalità di fallimento specificata nel tuo record SPF, i server di ricezione potrebbero non rispettare la policy che hai richiesto. Per questo motivo DMARC è diventato obbligatorio da parte dei principali provider di posta nel 2026. Questo perché SPF presenta le seguenti limitazioni:
- Non richiede l’allineamento tra il dominio nel campo From e l’indirizzo Return-Path che controlla. Dal punto di vista SPF, non devono combaciare.
- SPF non offre funzionalità di reporting: il ricevente non invia al mittente rapporti sugli esiti di autenticazione email.
- SPF non sopravvive ai reindirizzamenti automatici o ai flussi di posta indiretti, il che può causare problemi di autenticazione.
Per questi limiti, è stato introdotto DMARC (Domain-based Message Authentication, Reporting, and Conformance) come standard aggiuntivo di autenticazione email. DMARC risolve le carenze di SPF e offre questi miglioramenti:
- DMARC si concentra sull'intestazione From visibile agli utenti finali.
- DMARC richiede che il dominio usato da SPF sia allineato con quello mostrato nell’indirizzo From dell’email.
- DMARC ignora i dettagli delle modalità softfail e hardfail nella configurazione SPF, trattandole comunque come fallimenti SPF.
- DMARC implementa la funzione di reporting, che consente di inviare al proprietario del dominio From i risultati di autenticazione: questo aiuta a identificare abusi e correggere eventuali configurazioni sbagliate con mittenti legittimi.
- DMARC prevede una policy che dice ai riceventi come gestire le email che non superano l'autenticazione, e i riceventi applicano questa policy. Al contrario, SPF da solo non ha meccanismi di enforcement.
DMARC è ormai ampiamente adottato come requisito di autenticazione, poiché supera le limitazioni di SPF e DKIM, blocca le impersonificazioni esatte e migliora la consegnabilità delle email. Dal 2026, DMARC è obbligatorio per chi invia grandi volumi di email verso Google, Yahoo e Microsoft, affermandosi come standard definitivo di autenticazione email.
Controlla il tuo record SPF gratuitamente, senza bisogno di registrazione.
Domande frequenti: Guida alla configurazione dei protocolli email
Prima di DMARC, nei record SPF era spesso usato il meccanismo “-all” per applicare restrizioni rigorose alle policy dei mittenti. Tuttavia, le attuali raccomandazioni del settore per il 2026 privilegiano “~all” per bilanciare sicurezza e deliverability ed evitare il rifiuto non necessario di email legittime che falliscono SPF, ma superano DKIM e DMARC.
Il motivo è che “~all” in combinazione con DMARC (in p=reject) consente comunque di non recapitare email non autenticate quando SPF e DKIM falliscono, senza bloccare email legittime – migliorando così la deliverability complessiva.
Le specifiche DMARC (RFC 7489) affermano che un prefisso “-” nel meccanismo SPF del mittente – come “-all” – può comportare il rifiuto di un’email già nella fase iniziale, cioè prima che venga applicato DMARC. Utilizza “-all” solo per domini inattivi che non inviano mai email. DMARC non distingue tra Soft Fail e Hard Fail su SPF: considera entrambi semplicemente come un errore SPF.
DMARC richiede non solo che SPF o DKIM abbiano esito positivo, ma anche che almeno uno dei domini usati con SPF o DKIM corrisponda al dominio presente nell'intestazione From. Un corretto allineamento è fondamentale nel 2026 per la consegna delle email, perché i principali provider ora richiedono questa verifica.
Per SPF, l’allineamento significa che la verifica di MAIL FROM/Return-PATH è andata a buon fine e la parte dominio di MAIL FROM/Return-PATH coincide con il dominio dell’indirizzo From. In modalità Strict le due devono essere identiche; in modalità Relaxed vengono accettate anche le sottodomini se appartengono alla stessa organizational domain.
Esempio: se MAIL-FROM/RETURN-PATH è @ondmarc.com e il From-header è @knowledge.ondmarc.com, non sono allineati in modalità Strict, ma DMARC li considererebbe validi in modalità Relaxed.
Un report aggregato DMARC contiene informazioni sullo stato di autenticazione dei messaggi inviati per conto di un dominio. Si tratta di un bounce report in XML che riepiloga quali email hanno superato o fallito SPF e DKIM. Permette ai possessori di dominio di avere una panoramica precisa delle fonti che inviano email a loro nome e cosa succede (policy del destinatario).
I destinatari usano il tag 'rua' del record DMARC per inviare i report. Puoi definire la frequenza usando il tag ri nel record DMARC (valore predefinito: 86400 secondi, ovvero 24h). I report forensi forniscono dettagli molto più precisi su ogni fallimento di autenticazione. I dati personali vengono rimossi, ma tutte le informazioni utili alla risoluzione dei problemi, come header SPF/DKIM e indirizzo mittente completo e oggetto, sono trasmesse.
L’indirizzo di ricezione dei report forensi DMARC si indica tramite il tag 'ruf'. Non tutti i sistemi supportano questi report. Red Sift OnDMARC è tra le poche soluzioni che può ricevere report forensi – grazie alla partnership con Yahoo.
Una macro SPF è un meccanismo nei record SPF che consente di definire insiemi riutilizzabili di indirizzi IP. Le macro SPF offrono maggiore flessibilità e mantenibilità: puoi definire set complessi di IP in un unico meccanismo e referenziarli in vari record. Ad esempio, invece di elencare ogni IP autorizzato, puoi usare una macro come “%{i}”, che richiama l’IP in uscita dell’email. In questo modo puoi gestire facilmente grandi elenchi IP senza superare il limite di lookup SPF e rendere meno evidenti le autorizzazioni IP durante le interrogazioni DNS.
A seconda della struttura della macro nel record SPF, una mancata espansione della macro può causare errori SPF o un risultato neutro (?all). Se l’invio di email legittime dipende dalle macro SPF, queste ultime possono portare a maggiori fallimenti o a segnalare come sospetto il traffico verso sistemi che si basano su SPF.
Mail Transfer Agent Strict Transport Security (MTA-STS) è uno standard per la cifratura dei messaggi tra due server di posta. Comunica ai server mittenti che le email devono essere recapitate solo tramite connessione sicura, tramite Transport Layer Security (TLS), proteggendo così dai tentativi di intercettazione da parte dei criminali informatici.
L’adozione di MTA-STS è cresciuta rapidamente e nel 2026 la sicurezza dei trasporti sarà considerata essenziale per la protezione della posta in transito. Per attivare MTA-STS su un dominio ricevente, occorre dichiarare il supporto tramite DNS e rendere disponibile un file di policy sul proprio sito.
MTA-STS va attivato con cautela per non causare blocchi accidentalmente. Si consiglia di iniziare con la modalità Test: in questo modo, grazie ai rapporti TLS, puoi identificare e risolvere eventuali errori prima di passare alla modalità strict. Questo approccio graduale sarà probabilmente lo standard per la protezione della posta in transito nel 2026.
SMTP TLS Reporting (TLS-RPT), secondo RFC8460, serve a segnalare problemi di connettività TLS dai server MTA mittenti. Proprio come per DMARC, anche qui vengono inviati report via email al titolare del dominio quando problemi TLS ostacolano la consegna. I report contengono le policy MTA-STS rilevate, statistiche di traffico, connessioni fallite e motivi di errore.
Con la funzione MTA-STS in Red Sift OnDMARC non dovrai preoccuparti delle complesse implementazioni. Basta aggiungere gli MTA-STS Smart Record forniti da OnDMARC al proprio DNS e Red Sift si occuperà dell’hosting del file di policy, la gestione del certificato SSL e l’invio automatico di segnalazioni di violazione via report TLS. Nel 2026, l’MTA-STS in hosting è sempre più uno standard previsto nelle moderne piattaforme DMARC, rendendo più semplice l’integrazione della cifratura nei trasporti.
Secondo RFC 7671, DANE (DNS-based Authentication of Named Entities) è un nuovo standard Internet per la creazione di comunicazioni TLS tra client e server senza dipendere dalle autorità di certificazione (CA) tradizionali.
Nel modello attuale, qualsiasi CA può rilasciare un certificato per qualunque dominio. DANE adotta un altro approccio, sfruttando l’infrastruttura DNSSEC (Domain Name System Security Extensions) per associare in modo crittografico un nome di dominio a un certificato. DANE si basa sul protocollo DNSSEC esistente per garantire autenticità e integrità della ricezione.
DANE introduce inoltre un nuovo tipo di record DNS, TLSA, che segnala al client il supporto server a TLS. È raccomandato implementare sia MTA-STS sia DANE. DANE è d’obbligo per molti enti pubblici, in particolare in UE.
MTA-STS e DANE sono efficaci solo se anche il server mittente li supporta – molti implementano solo uno dei due. Attivare entrambi aumenta la sicurezza generale. Nel 2026 le organizzazioni adottano spesso MTA-STS prima, per massima compatibilità, e aggiungono DANE per livelli di sicurezza superiori quando richiesto.
La policy per le sottodomini permette agli amministratori di proteggere in modo differenziato diversi domini e sottodomini a seconda dello stadio di implementazione di DMARC. Ad esempio, se tutti i servizi di invio associati al dominio principale sono già protetti da SPF e DKIM, puoi impostare una policy DMARC p=reject sul dominio principale e p=none sulle sottodomini – o viceversa.
Se un servizio di invio non supporta DMARC (cioè non implementa SPF o DKIM) puoi assegnargli una sottodominio separata con una policy DMARC propria, senza compromettere la protezione dei domini restanti. Ciò consente di distribuire il traffico tra diverse sottodomini e proteggerle separatamente secondo le esigenze.