Un risultato della verifica verde e un messaggio non riuscito possono entrambi essere accurati. Il controllore potrebbe aver ispezionato una politica DNS corrente per un nome, mentre il destinatario ha valutato un dominio Da diverso, ha utilizzato una risposta precedente memorizzata nella cache o ha ricevuto un messaggio senza la firma allineata prevista.
Inizia rendendo comparabili le due osservazioni. Conserva i risultati originali prima di modificare la configurazione. Quindi chiedi esattamente cosa ha esaminato ciascun sistema e quando.
Annota ciò che il controllore ha effettivamente controllato
Registra il dominio inserito, il nome esatto della query, il tipo di query, il timestamp, il risolutore e il set di record restituito. Salva la spiegazione visualizzata e il colore del risultato. Determina se lo strumento ha esaminato solo DNS o ha effettivamente valutato un messaggio fornito.
Per una policy pubblicata su _dmarc.example.com , una ricerca positiva stabilisce una policy osservata con quel nome. Non stabilisce il SPF O DKIM identità sul messaggio di un'applicazione. Inoltre, non dimostra che lo strumento abbia seguito le stesse regole di rilevamento del destinatario.
Mantenere visibili i presupposti delle specifiche. Attuale RFC 9989 §4.10 utilizza le regole di percorso ad albero DNS per l'individuazione e i domini organizzativi. Un'implementazione legacy può utilizzare presupposti diversi, in particolare per rilassati allineamento. Non descrivere un disaccordo come un errore DNS finché il confronto non supporta tale conclusione.
Avvia l'indagine del destinatario dal messaggio
Per un esempio consegnato, conservare il messaggio ricevuto originale e identificare il sistema ricevente attendibile Authentication-Results. Registra il dominio Da visibile, l'identità SPF valutata, ogni valore DKIM d e s, i risultati dell'autenticazione, l'allineamento e la policy applicabile.
Sotto RFC 8601 §7.1, tratta un'asserzione di autenticazione non attendibile come contenuto del messaggio, non come un sostituto del lavoro del sistema ricevente. Inoltre, il nome di un fornitore in un'intestazione non stabilisce che la tua organizzazione abbia approvato l'account che lo utilizza.
In caso di rifiuto, potrebbe non esserci alcun messaggio consegnato da controllare. Conservare l'intero testo SMTP restituito, il riferimento al messaggio o alla transazione, l'account di invio, il dominio del destinatario e il timestamp. Combinali con il record dell'evento del sistema di invio e il messaggio inviato originale disponibile.
Raccogli un confronto DNS con il contesto
Un pacchetto di indagine dovrebbe includere:
- Osservazione: risposta autorevole completa per il nome esatto del proprietario; Perché conservarlo: mostra i dati della zona servita al momento della raccolta
- Osservazione: risposta ricorsiva pertinente, inclusi stato e TTL; Perché conservarlo: mostra una vista del risolutore e il possibile stato memorizzato nella cache
- Osservazione: Qualsiasi alias o percorso di delega; Perché conservarlo: spiega quali autorità e nomi sono stati coinvolti
- Osservazione: completa registrazione TXT confini; Perché conservarlo: distingue un record multistringa da più criteri candidati
- Osservazione: ora di raccolta UTC e cronologia delle modifiche recenti; Perché conservarlo: mette in relazione i dati attuali con il tempo di valutazione del messaggio
Evitare di conservare solo l'output +breve quando i codici di risposta, le informazioni sull'autorità o l'assenza sono importanti. Utilizzo la guida ai record mancanti per risalire al nome e all'autorità.
Una risposta attuale e autorevole è una prova preziosa, ma non può ricostruire la cache storica di un ricevitore remoto. Dichiara questa lacuna invece di dichiarare che il ricevente deve aver utilizzato la risposta di oggi.
Elaborare una mancata corrispondenza sintetica
Questo caso immaginario mostra perché l'ambito corrispondente è importante:
- Articolo: Checker alle 14:10 UTC; Osservazione catturata: una politica valida per example.com
- Elemento: messaggio non riuscito alle 14:04 UTC; Osservazione acquisita: da alerts@notices.example.com
- Oggetto: Firma del mittente; Osservazione catturata: d=mailer.example.net verifica
- Voce: prove politiche di origine; Osservazione catturata: l'applicazione utilizza un dominio busta controllato dal provider
- Voce: Configurazione del sottodominio; Osservazione acquisita: esiste una policy esplicita per notices.example.com
Il controllo del dominio root non ha stabilito la politica o l'allineamento per quel messaggio. Anche la firma del provider che passa non è correlata al dominio Da in questo esempio. Esaminare la policy del sottodominio e la configurazione allineata supportata dall'applicazione.
Un caso diverso potrebbe rivelare che le identità corrette si sono allineate ma la ricerca della politica richiesta è scaduta; RFC 9989 §5.3.6 non classifica il controllo incompleto come superato o fallito. Lo stesso colore della scacchiera porterebbe quindi a una riparazione diversa.
Mantieni distinte le categorie di risposta DNS
Una risposta riuscita contenente dati rilevanti differisce da NXDOMAIN , una risposta completa senza dati, SERVFAIL , REFUSED e un timeout. Queste osservazioni non significano tutte “no Registro DMARC”. RFC 1035 §4.1.1 definisce i codici di risposta DNS ; RFC 2308 §2.1 E RFC 2308 §2.2 distinguere NXDOMAIN e NODATA .
Controllare il nome richiesto prima di interpretare l'assenza. NXDOMAIN per _dmarc.example.com , senza complicazioni alias, descrive il nome del proprietario richiesto; di per sé non stabilisce che example.com non esista.
Sotto RFC 2308 §5, la memorizzazione nella cache negativa può preservare un'assenza precedente dopo un record viene aggiunto. La memorizzazione nella cache positiva può preservare un valore precedente dopo una modifica. Conservare il contesto della risposta e il tempo di raccolta in modo che la spiegazione possa essere valutata.
Scegli la riparazione dalle prove abbinate
Se lo strumento e il ricevitore hanno esaminato nomi diversi, correggere l'ambito dell'indagine. Se il messaggio non ha un percorso allineato, correggere la configurazione di invio supportata. Se le risposte differiscono tra i server autorevoli, esamina la coerenza delle zone. Se la risoluzione ricorsiva fallisce, ispezionare il risolutore, la delega, la convalida e il percorso di trasporto.
Una modifica della politica non è la riparazione automatica per ogni discrepanza. Modificare la configurazione più piccola rilevante e mantenere il motivo. Utilizzo la guida di allineamento quando l'autenticazione grezza passa per un dominio che non si allinea.
Ripetere un test controllato e chiudere il confronto
Dopo la riparazione, acquisisci nuove osservazioni DNS e un messaggio rappresentativo tramite lo stesso account e percorso dell'applicazione. Confronta il nuovo risultato con il pacchetto precedente e spiega le prove modificate.
Un tentativo riuscito dimostra quel tentativo. Continuare i controlli del livello di servizio definiti quando l'incidente ha coinvolto più percorsi o ricevitori.
La conclusione utile è un resoconto coerente del disaccordo: cosa è stato controllato, cosa ha valutato il ricevente, quale differenza contava e quale riparazione ha cambiato il risultato.
Rendi esplicita la decisione successiva
Per il controllo 14:10 e il dispositivo di messaggio 14:04, allineare prima il dominio dell'autore richiesto e ricostruire le identità del messaggio; non attribuire la differenza di sei minuti alla memorizzazione nella cache senza prove. Gli errori DNS richiesti e la mancanza di allineamento sono risultati diversi. Le risposte obsolete qualificanti possono estendersi oltre la scadenza TTL ai sensi RFC 8767 §4. Le osservazioni illustrate sono fittizie, non registri catturati.