SPF risponde a una domanda ristretta: il server che si connette è autorizzato a utilizzare il dominio presentato in una particolare identità SMTP ? Non inizia con il nome del mittente visualizzato in una casella di posta. Questa distinzione spiega perché la modifica del record DNS sbagliato può lasciare intatto un problema di autenticazione.
Per un normale percorso inverso non vuoto, l'identità rilevante è il dominio in SMTP MAIL DA. L'indirizzo può essere un indirizzo di mancato recapito gestito dal provider anziché l'autore visibile. Un separato HELO può anche verificarsi un controllo. Quando MAIL FROM è vuoto, SPF costruisce la sua identità MAIL FROM utilizzando il dominio HELO e il postmaster della parte locale. Queste regole di identità sono definite in RFC 7208 §2.3 E RFC 7208 §2.4.
Segui la busta durante una consegna
Immagina un'applicazione che invia una fattura. La connessione SMTP proviene da 192.0.2.44 , il suo MAIL FROM è receipts@bounce.example.com e l'intestazione del messaggio dice From: billing@example.com . Si tratta di valori sintetici riservati alla documentazione, non a una ricetta di distribuzione.
Il destinatario valuta l'IP di connessione rispetto alla politica SPF su bounce.example.com . Non seleziona la politica SPF di example.com semplicemente perché quel dominio appare in From. Una policy del genitore non autorizza automaticamente il figlio.
Supponiamo che bounce.example.com pubblichi v=spf1 ip4:192.0.2.44 -all. Il meccanismo ip4 corrisponde e il risultato è superato. Se l'indirizzo di connessione fosse 192.0.2.45 , non corrisponderebbe; la valutazione raggiungerebbe -all e restituirebbe un errore. Nessuno dei due risultati dice se la fattura è autentica o se l'account che l'ha inviata è stato compromesso.
Individua le prove di cui ti puoi fidare
Richiedi il messaggio originale ricevuto anziché uno screenshot del nome visualizzato. Registra il destinatario, l'ora di ricezione, l'IP di connessione, l'identità SMTP valutata e il risultato SPF . Sotto RFC 8601 §7.1, i risultati o i registri di autenticazione attendibili del destinatario costituiscono una prova più forte di un'intestazione fornita da un mittente arbitrario.
Sotto RFC 5321 §4.4, un consegnato Return-Path può aiutare a rivelare il mittente della busta, ma è una traccia di consegna piuttosto che un comando che puoi modificare in sicurezza per cambiare SPF . I gateway, il nuovo invio e l'inoltro potrebbero creare un'altra transazione SMTP . Diagnosticare la transazione in cui il destinatario in errore ha eseguito il controllo.
Tieni un breve foglio di lavoro sull'identità: visibile dal dominio; MAIL DA dominio; Nome HELO ; connessione IP; Registro SPF osservato in quel momento; risultato; e qualsiasi allineato DKIM risultato. Il punto è prevenire un record editor dal diventare il primo passo diagnostico.
Gestisci i rimbalzi e gli inoltri separatamente
Un percorso inverso vuoto è normale per alcune notifiche di consegna. Non trattarlo come prova mancante e sostituiscilo con il dominio Da visibile. Cattura HELO e applica invece la regola del percorso nullo.
L'inoltro introduce un problema diverso. Il destinatario successivo vede l'IP di connessione dello spedizioniere, che potrebbe non essere autorizzato dal dominio della busta originale. Riscrivere la busta può modificare l'identità sottoposta a controllo. Un pass per l'identità riscritta non viene automaticamente allineato all'autore visibile. Indagare sul percorso completo e su eventuali sopravvissuti allineati Firma DKIM piuttosto che aggiungere ogni spedizioniere alla tua polizza.
Collega SPF alla decisione aziendale
DMARC aggiunge un confronto di identità: un risultato SPF che passa deve allinearsi con il dominio dell'autore per soddisfare il suo percorso SPF . Un passaggio DKIM allineato separato può soddisfare DMARC anche quando SPF non lo fa. RFC 9989 descrive quella relazione.
Per l'esempio della fattura, valutare allineamento secondo le modalità applicabili e le regole di discovery del dominio organizzativo; non dare per scontato che un suffisso di testo condiviso dimostri l'allineamento in ogni spazio dei nomi. Il rigoroso allineamento SPF richiede l'esatta uguaglianza dei domini sotto RFC 9989 §3.2.10.2; è specificata l'individuazione rilassata del dominio organizzativo RFC 9989 §4.10.2.
Prima di approvare una modifica, chiedi al proprietario del servizio quale identità di busta supporta il prodotto e chi ne controlla DNS . Conserva il record precedente, apporta la più piccola modifica autorizzata e invia una nuova fattura rappresentativa attraverso il percorso interessato. Chiudere il problema solo quando l'identità osservata, il risultato e l'allineamento richiesto soddisfano il risultato previsto.
Il pratico takeaway
Inizia con la busta SMTP e l'IP di connessione. La modifica di un dominio che SPF non ha mai valutato non è una riparazione, anche se uno strumento di controllo dei record diventa verde.
Mantenere la decisione riproducibile
Per il dispositivo della fattura, mantieni la connessione IP 192.0.2.44 , MAIL FROM dominio bounce.example.com e dominio autore visibile example.com come campi separati. Una modifica TXT principale non è prova di un controllo secondario riparato. Per una copia inoltrata, acquisisci una nuova riga di transazione invece di portare avanti l'IP originale. Si tratta di input ipotetici, non di SPF eseguiti o di osservazioni di consegna.