Potrebbe offrire una vecchia interfaccia DNS un record tipo etichettato SPF. Tale etichetta può fare riferimento al record di risorse storico di tipo 99, che non è il formato di pubblicazione richiesto dall'attuale specifica SPF versione 1. RFC 7208 §3.1 richiede la politica SPF in TXT , tipo DNS 16 e ha interrotto il precedente approccio di tipo alternativo.
Per un amministratore che mantiene un dominio più vecchio, il compito utile è una pulizia della compatibilità: stabilire cosa viene effettivamente servito, correggere TXT e identificare eventuali sistemi legacy che dipendono ancora dal tipo 99 prima di rimuovere i dati obsoleti.
Conferma il tipo di cavo
Un prodotto può utilizzare " SPF " come etichetta di configurazione intuitiva durante la creazione effettiva di dati TXT . Un'altra interfaccia può effettivamente creare il tipo 99. Non decidere solo dal testo del menu. Interroga TXT in modo esplicito e, se i tuoi strumenti DNS lo supportano, esegui query sul tipo 99 separatamente. Salva i tipi di risposta, il nome del proprietario, i valori e i TTL.
La politica SPF appartiene al nome di dominio valutato. Una policy TXT alla radice non copre automaticamente un sottodominio della busta separato. Assicurati che il dominio da controllare corrisponda a un'identità di invio reale prima di concludere che un risultato TXT mancante spieghi un problema di posta.
Comprendere perché la doppia pubblicazione non è l'obiettivo
Lo storico RFC 4408 §12 registra l'assegnazione SPF di tipo 99; quella specifica sperimentale consentiva un tipo di record di risorse alternativo. RFC 7208 §3.1 spiega che l'approccio di transizione non ha prodotto un modello di distribuzione comune affidabile e ha selezionato TXT solo per la versione 1 SPF Il mantenimento di due copie divergenti non migliora la moderna valutazione SPF ; crea un'altra configurazione che le persone potrebbero ispezionare e fraintendere.
Un record di tipo 99 da solo non è quindi sufficiente per la pubblicazione SPF versione 1 conforme agli standard. Un corretto registrazione TXT è la priorità operativa. Se TXT e il tipo 99 non sono d'accordo, non selezionare il valore che sembra più rigido. Ricostruire la politica del mittente prevista dalla proprietà attuale del servizio e dalle istruzioni del fornitore.
Pianificare una migrazione conservativa
Inizia esportando lo stato DNS esistente. Se TXT è assente, progettare e convalidare la policy corretta prima di pubblicarla. Se TXT esiste già, conferma che è l'unico record SPF TXT applicabile in RFC 7208 §4.5 e valuta correttamente. Non creare un'altra policy TXT semplicemente perché esiste il tipo 99.
In un esempio sintetico, un dominio serve il tipo 99 contenente v=spf1 ip4:192.0.2.10 -all ma non ha record TXT SPF . Una moderna valutazione basata su TXT non ottiene la sua politica da quel valore di tipo 99. La pubblicazione di una policy TXT equivalente approvata risolve il formato di pubblicazione standard mancante. L'indirizzo è solo documentazione e non deve essere copiato in produzione.
Prima di rimuovere il tipo 99, controllare il software di posta interno, l'automazione DNS , gli script di monitoraggio e le procedure di modifica per le aspettative legacy. Uno strumento locale potrebbe comunque interrogarlo anche se lo standard non lo richiede. Aggiorna deliberatamente tali dipendenze, quindi rimuovi il record obsoleto sotto i controlli delle modifiche dell'organizzazione. Questa è una precauzione di migrazione, non una raccomandazione per preservare il tipo 99 a tempo indeterminato.
Verifica DNS e posta effettiva
Ispeziona le risposte TXT autorevoli dopo la pubblicazione e tieni conto delle cache ricorsive. Testare messaggi reali dai servizi di invio conservati presso destinatari attendibili, annotando l'identità SMTP utilizzata e il risultato SPF . Un passaggio di segnalazione del destinatario per un dominio busta controllato dal fornitore diverso non dimostra che è stata esercitata la politica TXT del dominio corretto.
Aggiorna i runbook per indicare il tipo TXT 16 e acquisire il nome del proprietario previsto. Se l'interfaccia utente del provider continua a utilizzare un'etichetta SPF , documenta ciò che crea. Ciò impedisce che lo stesso problema si ripresenti durante il trasferimento del registrar o la migrazione del provider DNS.
Definire le prove di completamento
Conserva le risposte DNS prima e dopo, l'approvazione della policy del mittente, l'inventario delle dipendenze legacy ritirate e i test rappresentativi dei messaggi. L'obiettivo è mantenere la policy SPF versione 1 nel formato richiesto, in cui i vecchi strumenti non presentino più prove contrastanti.
Utilizzare le prove per prendere una decisione
Per l'esempio solo type99, conserva i risultati della query separati per TXT e type99. Supponendo un'identità valida e nessun errore di ricerca, un controllo SPF conforme agli standard non trova alcuna policy TXT e non ne restituisce alcuna; non prende in prestito il tipo99. Dopo una modifica TXT approvata, richiedi un campione utilizzando quell'identità esatta prima della chiusura. Si tratta di un comportamento previsto del protocollo, non di una migrazione misurata.