UN SPF il risultato neutral o none non autentica l'host mittente. Entrambi i risultati possono coesistere con un messaggio consegnato, quindi la consegna da sola è una diagnosi inadeguata. Il compito pratico è identificare il motivo per cui il valutatore ha raggiunto quel risultato e se è previsto per l'identità effettivamente utilizzata.
Distinguere l'assenza da una non asserzione esplicita
RFC 7208 §2.6.1 definisce none come un risultato in cui nessuna identità di dominio utilizzabile può essere estratta dalla sessione SMTP oppure no Registro SPF viene recuperato. Sotto RFC 7208 §2.6.2, neutrale significa che il dominio non afferma se l'IP è autorizzato. Un record terminando con ?all può produrre neutralità per una fonte che non corrispondeva a un meccanismo precedente. Un record valido che raggiunge la fine senza una corrispondenza o un reindirizzamento ha anche un valore predefinito neutro implicito sotto RFC 7208 §4.7.
Questo è diverso dal passaggio. Pass autorizza esplicitamente l'host che si connette per l'identità valutata. Neutro non significa “probabilmente autorizzato”, e nessuno non significa “sicuro perché non esiste alcun divieto”. RFC 7208 §8.2 richiede che neutral venga trattato come nessuno ai fini della gestione, ma mantenere le due etichette separate è utile per diagnosticare la configurazione.
Inizia con l'identità osservata
Leggi i risultati dell'autenticazione generati dal destinatario da un sistema di cui ti fidi. Registrare se l'assegno è stato utilizzato MAIL DA O HELO, il dominio valutato e l'IP di connessione. Non accettare un mittente arbitrario fornito Authentication-Results linea come prova autorevole.
Un errore di indagine comune consiste nell'interrogare il dominio Da visibile mentre il messaggio utilizza un dominio della busta diverso. Un record SPF valido attivo example.com non dice nulla di per sé sul record restituito bounce.example.com. Un altro errore è interrogare solo l'editor del registrar anziché i server autorevoli che effettivamente servono il nome.
Se il risultato è nessuno, controlla il nome esatto richiesto e la risposta TXT . Controlla se a v=spf1 esiste un record lì, se il messaggio utilizzava l'identità della busta prevista e se il controllo registrato è stato effettuato prima di una recente modifica DNS . Una ricerca DNS corrente non può ricreare da sola lo stato DNS storico.
Non unire gli stati di errore in nessuno
Sotto RFC 7208 §4.5, producono due record SPF selezionati permerror, non un’innocua assenza di politica. Può verificarsi un errore DNS temporaneo temperror. Tali condizioni necessitano di propri percorsi di indagine. Una dashboard che raggruppa tutti i risultati non superati sotto " SPF mancante" può indirizzare un amministratore verso la riparazione sbagliata.
Per neutrale, esaminare la politica in ordine. L'uso del punto interrogativo è stato intenzionale? Un messaggio senza corrispondenza è arrivato alla fine di un record privo di un efficace meccanismo finale? Se il dominio delega la policy tramite reindirizzamento, ispeziona la destinazione e la valutazione risultante anziché presupporre che il testo di livello superiore costituisca l'intera policy.
Utilizzare una piccola matrice diagnostica
Quelle che seguono sono aspettative sintetiche, non consigli sulla configurazione della produzione:
v=spf1 ip4:192.0.2.10 ?all, valutato per 192.0.2.10 : sufficente.- Stesso record, valutato per 198.51.100.20 : neutro.
v=spf1 ip4:192.0.2.10, valutato per 198.51.100.20 : neutro attraverso il risultato predefinito.- Nessun SPF registrazione TXT con un nome valutato altrimenti valido: none, presupponendo che la ricerca venga completata senza un errore diverso.
Gli indirizzi IP di sola documentazione distinguono la logica dei criteri da un test del tenant in tempo reale. Ripeti test equivalenti con le tue fonti autorizzate in un ambiente controllato, quindi confronta le prove reali del ricevitore.
Riparare solo la causa dimostrata
Se il dominio della busta previsto non dispone di un record, progettare una politica per i suoi mittenti effettivi. Se la neutralità è intenzionale, documenta il motivo. Se un record cade accidentalmente, decidere la dichiarazione finale prevista dopo aver controllato i percorsi legittimi. Non sostituire il neutro con il passante universale +all: una volta raggiunta, le sovvenzioni passano invece di fissare l'inventario. Corrispondenze o errori precedenti possono comunque determinare un risultato.
Chiudere l'indagine con l'osservazione originale, la causa identificata, l'eventuale modifica approvata e un nuovo risultato del messaggio. Uno screenshot DNS costituisce prova della pubblicazione; il risultato di un messaggio ricevuto è la prova di una particolare valutazione. Conservali entrambi quando l'attività dipende dal percorso.
Utilizzare le prove per prendere una decisione
Conserva una riga per identità/IP/ora, risultato esatto, snapshot della policy e causa. Una ricerca completata senza alcun record SPF selezionato non equivale a un timeout o a più record selezionati. Se una dashboard li combina, utilizza le prove sottostanti prima di modificare DNS . I casi neutri sintetici dimostrano il flusso di controllo, non il successo dell'autenticazione o la garanzia di consegna.