Defaults.Exposed › Report

SPF ~all vs -all: Softfail o Hardfail — Cosa Hanno Scelto 139 Milioni di Record (2026)

Pubblicato 2026-07-03

Dati aggiornati al 2026-06-29 · metodologia v7. Dati aggregati del censimento su 261 milioni di domini classificati. Tutti i valori sono aggregati — non pubblichiamo mai il record di una singola azienda. Vedi come classifichiamo.

Ogni record SPF termina con un meccanismo “all” — il verdetto sulla posta proveniente da qualsiasi luogo non presente nella tua lista — e internet ha scelto in modo schiacciante quello morbido: il 55,8% dei 139 milioni di domini che pubblicano SPF termina con ~all (softfail), contro il 39,3% che termina con -all (hardfail). Un solo carattere separa “rifiuta le contraffazioni” da “probabilmente è una contraffazione — consegnala comunque”. Quale sia quello giusto per te dipende da una seconda impostazione che la maggior parte dei proprietari non configura mai.

Cosa comunicano davvero ~all e -all a un destinatario?

• -all (hardfail): “Rifiuta la posta proveniente da qualsiasi altro luogo.” Un no deciso.
• ~all (softfail): “La posta proveniente da altrove probabilmente non è legittima — accettala, magari segnalala.” Una scrollata di spalle.
• ?all (neutrale): “Nessuna opinione.” Scelto dal 3,0% dei pubblicatori; protezione solo di nome.
• +all: “Chiunque può inviare come me.” Pubblicato da 36.014 domini, e peggio di nessun record — il problema dello zerbino di benvenuto ha un suo report dedicato.

Allora ~all è sbagliato? Solo se è da solo — e quasi sempre lo è

Il softfail ha una giustificazione moderna difendibile: le linee guida di Google per i mittenti, e con esse la maggior parte delle pratiche di deliverability, convergono su ~all abbinato a una policy DMARC applicativa (p=reject). L’abbinamento protegge tanto quanto -all presso ogni destinatario che valuta DMARC — il che ora include tutti i principali provider di caselle di posta — senza far rimbalzare in modo netto la posta legittima inoltrata, la classica vittima di -all. In quella configurazione la scrollata di spalle acquista mordente: DMARC fornisce il verdetto che SPF ha rinunciato a dare.

Ma l’abbinamento è il punto cruciale, ed ecco cosa aggiunge il censimento che le guide di configurazione non possono aggiungere: dei 77.484.057 record softfail presenti su internet, solo 7,1 milioni — circa 1 su 11 — hanno una policy DMARC applicativa alle spalle. Per gli altri 70,4 milioni di domini, ~all è esattamente ciò che sembra. Il loro record identifica la contraffazione e la lascia passare.

I mandati del 2024 non hanno risolto la questione?

No — e la distinzione conta più di quanto la maggior parte della copertura mediatica suggerisca. Google e Yahoo hanno iniziato a richiedere l’autenticazione dai mittenti massivi a febbraio 2024, seguiti da Microsoft a maggio 2025: SPF o DKIM validi e allineati, più un record DMARC di minimo p=none. I mandati si fermano prima di richiedere l’applicazione — un dominio con ~all, un record p=none e DKIM allineato è pienamente conforme, e rimane pienamente falsificabile. I mandati hanno normalizzato la burocrazia, non la protezione. Quella zona intermedia non applicata — conforme, pubblicata, falsificabile — è precisamente il divario che questo censimento misura, ed è la popolazione più numerosa nella sicurezza email.

Con cosa dovrebbe terminare, quindi, il tuo record?

1. Invii posta e l’inoltro conta (newsletter, mailing list, alias): ~all con DMARC p=reject alle spalle — l’abbinamento raccomandato di cui sopra.
2. Invii posta da una configurazione strettamente controllata: -all funziona e dichiara la policy nel record stesso. Mappa prima i tuoi mittenti — un finale rigido su un record non mappato rompe la posta reale, o peggio.
3. Il dominio non invia mai posta: -all più p=reject, subito. Non esiste nulla di legittimo da proteggere, quindi non c’è nulla da rompere.

Qualunque finale tu scelga, la lezione in una riga del censimento vale sempre: il qualificatore conta solo quanto ciò che lo fa rispettare. Il punto in cui ti trovi su quella scala è misurabile.

Domande frequenti

È meglio SPF ~all o -all? Nessuno dei due, in assoluto. ~all con una policy DMARC applicativa è lo schema raccomandato dalle linee guida di Google — pari protezione presso i destinatari che valutano DMARC senza rompere la posta inoltrata. -all è adatto ai mittenti strettamente controllati. ~all da solo — lo stato di tutti tranne 1 su 11 dei domini softfail — è l’opzione debole.

Cosa significa softfail SPF? ~all comunica ai destinatari che la posta proveniente da server non elencati è probabilmente illegittima ma dovrebbe comunque essere accettata, di solito con sospetto. Diventa protezione reale solo quando una policy DMARC agisce sull’errore; vedi SPF senza DMARC.

L’hardfail -all romperà la mia posta inoltrata? Può farlo: l’inoltro reinvia la tua posta dal server del forwarder, che il tuo SPF non elenca, e un hardfail invita al rifiuto prima che DKIM o DMARC intervengano. Quel rischio è il motivo per cui esiste l’abbinamento ~all + p=reject.

Google e Microsoft richiedono -all adesso? No. I mandati per i mittenti massivi richiedono un’autenticazione allineata e valida e un record DMARC di minimo p=none — nessuna applicazione, nessun qualificatore specifico. Il rifiuto da parte di Google della posta massiva non conforme è attivo; Microsoft ha spostato nella posta indesiderata gli errori e si sta muovendo verso il rifiuto vero e proprio. La conformità non è protezione.

Verifica con cosa termina il tuo record — e cosa c’è dietro

Due controlli ti dicono entrambe le cose, gratis, in 30 secondi. Se sei una delle 70,4 milioni di scrollate di spalle non applicate, la soluzione è un record DNS, non un acquisto.

Controlla il tuo dominio → · Correggi SPF → · Correggi DMARC → · Il modello di maturità SPF → · La mappa +all → · Solo dati aggregati. Dati archiviati ed elaborati nell’UE.