Guida Red Sift alla configurazione dei protocolli email
Errori SPF: Hard fail vs Soft fail
Che cos'è un errore SPF?
Un errore SPF si verifica quando l'indirizzo IP del mittente non è presente nel record SPF pubblicato. Gli errori incidono in modo significativo sulla consegna delle email, poiché fanno sì che il messaggio venga inviato nella posta indesiderata o eliminato del tutto. Questo può essere catastrofico per le aziende che si affidano all'email per raggiungere i clienti. Con i principali provider di posta elettronica che dal 2026 applicheranno requisiti di autenticazione obbligatori, gli errori SPF hanno conseguenze dirette sulla consegnabilità.
Esistono due tipi di errori SPF: SPF softfail e SPF hardfail. Un hardfail indica che un'email non è autorizzata, mentre un softfail segnala che un'email probabilmente non è stata autorizzata. Per il destinatario, questo determina il trattamento della mail; un hardfail richiede al destinatario di rifiutare l'email, mentre un softfail suggerisce di deviarla nello spam.
Useremo due esempi per mostrare visivamente la differenza tra le due modalità.
Esempio di SPF hardfail
v=spf1 ip4:192.168.0.1 -all
Nell'esempio sopra, il simbolo meno (davanti a all alla fine del record) significa che ogni mittente non presente in questo record SPF deve essere trattato come hardfail, ovvero non autorizzato, e quindi le email da questi mittenti devono essere scartate. In questo caso, solo l'indirizzo IP 192.168.0.1 è autorizzato a inviare email e nessun altro.
Esempio di SPF softfail
v=spf1 include:spf.protection.outlook.com ~all
Nell'esempio precedente, il simbolo tilde (davanti a all alla fine del record) significa che qualsiasi mittente non elencato in questo record SPF deve essere trattato come softfail, cioè la mail può essere consegnata ma deve 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 altri server dovrebbe essere marcata come spam dai destinatari.
Non sei sicuro della tua configurazione SPF? Usa il nostro verificatore gratuito per iniziare.
Quale modalità di errore SPF utilizzare?
Visto che l'hardfail ("-all") segnala di rifiutare qualsiasi mittente non autorizzato non presente nel record SPF, potrebbe sembrare la scelta migliore. Tuttavia, la decisione è più complessa.
Prima dell'introduzione di DMARC, i record SPF usavano comunemente il meccanismo "-all" per applicare rigorosamente le regole sui mittenti, senza il livello aggiuntivo di DKIM e DMARC per autenticare le email legittime.
Tuttavia, le attuali linee guida di settore per il 2026 consigliano di preferire "~all" per bilanciare sicurezza e consegnabilità, evitando il rifiuto di email valide che potrebbero fallire SPF ma superare DKIM e DMARC.
Anche il settore riconosce che occorre attenzione con le modalità SPF; la specifica DMARC (RFC 7489) afferma che:
“Alcune architetture di ricezione potrebbero implementare SPF prima di qualsiasi operazione DMARC. Questo significa che un prefisso "-" su un meccanismo SPF sender, come "-all", potrebbe fare sì che il rifiuto venga applicato anticipatamente nella gestione, portando al rifiuto del messaggio prima che venga eseguita l'elaborazione 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 mai email. Questa impostazione blocca rigorosamente tutte le email non autorizzate ma rischia di respingere anche email legittime se il record SPF non è aggiornato.
- Usa "~all" per domini attivi che inviano email: Scegli "~all" se usi SPF insieme a DKIM e DMARC per contrastare phishing e spoofing. Questo perché “~all”, quando è implementato insieme a DMARC (a p=reject), comunque respinge le email non autenticate se SPF e DKIM falliscono. Questa modalità non blocca mail legittime, migliorando così la consegnabilità totale delle email.
In sintesi, il softfail trova un equilibrio tra la massima sicurezza (che potrebbe bloccare email valide) e una maggiore flessibilità nella consegna della posta, assicurando che le email vengano recapitate anche in caso di incroci occasionali errati nel record SPF.
Come viene trattato il softfail SPF dalle società di rating della cybersecurity?
È possibile che alcune società di rating penalizzino i domini configurati con softfail SPF. Tuttavia, riteniamo che abbassare il punteggio di sicurezza di un dominio a causa della presenza di un softfail possa distorcere la reale valutazione del rischio e penalizzare involontariamente le organizzazioni che seguono le best practice consigliate dal settore per una buona gestione e sicurezza dell'email. Nel 2026, un'implementazione DMARC corretta con p=reject fornisce lo strato di enforcement che risponde a qualsiasi preoccupazione relativa al softfail SPF.
D'altra parte, servizi di rating come Security Scorecard riconoscono che DMARC (quando impostato con policy di quarantine o reject) è un controllo “compensativo” per il softfail SPF.
Se in un audit di sicurezza informatica ti viene penalizzato l'uso del softfail SPF, rivolgiti direttamente alla società di rating per spiegare la tua strategia di autenticazione email e la sua adesione alle migliori pratiche del settore. Sostieni un approccio più articolato alle valutazioni della sicurezza, che consideri il contesto completo delle tue misure di sicurezza email e non penalizzi singole configurazioni prese separatamente.
Perché SPF non basta e serve comunque DMARC
Indipendentemente dalla modalità di errore specificata nel record SPF, è improbabile che i server riceventi onorino sempre la tua policy indicata. Ecco perché DMARC è diventato obbligatorio per i principali provider di posta elettronica dal 2026. Ciò accade perché SPF presenta questi limiti:
- Non richiede l'allineamento tra il dominio nel campo
Frome l'indirizzoReturn-Pathche controlla. Dal punto di vista SPF, non è necessario che coincidano. - SPF non offre funzioni di reportistica, ossia il destinatario non invia report al mittente con i risultati dell'autenticazione email.
- SPF non regge contro l'inoltro automatico e i flussi di posta indiretti, il che può causare problemi di autenticazione.
Per questi motivi, DMARC (Domain-based Message Authentication, Reporting, and Conformance) è stato introdotto come standard aggiuntivo per l'autenticazione delle email. DMARC colma le lacune di SPF e offre questi miglioramenti:
- DMARC si concentra sull'header visibile
From, visualizzato dagli utenti finali. - DMARC richiede allineamento tra il dominio utilizzato da SPF e quello visibile nel campo
Fromdell'email. - DMARC ignora le sfumature tra softfail e hardfail nella configurazione SPF, trattandoli entrambi come errori SPF.
- DMARC fornisce funzionalità di reportistica, consentendo l'invio dei risultati dell'autenticazione email al proprietario del dominio
From. Questo aiuta a identificare un uso improprio del dominio e a correggere eventuali errori nelle configurazioni per mittenti autorizzati. - DMARC include una policy che indica ai destinatari come trattare le email che non superano l'autenticazione, e i destinatari applicano questa policy. Al contrario, SPF da solo non offre meccanismi di enforcement.
DMARC è ormai largamente adottato e richiesto come standard di autenticazione, poiché supera i limiti di SPF e DKIM, blocca le impersonificazioni email esatte e migliora la consegnabilità delle email. Dal 2026, DMARC è obbligatorio per i mittenti di posta elettronica massiva su Google, Yahoo e Microsoft, rafforzando il suo ruolo di standard per l'autenticazione delle email.
Controlla gratuitamente il tuo record SPF, senza 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.