A Firma DKIM può verificare correttamente il dominio di un provider senza autenticare il dominio che un lettore vede in Da. Rapporti aggregati preservare entrambi gli strati. Leggere l'identità grezza della firma e il risultato prima di interpretare il file relativo a DKIM DMARC risultato.
Inizia con ogni firma riportata
Riferimenti: RFC 9990 §3.1.1.12, RFC 9990 §3.1.3.
In auth_results/dkim, RFC 9990 identifica il dominio firma, selettore e risultato della verifica. Il dominio corrisponde a d nella DKIM-Signature e il selettore a s. Né un nome visualizzato descrittivo né l'etichetta del selettore sostituiscono il dominio di firma allineamento.
I messaggi possono contenere più firme. Uno può fallire dopo la modifica del contenuto mentre un altro verifica, oppure entrambi possono verificare in domini diversi. Esamina i singoli risultati anziché selezionare la prima firma visualizzata dall'interfaccia. I rapporti possono limitare il numero di firme che includono, quindi l'assenza da un record aggregato non è sempre la prova che una firma non sia mai esistita.
Confronta il dominio della firma con Da
Riferimenti: RFC 9989 §4.4.1, RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
DMARC utilizza il dominio dell'autore dal campo Da visibile e il dominio di una firma DKIM verificata correttamente. L'allineamento rigoroso richiede una corrispondenza esatta del dominio. L'allineamento rilassato utilizza la relazione definita dall'individuazione del dominio organizzativo in base alle regole applicabili. L'identità i in una firma non sostituisce d per questo confronto.
Una firma il cui dominio è allineato ma il cui controllo crittografico fallisce non fornisce un passaggio DKIM sentiero. Al contrario, una firma valida proveniente da un dominio non correlato rimane non allineata. Il campo policy_evaluated/dkim rappresenta la valutazione relativa a DMARC, non semplicemente se una firma è stata verificata.
Riprodurre il risultato in un esempio sintetico
Riferimenti: RFC 9989 §5.3.5.
Presupporre una policy valida applicabile, controlli completati, domini organizzativi brand.example / vendor.example non correlati e header_from= brand.example . La firma uno utilizza d=vendor.example e verifica. La firma due utilizza d=brand.example e non supera il controllo dell'hash del corpo. In questo esempio non esiste un percorso DKIM allineato con successo, quindi un errore della policy relativa a DKIM è coerente con il passaggio non elaborato della firma.
Ora cambia il risultato della firma due in Passa mantenendo le stesse identità. Tale firma fornisce un allineamento esatto, quindi il percorso DKIM può soddisfare DMARC indipendentemente dal risultato della firma non correlata. Questi sono casi costruiti, non misurazioni reali del ricevitore. Ispezionare SPF anche prima di determinare il risultato DMARC complessivo nel primo caso.
Riparare la verifica e l'allineamento separatamente
Riferimenti: RFC 6376 §6.1, RFC 9989 §5.4.
In caso di errore di verifica, indagare sulla chiave della firma segnalata, sulla copertura del contenuto e sull'effettiva elaborazione del messaggio. Un difetto di body-hash non viene riparato semplicemente modificando l'indirizzo del mittente. Per una firma del provider verificata ma non allineata, stabilisci se il servizio supporta un dominio di firma personalizzato o un altro percorso allineato.
Non dare per scontato che l'aggiunta di una firma aggiuntiva ne ripari una precedente. Crea un altro percorso valutato in modo indipendente. La domanda utile è se almeno una firma valida e supportata è allineata, non se ogni possibile firma viene superata.
Conserva i campioni grezzi e i risultati dei ricevitori affidabili quando risolvi prove aggregate ambigue. Registra il dominio d, il selettore, il risultato della verifica, la modalità di allineamento e il dominio dell'autore per ciascun percorso testato. Mantieni le disposizioni separate: il successo dell'autenticazione non garantisce la consegna e un'eccezione di gestione del destinatario non trasforma una firma non riuscita in una valida.
Conservare il confronto tra firme multiple
Due mappe sintetiche parziali utilizzano header_from= brand.example , policy p=reject, allineamento rilassato e intervallo epocale 1704067200–1704153600. Entrambi hanno un pass SPF non elaborato per vendor.example non correlato, quindi nessuno dei due ha allineato SPF . Il primo prevede che il passaggio DKIM vendor.example /v1 e il DKIM brand.example /b1 falliscano. Il risultato DKIM allineato e il risultato DMARC complessivo non riescono. Il secondo ha il fallimento vendor.example /v1 e il passaggio brand.example /b1. I risultati DKIM allineati e DMARC complessivi sono superati.
L'esercizio di identità locale fornito riproduce questi risultati e mantiene i selettori attaccati a ciascuna firma. Il modello presuppone i risultati della verifica forniti; non ricalcola le firme né testa DNS . Entrambe le mappe rappresentano 25 osservazioni ciascuna, non un campione di traffico misurato. Il loro campo di disposizione rimane un contesto di reporting fornito anziché una garanzia di consegna calcolata. Utilizza messaggi non elaborati effettivi per convalidare questa catena per un percorso di produzione.
Mantieni l'esercizio entro l'ambito
Gli esempi sono proiezioni parziali del campo, non report validi per lo schema o traffico misurato. I controlli locali utilizzano risultati di autenticazione e relazioni organizzative forniti esplicitamente; non eseguono il rilevamento DNS , la valutazione SPF , la verifica crittografica, l'acquisizione di report o i test di consegna del ricevitore. Conserva il report originale e le prove del messaggio attendibile prima di apportare una modifica alla produzione.