“SPF passa nello strumento" e "il destinatario segnala un errore SPF " non sono necessariamente contraddittori. Lo strumento potrebbe aver convalidato la sintassi, testato un IP diverso o interrogato DNS più recente. Il destinatario ha valutato una particolare connessione SMTP . La diagnosi inizia ricostruendo tale connessione, non presupponendo che uno dei risultati debba essere sbagliato.
Identificare ciò che lo strumento ha effettivamente passato
Salva gli input dello strumento e l'output esatto. Un indicatore di record valido non è necessariamente un passaggio SPF per un messaggio. Se ha eseguito una valutazione, registra l'indirizzo IP, mittente della busta, HELO ove pertinente e tempo di interrogazione. Mantieni visibile la distinzione quando segnali l'incidente ad altri team.
Raccogli quindi il risultato dell'autenticazione attendibile della destinazione o la prova del rifiuto SMTP . Non trattare un mittente fornito Authentication-Results campo come verdetto della destinazione. RFC 8601 spiega perché i risultati necessitano di un confine di fiducia.
Confronta l'identità e l'indirizzo di connessione
SPF valuta la connessione rispetto all'identità SMTP pertinente, non semplicemente all'indirizzo del mittente visibile. RFC 7208 §2.3 E RFC 7208 §2.4 descrivere i controlli HELO e MAIL FROM. Confrontare l'IP osservato dal destinatario e il dominio valutato con la struttura dello strumento.
Un caso illustrativo: un'applicazione visualizza Da billing@example.com ma utilizza un'identità di busta nel dominio di un provider. Un test dello strumento di example.com può essere irrilevante per l'effettiva decisione SPF del destinatario. In un altro caso, l'applicazione esce attraverso un relè diverso da quello previsto dall'amministratore. Correggere la comprensione del percorso prima di estendere l'autorizzazione.
Come descritto in RFC 7208 §10.3, se è coinvolto un forwarder, il destinatario finale può vedere la connessione del forwarder anziché l'IP di invio originale. Non aggiungere ogni forwarder osservato SPF del dominio di origine come riparazione generale. Valutare invece il flusso completo di posta indiretta e altri risultati di autenticazione.
Confronta DNS negli orari rilevanti
Recuperare il record e le dipendenze applicabili correnti. Conserva l'ora dell'evento del destinatario e qualsiasi prova DNS contemporanea. Un test eseguito dopo una riparazione non può dimostrare ciò che il ricevitore ha visto in precedenza. Allo stesso modo, la dipendenza di un provider può cambiare senza una modifica del record locale.
Controlla la pubblicazione autorevole, le risposte ricorsive e le condizioni di errore. Distinguere una vecchia policy memorizzata nella cache da una policy mancante o da un errore DNS temporaneo. RFC 7208 sezione 2.6 definisce diverse categorie di risultati; non collassare fallire, softfail , temperror E permerror in una diagnosi.
Riproduci il percorso reale
Utilizzare un valutatore attento agli standard con gli input osservati. Esamina il meccanismo di corrispondenza, i qualificatori, le dipendenze ricorsive e qualsiasi limite o errore DNS . Laddove DNS storico non sia disponibile, etichetta la riproduzione come un test dello stato attuale piuttosto che come una ricostruzione dell'evento precedente.
Testare entrambe le famiglie di indirizzi se il mittente può utilizzarle entrambe. Confronta più campioni interessati e non interessati per verificare se l'errore segue un percorso, una regione, una famiglia IP o un intervallo di tempo. Questo è un metodo diagnostico consigliato, non un'affermazione secondo cui un provider specifico distribuisce il traffico in un modo particolare.
Effettuare la riparazione supportata più stretta
Correggere il problema confermato: configurazione della busta errata, ambito autorizzato mancante, policy non valida, dipendenza interrotta o incoerenza del routing. Conserva lo stato originale e ottieni la normale approvazione della modifica. Non ampliare la politica semplicemente per far passare un campione inspiegabile.
Dopo la riparazione, invia tramite lo stesso percorso dell'applicazione e controlla un nuovo risultato del ricevitore attendibile. Controllo DMARC separatamente, perché una passata SPF grezza può essere non allineata e allineata DKIM pass può supportare DMARC anche quando SPF fallisce. IL guida alla diagnosi dell'allineamento copre questa distinzione. Chiudi l'incidente con la differenza tra le prove vecchie e nuove, non solo con l'ennesimo screenshot della pedina verde.
Sfondo DNS : RFC 1035 sezione 3.2.1 definisce il TTL del record di risorse; RFC 2308 §5 copre la memorizzazione nella cache delle risposte negative. RFC 8767 §4 aggiorna la semantica TTL per consentire l'uso obsoleto quando l'aggiornamento autorevole non riesce. Questi descrivono il comportamento DNS , non un tempo di completamento universale per una modifica.
Utilizzare un documento decisionale concreto
Confronto ipotetico: un verificatore valuta oggi l'IP A rispetto example.com ; il ricevitore di ieri ha valutato l'IP B rispetto a bounce.service.example.net . Questi sono set di input diversi. Registra sia le triple IP/dominio/ora che le prove DNS disponibili per ciascuna. Se manca DNS storico, indicare che il risultato originale non può essere riprodotto completamente. Non etichettare nessuno degli strumenti come difettoso basandosi solo su queste osservazioni. Qui non è stato eseguito alcun replay o test DNS .