UN SPF pass risponde se un IP di invio è stato autorizzato per l'identità SPF valutata. DMARC pone un'ulteriore domanda: l'identità autenticata è in linea con il dominio in From? UN rapporto aggregato può quindi mostrare un passaggio SPF non elaborato e un errore DMARC relativo a SPF senza contraddirsi.
Identificare il dominio SPF autenticato
Riferimenti: RFC 9990 §3.1.1.13, RFC 7208 §2.4, RFC 9989 §4.4.2.
Leggi auth_results/spf/domain e il risultato insieme. Ispeziona gli identificatori/header_from, qualsiasi busta_da e l'ambito riportato. Non dare per scontato che SPF abbia controllato il dominio Da visibile. RFC 7208 definisce il MAIL DA identità, mentre RFC 9989 utilizza tale identità per il contributo di SPF a DMARC .
Per un percorso inverso nullo, SPF definisce un'identità MAIL FROM utilizzando postmaster nel file HELO dominio. Questo caso speciale non dovrebbe diventare una regola secondo cui qualsiasi pass HELO indipendente soddisfa DMARC . Attuale RFC 9990 i permessi di reporting rientrano nell'ambito SPF ; i formati di report legacy possono esporre campi diversi e necessitano di un'interpretazione esplicita.
Applicare la modalità di allineamento corretta
Riferimenti: RFC 9989 §3.2.10.2, RFC 9989 §4.10.2, RFC 9990 §3.1.1.9.
SPF rigoroso allineamento richiede che il dominio autenticato corrisponda esattamente al dominio dell'autore. Un allineamento rilassato consente la relazione definita attraverso le regole di dominio organizzativo applicabili. Non calcolatelo semplicemente rimuovendo un numero fisso di etichette: i dettagli relativi al suffisso pubblico e all’individuazione delle politiche contano.
Il valore SPF in row/policy_evaluated esprime il risultato relativo a DMARC, non un duplicato del risultato SPF non elaborato. Un fallimento o un errore non possono diventare un percorso SPF riuscito solo perché i nomi di dominio si somigliano. L'autenticazione deve riuscire e allinearsi.
Lavora attraverso due file contrastanti
Riferimenti: RFC 9989 §5.3.5.
Presumi policy valide applicabili, controlli completati e domini organizzativi non correlati per brand.example e vendor.example . La riga sintetica A utilizza header_from= brand.example , MAIL FROM= vendor.example e SPF non elaborato =pass. L'identità non correlata non si allinea, quindi è previsto policy_evaluated/ spf=fail . L'aggiunta dell'IP di un fornitore SPF di brand.example non modifica l'identità effettivamente valutata da questo percorso.
La riga sintetica B utilizza header_from= brand.example e MAIL FROM= bounce.brand.example con SPF non elaborato =pass. Supponiamo che il rilevamento del dominio organizzativo applicabile li collochi insieme. L'allineamento SPF rilassato può passare, mentre l'allineamento SPF rigoroso fallisce perché i nomi differiscono. Queste sono partite illustrative sul campo, non traffico osservato.
Per entrambe le righe, ispezionare allineate DKIM prima di concludere che DMARC nel suo insieme ha fallito. Un passaggio allineato Firma DKIM può fornire il percorso DMARC corretto indipendentemente da SPF .
Scegli una riparazione che modifichi il livello danneggiato
Riferimenti: RFC 7208 §10.3.
Se SPF non elaborato fallisce, esamina l'autorizzazione e il percorso di connessione per il dominio effettivamente valutato. Se SPF non elaborato passa ma non si allinea, esamina una configurazione MAIL FROM personalizzata supportata o un altro percorso di autenticazione allineato. Non continuare ad aggiungere IP a domini non correlati Registro SPF.
Conferma le modifiche controllando la posta ricevuta e riportando successivamente le prove, preservando i risultati grezzi e allineati. L'inoltro può modificare l'IP di connessione, quindi testa i percorsi pertinenti ed evita di considerare SPF da solo come garanzia di consegna. Chiudere l'indagine con l'identità valutata, la modalità di allineamento e il risultato dimostrato.
Conservare i casi di test grezzi-allineati
Quattro mappe sintetiche parziali condividono header_from= brand.example , policy p=reject e intervallo epocale 1704067200–1704153600. A utilizza MAIL FROM= vendor.example con pass SPF non elaborato e nessuna firma DKIM : SPF e DMARC allineati non riescono. B utilizza MAIL FROM= bounce.brand.example con passaggio SPF non elaborato e senza DKIM : in un dominio organizzativo condiviso esplicitamente assunto, la modalità rilassata supera l'allineamento SPF e DMARC . Lo stesso input B in modalità rigorosa fallisce entrambi. Un quarto caso ripristina l'identità SPF non correlata di A ma aggiunge il passaggio di DKIM per brand.example /selector billing1: DMARC passa attraverso DKIM .
L'esercizio di identità locale fornito riproduce tutti e quattro i risultati dalle identità, dai risultati e dalle modalità di allineamento forniti. Utilizza una mappa esplicita del dominio organizzativo, non un'implementazione del percorso ad albero DNS . Inoltre non verifica un vero messaggio di percorso inverso nullo; la guida al percorso nullo sopra è basata sulle specifiche. Il comportamento effettivo del fornitore e del destinatario necessita ancora della prova del messaggio ricevuto.
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.