Cosa imparerai in questo articolo
- Un dominio dovrebbe pubblicare un solo record SPF per ogni nome host. Se lo stesso nome host presenta più record SPF, la valutazione SPF può restituire un errore SPF PermError anziché un normale risultato positivo.
- I sottodomini distinti possono avere le proprie politiche. Ad esempio, example.com e mail.example.com possono pubblicare ciascuno un record se inviano posta in modo indipendente.
- Di solito si verificano record SPF multipli quando viene aggiunto un nuovo mittente, come Google Workspace, Amazon SES o un’altra piattaforma di posta elettronica, senza integrarlo nel record TXT SPF esistente.
- La soluzione corretta non consiste nel mantenere politiche SPF separate. L'obiettivo è quello di unire i record SPF in un single record SPF, verificare la correttezza sintattica dell'SPF e monitorare la deliverability dopo l'aggiornamento.
È possibile avere più record SPF su un unico dominio?
Per lo stesso nome host, no. Un dominio dovrebbe pubblicare un solo record SPF per ogni nome host. La RFC 7208 stabilisce che un nome di dominio non deve contenere più record che potrebbero indurre un controllo di autorizzazione a selezionare più di un record . In pratica, la presenza di più record SPF genera un errore di "record SPF multipli" anziché un risultato valido di "SPF superato" .
In questo caso, la distinzione tra sottodomini è importante. example.com e mail.example.com possono avere ciascuno il proprio record TXT SPF se inviano e-mail in modo indipendente, poiché si tratta di nomi DNS diversi. Tuttavia, example.com non dovrebbe pubblicare due record TXT distinti del tipo v=spf1 per lo stesso host. Questa è la differenza tra un dominio che utilizza un record single e più sottodomini che utilizzano i propri record.
Suggerimento visivo: inserisca un semplice diagramma DNS che mostri example.com con un record SPF e mail.example.com con un proprio record SPF separato per .
Problemi comuni causati dalla presenza di più record SPF
I destinatari non interpretano le politiche SPF duplicate come un'autorizzazione aggiuntiva. Di solito li interpretano come una condizione di errore . La RFC 7208 considera i record SPF multipli come non validi ai fini della valutazione e, nei controlli pratici, ciò si manifesta comunemente come errore "SPF PermError". Ciò significa che il server ricevente non può considerare l'SPF come un normale risultato positivo.
Tale errore tecnico ha ripercussioni sul business. Le e-mail legittime possono essere contrassegnate come spam, sottoposte a un filtraggio più rigoroso o respinte. Nel corso del tempo, i record duplicati possono comportare un aumento del carico amministrativo, ridurre l’effettività di consegna delle e-mail e compromettere la reputazione dell’ e del mittente, poiché i ripetuti problemi di autenticazione riducono la fiducia nel dominio.
Come si verificano i record SPF multipli?
La causa più comune è il cambiamento senza consolidamento. Un team integra Microsoft Exchange Online Protection, Google Workspace, Amazon SES, un CRM, una piattaforma di assistenza o un servizio di marketing, e la guida alla configurazione del fornitore fornisce un nuovo esempio di record SPF del tipo . Anziché integrare il nuovo meccanismo nel record SPF esistente, qualcuno pubblica un record SPF separato.
Ciò è particolarmente frequente nelle organizzazioni di grandi dimensioni, dove le impostazioni DNS vengono modificate da team diversi e nessuno è responsabile dell’autenticazione e-mail dall’inizio alla fine. Si verifica inoltre in occasione di fusioni, migrazioni e cambi di fornitore, quando i servizi di " " vecchi e nuovi inviano messaggi dallo stesso dominio contemporaneamente. In tali casi, la presenza di più registrazioni riflette spesso una titolarità frammentata piuttosto che un intento doloso.
Come si presenta un errore relativo alla presenza di più record SPF?
Il segnale più evidente è la presenza di un risultato “SPF PermError” in un controllo SPF, in uno strumento di verifica SPF, nell’intestazione di un messaggio o in uno strumento di analisi dell’autenticazione . Un altro segnale evidente è una ricerca DNS che mostra più di un record TXT che inizia con v=spf1 per lo stesso nome host .
Dal punto di vista operativo, il problema si manifesta spesso sotto forma di un improvviso malfunzionamento dell'SPF in seguito all'integrazione di un nuovo mittente. Potreste inoltre riscontrare problemi inspiegabili relativi all’invio dei messaggi nella cartella “ ” (Posta indesiderata), anche quando i mittenti in questione sono legittimi. Se non si verificano altri cambiamenti, ma la deliverability di diminuisce subito dopo l’entrata in funzione di una nuova piattaforma, vale la pena verificare innanzitutto la presenza di record SPF duplicati.
Suggerimento visivo: inserisca uno screenshot di uno strumento di verifica SPF che mostri due voci “v=spf1” e un risultato “SPF PermError”.
Come si verifica se un dominio presenta più record SPF?
Si inizi dal livello DNS. Verifichi i record TXT del dominio e cerchi se sono presenti più di una voce v=spf1 relativa al nome host esatto utilizzato per l'invio. Non date per scontato che il dominio principale sia l'unico posto da controllare. Se la posta viene inviata da un sottodominio, esegua la ricerca SPF su anche per quel sottodominio.
Questo controllo è particolarmente importante dopo:
- Aggiunta di Google Workspace, Microsoft 365, Amazon SES o un’altra piattaforma di posta elettronica esterna
- Migrazioni DNS o cambi di registrar
- Implementazione di piattaforme di sicurezza o altri aggiornamenti dell'infrastruttura di posta elettronica
Sono proprio questi i momenti in cui si verificano più spesso i record SPF duplicati.
Come si risolvono i problemi legati alla presenza di più record SPF?
La soluzione non consiste nel continuare a cercare di risolvere i problemi relativi alle voci duplicate. Si tratta di riunire tutti gli elementi in un’unica politica SPF valida per quel nome host, per poi verificare che funzioni come previsto.
- Raccogliete tutti i record SPF esistenti. Elencare tutti i record TXT SPF associati al dominio e a eventuali sottodomini pertinenti. Controlli attentamente la Sua zona DNS ed elenchi ogni nome host su cui è pubblicato l'SPF, in modo da poter operare sulla base di un inventario completo .
- Esaminare tutti i meccanismi e le inclusioni. Esamini ogni record SPF e identifichi le fonti di invio che sono ancora legittime e ancora necessarie. Verifichi ogni voce IPv4, IPv6, "include", "a" e "mx" rispetto ai Suoi attuali sistemi di posta elettronica e verifichi se tale fonte invia ancora posta per il dominio.
- Eliminare le voci obsolete. Una volta individuate le fonti valide, elimini tutto ciò che non necessita più di un’ autorizzazione. Elimini le piattaforme dismesse, i meccanismi duplicati, i sistemi di test e i vecchi servizi di terze parti che non fanno più parte del Suo flusso di posta.
- Creare un unico record SPF consolidato. Raggruppa tutte le fonti di invio richieste in una politica v=spf1 single per quel nome host. Aggiunga solo i meccanismi di cui ha ancora bisogno, li disponga in un ordine logico e chiaro e concluda la registrazione con un qualificatore come ~all o -all.
- Verifichi la validità del nuovo record SPF. Prima di pubblicarlo in produzione, esegua un controllo del record SPF all’indirizzo per verificare che la sintassi sia corretta, che il numero di ricerche rimanga entro i limiti e che il record continui a coprire tutti i mittenti legittimi . Si prega di correggere eventuali errori di sintassi o di ricerca prima di sostituire il record attivo.
- Pubblicate il record SPF unified ed eliminate quelli superflui. Aggiorni il DNS in modo che per quel nome di host rimanga in vigore solo la nuova politica SPF consolidata . Rimuova contemporaneamente i record TXT SPF in eccesso, anziché lasciarli attivi insieme a quello nuovo.
- Si assicuri che esista un solo record SPF. Dopo la pubblicazione, ricontrolli nuovamente i record TXT DNS e verifichi che per quel nome host sia pubblicato un solo record SPF . Se il Suo provider DNS mostra più voci TXT, verifichi attentamente per assicurarsi che i record SPF precedenti siano stati completamente rimossi.
- Monitorare la deliverability. Una volta che il record unified sarà attivo, monitorate attentamente il flusso di posta per individuare eventuali errori SPF, messaggi bloccati, o altri problemi di autenticazione. Esaminare i messaggi di rimbalzo, i registri di posta o i risultati dell’autenticazione per individuare eventuali mittenti mancanti e correggere i dati, se necessario.
L'obiettivo non è semplicemente quello di eliminare l'errore. L'obiettivo è quello di ottenere un unico record SPF che sia valido, gestibile e allineato con tutti i servizi di invio legittimi.
Come si uniscono correttamente più record SPF?
L'unione dei record SPF non consiste semplicemente nel combinare il testo in un'unica riga. L'obiettivo è quello di definire una politica SPF chiara e valida che copra tutti i mittenti legittimi senza aggiungere inutili complessità.
Elaborare una politica chiara in materia di SPF
Un record SPF unificato e ben strutturato combina meccanismi quali ip4, ip6, a, mx e include in un’unica sequenza logica, dopodiché si conclude con una politica chiara come ~all o -all. Ecco come dovrebbe avvenire l'unione dei record SPF. L'obiettivo è disporre di un single record SPF che comprenda tutti i mittenti legittimi.
Evitare la complessità durante l'unione
Gli errori più gravi che si commettono durante il processo di fusione sono la duplicazione e l'eccessiva complessità. Si raccomanda di evitare meccanismi duplicati o in conflitto tra loro, e di prestare particolare attenzione alle inclusioni multiple, poiché ogni ricerca DNS viene conteggiata ai fini del limite di ricerche DNS previsto dall’SPF. Talvolta si ricorre all’appiattimento degli SPF per ridurre tale numero, ma anche un record SPF unificato, tecnicamente valido, può diventare difficile da gestire se la titolarità dell’ è frammentata.
In che modo la presenza di più record SPF influisce sul DMARC e sulla deliverability?
L'SPF non è l'unico fattore. Quando SPF restituisce un PermError, potrebbe non riuscire a fornire un risultato SPF allineato utilizzabile per un DMARC di tip. La situazione si aggrava quando l', il DKIM è assente, non funzionante o non allineato, poiché in tal caso il destinatario dispone di un numero inferiore di segnali di autenticazione validi su cui fare affidamento.
In pratica, i record SPF duplicati possono comportare il filtraggio dello spam, il rischio di rifiuto e un peggioramento del posizionamento nella posta in arrivo. Gli errori di autenticazione ripetuti finiscono inoltre per minare, nel tempo, la fiducia nel dominio mittente; ecco perché è importante disporre di un sistema di segnalazione DMARC più rigoroso . Ecco perché si tratta sia di un problema di sicurezza della posta elettronica che di un problema di recapito. Uno strumento di verifica dei record DMARC può aiutare a comprendere il quadro generale, ma il suo funzionamento dipende comunque da dati di autenticazione SPF corretti.
Cosa succede quando si hanno molti mittenti ma un solo record SPF?
Il fatto di avere molti mittenti non implica la necessità di disporre di più record SPF. Un single record SPF può autorizzare numerose fonti di invio tramite meccanismi quali ip4, ip6, mx e include. Questo è il modo corretto per gestire un unico dominio utilizzando contemporaneamente diversi servizi di posta elettronica affidabili .
La distinzione fondamentale riguarda la presenza di più mittenti e di più politiche SPF. Una politica SPF dovrebbe tenere conto di tutti i servizi approvati dall' , anziché pubblicare record separati per lo stesso nome host. Anche dopo il consolidamento, la complessità continua a rappresentare un rischio. Un numero eccessivo di istruzioni "include" può far avvicinare il record al limite di 10 ricerche DNS, e un record tecnicamente valido può comunque diventare difficile da gestire se la responsabilità è frammentata tra diversi team.
Migliori pratiche per una gestione più efficace dei record SPF
I problemi relativi all’SPF spesso non riguardano tanto la sintassi, quanto piuttosto la titolarità e il controllo delle modifiche. Una gestione quotidiana più efficace contribuisce a prevenire la duplicazione dei record, a ridurre gli errori di autenticazione e a semplificare la gestione delle politiche nel tempo.
- Assegnare chiaramente le responsabilità relative all’SPF e all’autorizzazione dei mittenti in uscita tra i vari team.
- Si raccomanda di esaminare la politica SPF esistente prima di adottare qualsiasi nuova piattaforma di posta elettronica o fornitore.
- Si prega di documentare ogni mittente autorizzato, il motivo per cui è stato incluso e chi ne è il responsabile.
- Verifichi regolarmente le impostazioni DNS e di autenticazione a seguito di modifiche all’infrastruttura o al fornitore.
-
Si raccomanda di mantenere un record single per ogni nome host e di utilizzare record SPF distinti solo per i sottodomini che inviano effettivamente posta in modo indipendente.
Queste best practice migliorano la visibilità a lungo termine, il controllo delle modifiche e le procedure di autenticazione delle e-mail. Inoltre, rendono più semplice la gestione dell'SPF ( ) man mano che gli elenchi dei mittenti crescono e cambiano.
Semplificare la gestione di più record SPF
Il concetto fondamentale è semplice: un dominio o un nome host dovrebbe avere un solo record SPF, non più voci SPF in conflitto tra loro. La presenza di più record SPF non migliora l'autenticazione. Tali errori, solitamente di tipo SPF PermError, possono compromettere la deliverability delle e-mail, l’affidabilità del mittente e l’efficienza operativa.