Cosa imparerai in questo articolo
- Un record SPF indica ai server destinatari quali sistemi sono autorizzati a inviare e-mail per conto del Suo dominio.
- Se una ricerca restituisce il messaggio “nessun record SPF trovato”, significa che il dominio non pubblica attualmente un record TXT SPF valido sull’host oggetto della verifica.
- Per risolvere il problema, occorre innanzitutto verificare se il record sia effettivamente mancante, quindi identificare tutte le fonti di invio legittime prima di pubblicare un record SPF valido.
- Un record SPF corretto inizia con v=spf1, elenca le fonti di invio autorizzate, quali include o ip4, e termina con una politica, ad esempio ~all o -all.
- La pubblicazione dell’SPF è fondamentale, ma una protezione più efficace si ottiene utilizzando l’SPF insieme a DKIM e DMARC nell’ambito di una strategia più ampia di autenticazione delle e-mail.
Un risultato del tipo “nessun record SPF trovato” può sembrare un problema DNS di lieve entità, finché non inizia a indebolire la protezione contro lo spoofing e a compromettere l’autenticazione delle e-mail. La presente guida illustra l'importanza dell'SPF, il significato tipico dell'errore e come risolverlo senza causare nuovi problemi relativi ai record o alla sintassi.
Perché è necessario un record SPF?
L'SPF è uno dei controlli fondamentali nell'autenticazione delle e-mail. I punti riportati di seguito spiegano perché è importante e cosa occorre per configurarlo correttamente.
Un record SPF consente di definire quali server di posta sono autorizzati a inviare e-mail per un determinato dominio. Nel Sender Policy Framework, il dominio pubblica un record TXT DNS che elenca le fonti approvate, in modo che il server ricevente possa verificare se l'indirizzo IP mittente sia autorizzato.
Questo è importante ai fini della protezione del dominio. L'SPF rende più difficile per i mittenti non autorizzati spacciarsi per il dominio durante la consegna della posta, contribuendo così a ridurre il rischio di spoofing e garantendo un'autenticazione più rigorosa delle e-mail.
Come configurare un record SPF
Il processo di configurazione inizia con l'identificazione di tutte le fonti di invio legittime per il dominio. Ciò include i server di posta interni, le piattaforme cloud come Google Workspace o Microsoft Office 365 e qualsiasi strumento SaaS di terze parti che invii messaggi per conto dell’organizzazione. Tali sorgenti vengono quindi raggruppate in un unico record TXT SPF.
Un record SPF valido segue una struttura specifica. Inizia con v=spf1, include meccanismi autorizzati quali include, ip4 o ip6 e termina con una politica quale ~all per un fail soft oppure -all per un approccio più rigoroso.
Nel loro insieme, questi punti dimostrano perché l’SPF sia al tempo stesso una misura di controllo protettiva e un’operazione di configurazione che richiede precisione. Prima di correggere un record mancante, è utile comprendere non solo il funzionamento dell’SPF, ma anche quali siano i requisiti effettivi per una configurazione valida.
Perché ricevo l'errore "No SPF Record Found"?
Un risultato del tipo “nessun record SPF trovato” può avere più di una causa. Prima di risolvere il problema, è utile verificare se il record è effettivamente mancante o se la ricerca viene effettuata sull’host sbagliato.
Non è stato pubblicato alcun record SPF per l'host oggetto della verifica
Se una ricerca SPF restituisce il messaggio “nessun record SPF trovato”, ciò significa solitamente che il dominio non pubblica un record TXT SPF sull’host oggetto della verifica. In tal caso, il server destinatario non può utilizzare l'SPF per verificare i mittenti autorizzati. In assenza di un record SPF, lo spoofing diventa più agevole e l’autenticazione e la recapitabilità delle e-mail possono risentirne.
È possibile che la ricerca stia controllando l'host sbagliato
Questo errore può verificarsi anche quando viene selezionato un host errato. È possibile che un dominio principale pubblichi un record SPF mentre un sottodominio non lo faccia; pertanto, una ricerca relativa a tale sottodominio può comunque restituire il messaggio “nessun record SPF trovato”, anche se il dominio principale ne possiede uno.
Ecco perché è opportuno verificare tale errore prima di correggerlo. In alcuni casi, il documento risulta mancante. In altri casi, la ricerca viene semplicemente eseguita sull’host sbagliato.
Come risolvere l'errore “Nessun record SPF trovato”
La risoluzione di questo problema si articola solitamente in quattro passaggi: verificare lo stato del record, effettuare un inventario dei mittenti legittimi, pubblicare un record SPF valido e, infine, verificare che la configurazione aggiornata funzioni effettivamente.
Fase 1: Verificare che non esista alcun record SPF
Iniziando con la verifica che il record SPF sia effettivamente mancante. Verifichi i record TXT DNS del dominio utilizzando strumenti quali nslookup, dig o un verificatore SPF, quindi confronti tali risultati con la console di gestione DNS presso il provider del dominio o la piattaforma di hosting.
La Sua prima verifica dovrebbe confermare quanto segue:
- se esiste un record SPF
- se la sintassi sia valida
- se per il nome host oggetto della verifica sia stato pubblicato un solo record SPF
Questo passaggio è importante perché il problema non è sempre dovuto alla mancanza di un record. È possibile che esista già un record TXT SPF, ma che sia errato, pubblicato su un host errato o duplicato.
Fase 2: Identificare tutte le fonti legittime di invio delle e-mail
Una volta verificato lo stato del record, effettui un controllo su tutti i sistemi che inviano e-mail per conto del dominio. Ciò comprende solitamente:
- server di posta interni
- piattaforme cloud quali Google Workspace e Microsoft 365
- strumenti SaaS di terze parti, quali piattaforme CRM, di assistenza e di marketing
Quindi, associare ciascun mittente al meccanismo SPF da esso richiesto. Alcuni provider utilizzano un meccanismo di inclusione, mentre altri richiedono un valore IPv4 o IPv6 specifico. Un elenco completo dei mittenti rappresenta una delle migliori pratiche più importanti relative all’SPF, poiché qualsiasi mittente non incluso nel record SPF ha maggiori probabilità di non superare l’autenticazione o di essere considerato sospetto.
Elemento visivo: inserisca qui un elemento visivo in stile elenco di controllo con tre categorie di mittenti: server interni, piattaforme di posta elettronica cloud e mittenti SaaS di terze parti.
Fase 3: Creazione e pubblicazione di un record SPF valido
Dopo aver identificato le fonti di invio legittime, crei un record TXT SPF valido per il dominio. Iniziate con v=spf1, aggiungete i meccanismi approvati e concludete con la politica più adatta al vostro ambiente.
Pubblicare quindi il record nella console di gestione del DNS, specificando l'host corretto e utilizzando la sintassi esatta richiesta. Dopo aver salvato la modifica, attenda il tempo necessario per la propagazione del DNS prima di ritenere che il record funzioni o non funzioni a livello globale.
Fase 4: Verifica del corretto funzionamento dell'SPF e monitoraggio dei risultati dell'autenticazione
Una volta che il record SPF è attivo, lo verifichi. Eseguite una verifica del record SPF, inviate messaggi di prova e controllate le intestazioni di autenticazione o gli strumenti di sicurezza per verificare che la configurazione produca ora un risultato positivo al test SPF, come previsto.
La convalida dovrebbe proseguire anche dopo la correzione iniziale. Continuate a monitorare i registri di posta, i dashboard di autenticazione e i segnali di reputazione nel corso del tempo, in modo da poter individuare mittenti non autorizzati, scostamenti nella configurazione o nuove piattaforme SaaS che non sono mai state aggiunte al record SPF.
È sufficiente pubblicare un record SPF?
La pubblicazione di un record SPF è importante, ma di per sé non è sufficiente. L'SPF costituisce una componente dell'autenticazione delle e-mail; una protezione più efficace si ottiene utilizzandolo in combinazione con DKIM e DMARC. Nel loro insieme, questi controlli contribuiscono a verificare l’identità dei mittenti, favoriscono l’allineamento e forniscono ai server destinatari un contesto più ampio per la gestione dei messaggi sospetti.
Il protocollo DKIM contribuisce a verificare l'integrità dei messaggi e l'autenticità del mittente, mentre il protocollo DMARC garantisce l'allineamento, l'applicazione delle regole e la generazione di report, riducendo il rischio di configurazioni errate di DMARC. Nel loro insieme, questi controlli forniscono ai server destinatari una base più solida per valutare i messaggi sospetti.
La protezione aziendale richiede una governance continua
A livello aziendale, l'obiettivo è garantire una governance più ampia in materia di autenticazione. Ciò significa monitorare le modifiche apportate dai mittenti, garantire la corretta gestione del DNS, individuare i tentativi di spoofing e ridurre il rischio che piccoli problemi di configurazione si trasformino in problemi più gravi relativi alla sicurezza della posta elettronica.
Piattaforme come Mimecast possono contribuire a garantire una visione d’insieme su SPF, DKIM e DMARC, evitando che i team debbano risolvere i problemi relativi a ciascun segnale separatamente, soprattutto se si utilizza uno strumento di reportistica DMARC.
Nel loro insieme, questi controlli offrono alle organizzazioni una base più solida per verificare i mittenti, garantire il rispetto delle politiche e individuare tempestivamente eventuali lacune nell’autenticazione. L'SPF rappresenta un importante punto di partenza, ma una protezione più efficace si ottiene integrandolo in una strategia di autenticazione più ampia e continuativa.
Dai record SPF mancanti a una maggiore protezione del dominio
La risoluzione del problema “nessun record SPF trovato” non dovrebbe essere considerata un’operazione di pulizia facoltativa. La pubblicazione di un record SPF valido costituisce un passo fondamentale per proteggere l'ecosistema di posta elettronica del dominio, ridurre il rischio di spoofing e fornire ai server destinatari una base più chiara per la verifica dell'autenticità del mittente.
Il valore a lungo termine deriva dal fatto di non limitarsi a pubblicare un record DNS e passare oltre. Le organizzazioni che desiderano una maggiore visibilità, un controllo più rigoroso e una protezione più efficace contro le minacce via e-mail in continua evoluzione possono avvalersi di Mimecast per migliorare il monitoraggio e la governance di SPF, DKIM e DMARC in ambienti di invio complessi.