Il meccanismo neutro dell'SPF "tutti" è un meccanismo dei record del Sender Policy Framework (SPF) che determina una valutazione neutrale. Indica ai server riceventi di non prendere una decisione di accettazione o di rifiuto in base a SPF.
- Esempio di record SPF con ?all:
v=spf1 include:_spf.google.com ?all
In questo esempio, il dominio include le impostazioni SPF di Google ma termina con `?all`, che indica ai server di ricezione di assumere una posizione neutrale nei confronti degli altri mittenti. Non li approva né li rifiuta, non offre un giudizio chiaro.
Anche se tecnicamente valido, ``tutti'' può creare un'ambiguità che indebolisce la fiducia, ostacola l'applicazione del DMARC e può portare a problemi di consegna se usato impropriamente.
I punti chiave da prendere in considerazione
- Il meccanismo neutrale SPF non specifica chiaramente se un'e-mail è legittima o meno.
- Il meccanismo "tutto" può essere ancora utile in alcuni casi, come per i test e le configurazioni precedenti.
- Tuttavia, se utilizzato in produzione, può creare ambiguità per i server di posta.
- Non è consigliabile utilizzare il meccanismo neutrale SPF in produzione, poiché può facilitare lo spoofing e causare errori di autenticazione e consegna delle e-mail.
- Per migliorare la sicurezza delle e-mail del vostro dominio, si consiglia di sostituire il meccanismo "all" con il "softfail" (cioè, ~all).
SPF Meccanismo neutro (?tutti) vs. altri meccanismi
"Il proprietario del dominio ha dichiarato esplicitamente di non poter o voler affermare se l'indirizzo IP è autorizzato o meno". Un risultato "Neutro" DEVE essere trattato esattamente come il risultato "Nessuno"; la distinzione esiste solo a scopo informativo. Un trattamento più severo di "Neutro" rispetto a "Nessuno" scoraggerebbe i proprietari di domini dal testare l'uso dei record SPF". - RFC 4408
Il "?tutti" si differenzia dagli altri qualificatori SPF perché non fornisce un risultato di tipo "pass/fail", il che può ostacolare la valutazione DMARC e il processo decisionale del server di posta.
Il "tutti" può confondere i server di posta in ricezione, che non sapranno se fidarsi o meno dell'e-mail. La tabella seguente fornisce una sintesi degli effetti e dei casi d'uso dei diversi meccanismi.
| Meccanismo | Effetto | Caso d'uso |
|---|---|---|
| tutti (meccanismo neutro) | Neutro - nessun giudizio di accettazione o di bocciatura | Utilizzato raramente e non consigliato. A volte viene utilizzato durante le configurazioni di transizione. |
| ~tutti (approccio consigliato) | Soft fail - segna come sospetto | Utilizzato durante il rollout dell'SPF in quanto segnala i mittenti non autorizzati senza bloccarli, consentendo al DMARC di applicare le politiche senza rischiare falsi positivi. |
| -tutti | Hard fail - può essere rifiutato dai server di posta | Utilizzato per un'applicazione rigorosa e una forte sicurezza. Usare con cautela. Assicuratevi che il vostro record SPF sia completo prima di applicare -all per evitare di rifiutare e-mail legittime. |
Quando utilizzare il meccanismo SPF Neutro
Il meccanismo neutrale SPF non è raccomandato per la maggior parte delle moderne configurazioni di posta elettronica. Può essere ancora utilizzato in alcuni casi, ma con cautela e pianificando in anticipo la transizione verso meccanismi più sicuri.
Sistemi legacy
Alcune infrastrutture e sistemi più vecchi potrebbero non avere politiche chiare sui mittenti o un'adeguata gestione dell'SPF. In questi casi, è necessario un atteggiamento neutrale, come nel caso del meccanismo neutrale SPF, per mantenere la funzionalità.
Fase di test
È possibile utilizzare questo meccanismo anche durante l'implementazione iniziale dell'SPF. Consentirà ai proprietari dei domini di monitorare il traffico di e-mail mantenendo intatta la consegna, rendendo sicuro il suo utilizzo come punto di partenza.
Casi limite rari
A volte, altri meccanismi come ~all o -all possono causare problemi di recapito inattesi. Per diagnosticare questi problemi, è possibile utilizzare temporaneamente il meccanismo ?all.
⚠️ I meccanismi SPF vengono valutati in modo sequenziale e il posizionamento di ?all prima di altri meccanismi può far sì che la valutazione SPF si interrompa in anticipo, aggirando potenzialmente i controlli previsti.
Quali sono i rischi legati all'uso di "tutto"?
Il meccanismo "tutti" impedisce di ottenere risultati chiari di autenticazione, il che compromette sia la sicurezza delle e-mail (ad esempio, la protezione contro lo spoofing) che la loro recapitabilità. I possibili rischi includono:
Spoofing delle e-mail
Poiché ?all restituisce un risultato neutro, non fornisce alcuna difesa contro lo spoofing. Al contrario, ~all e -all restituiscono segnali di fallimento identificabili. Se combinati con un criterio DMARC applicato, questi segnali consentono ai server riceventi di mettere in quarantena o rifiutare le e-mail non autorizzate.
Conflitti DMARC
I risultati SPF neutri di "tutti" possono ancora essere tecnicamente in linea con il DMARC se i domini corrispondono, ma non forniscono alcun segnale "pass/fail", che il DMARC richiede per intraprendere azioni di applicazione.
Problemi di deliverability
Alcuni server di posta interpretano il meccanismo "tutti" (neutro) dell'SPF come una politica debole o non impegnativa. Questo può segnalare una scarsa applicazione dell'identità del mittente, riducendo potenzialmente la fiducia. I provider di posta come Gmail utilizzano diversi segnali e un criterio SPF debole può essere solo uno dei tanti fattori.
Come sostituire ?tutti con ~tutti o -tutti
Per migliorare la sicurezza del vostro dominio, dovreste sostituire il meccanismo "all" con uno più definitivo. Ecco i passi principali da seguire nel processo.
1. Verifica del record SPF attuale
Utilizzate il controllore SPF di PowerDMARC SPF checker per verificare la vostra configurazione attuale. Se non si dispone di un record, il nostro generatore gratuito di generato SPFgratuito vi aiuta a crearne uno su misura per le vostre fonti di invio.
2. Sostituire ?tutti con ~tutti
Il meccanismo di soft fail (~all) è un approccio prudente e pratico. DMARC con p=rifiuto può ancora rifiutare le e-mail basati su SPF ~all se il controllo SPF fallisce (~all attiva "fail").
3. Monitoraggio dei rapporti DMARC
È inoltre importante monitorare regolarmente l'attività delle e-mail utilizzando i report aggregati DMARC. L'analizzatore di rapporti analizzatore di rapporti DMARC offre rapporti DMARC in tempo reale e di facile utilizzo per aiutarvi a rimanere informati e sicuri.
Comuni errori di configurazione del meccanismo neutrale SPF
Quando si fa un uso improprio del meccanismo "tutti", è probabile che si verifichino lacune di sicurezza non volute e problemi di deliverability. Ecco alcuni errori frequenti da evitare.
Errore 1: usare "tutto" in produzione
Le politiche neutrali non offrono alcuna protezione. In questo modo, i messaggi di posta elettronica falsificati possono apparire legittimi. Di conseguenza, sia la vostra reputazione che la sicurezza dei vostri destinatari potrebbero essere a rischio.
Errore 2: combinare il "tutto" con politiche DMARC rigorose
Un criterio DMARC come p=reject dipende dal fatto che SPF (o DKIM) fornisca una chiara accettazione o un rifiuto. Con un SPF neutro, il DMARC non saprà cosa fare e potrebbe verificarsi un inutile fallimento del DMARC.
Errore 3: supporre che "tutto" sia equivalente a "tutto".
~All segnala almeno i mittenti non autorizzati. Il meccanismo "all", invece, non fornisce alcun giudizio. Molti confondono le due cose e quindi hanno problemi di autenticazione e consegna delle e-mail.
Domande frequenti
1. È lo stesso che non avere un record SPF?
No. Tutti segnalano una posizione neutrale. Nessun record SPF, invece, non fornisce alcuna indicazione. I server di posta li trattano in modo diverso.
2. Posso utilizzare "tutti" con DMARC?
Tecnicamente sì, ma è sconsigliato. Il DMARC si basa su risultati chiari di SPF pass/fail per l'applicazione. L'uso di "tutto" spesso porta a risultati neutri, riducendo l'efficacia del DMARC.
Pensieri finali
Il meccanismo "all" nei record SPF può sembrare innocuo all'inizio, ma può essere pericoloso. Non è raccomandato nella pratica e può esporre il vostro dominio a spoofing e ridurre l'efficacia dei criteri DMARC.
Se attualmente si utilizza ?all, si consiglia di sostituirlo con ~all (soft fail) per una maggiore sicurezza e un'autenticazione più affidabile delle e-mail.
Per un'affidabilità SPF a lungo termine, semplificate la gestione ed evitate i limiti di ricerca DNS con PowerDMARC. SPF ospitato soluzione. È costruita per gestire record complessi e ottimizzarsi automaticamente per fornire un'autenticazione del dominio senza errori.
- Certificato di marchio verificato vs certificato di marchio comune: scegliere quello giusto - 10 marzo 2026
- Livello di affidabilità dello spam (SCL) -1 Bypass: cosa significa e come gestirlo - 4 marzo 2026
- "Non supera la verifica DMARC e ha una politica DMARC di rifiuto": cosa significa e come risolverlo - 26 febbraio 2026
