Un sistema di posta può segnalare SPF passare e DKIM passare mentre DMARC fallisce ancora. Questo risultato non è contraddittorio. Ogni meccanismo inizia con un'identità diversa e DMARC aggiunge un test di relazione tra un'identità passata e il dominio nell'indirizzo Da del messaggio.
Il modo affidabile per indagare su un messaggio è registrare la catena di identità prima di modificare DNS . Inizia con il dominio che il destinatario vede in Da. Quindi registra il dominio utilizzato per SPF e ogni dominio trovato in a Firma DKIM. Solo dopo dovresti valutare allineamento e il risultato DMARC a livello di messaggio.
Dai un nome alle tre identità prima di leggere i risultati
Considera questo messaggio immaginario:
Da: Team di fatturazione < statements@billing.example.com > Return-Path : < bounce+739@mailer.example.net > DKIM-Signature : ... d=billing.example.com; s=outbound1; ...Il dominio Da è billing.example.com. DMARC lo chiama dominio dell'autore. IL mittente della busta è rappresentato qui da Return-Path dominio mailer.example.net; per il controllo MAIL FROM di questo messaggio ordinario, ovvero l'identità con cui SPF valuta RFC 7208 §2.4. Un separato HELO il controllo può avvenire anche sotto RFC 7208 §2.3; La gestione Return-Path è specificata in RFC 5321 §4.4. Il valore del dominio di firma DKIM è d=, che è billing.example.com in questo esempio.
Un nome visualizzato come Team di fatturazione non è un'identità di autenticazione. Anche Reply-To non è il dominio dell'autore. Questi campi possono essere importanti per un'indagine antifrode, ma non sostituiscono i domini confrontati DMARC .
Registrare i risultati e l'allineamento separatamente
Un passaggio SPF non elaborato indica che l'origine della connessione è stata autorizzata per l'identità SPF valutata. Un passaggio DKIM non elaborato indica una firma verificata per il suo d= dominio e il materiale del messaggio coperto. Nessuno dei due risultati, di per sé, dice che il suo dominio abbia la relazione richiesta con From.
DMARC necessita quindi di due colonne per ciascun percorso:
- Percorso: SPF ; Domanda di autenticazione: SPF è passato per l'identità della busta valutata?; Domanda di allineamento: quell'identità è in linea con il dominio dell'autore?
- Percorso: DKIM ; Domanda di autenticazione: questa firma è passata per il suo dominio d=?; Domanda di allineamento: il dominio d= è in linea con il dominio dell'autore?
Sotto RFC 9989 §3.2.10.2, l'allineamento rigoroso richiede l'esatta uguaglianza del dominio. Sotto RFC 9989 §4.10.2, l'allineamento rilassato utilizza la relazione di individuazione del dominio organizzativo applicabile. Non approssimare quel confine prendendo le ultime due etichette, perché le regole pubbliche sui suffissi possono rendere sbagliata quella scorciatoia.
Lavorare attraverso un passaggio e un passaggio grezzo fuorviante
Quello che segue è un esempio didattico sintetico, non un messaggio per il cliente. Presupporre una politica valida applicabile, controlli completati, risultati di ricezione attendibili e modalità di allineamento note; RFC 9989 §5.3.5 definisce la regola pass/fail risultante.
- Osservazione: Da; Messaggio A: alerts@example.com ; Messaggio B: alerts@example.com
- Osservazione: risultato SPF ; Messaggio A: Passa per bounce.vendor.example.net ; Messaggio B: Passa per bounce.vendor.example.net
- Osservazione: SPF allineato?; Messaggio A: No; Messaggio B: no
- Osservazione: risultato DKIM ; Messaggio A: Passa con d=example.com; Messaggio B: Passa con d=vendor.example.net
- Osservazione: allineato DKIM ?; Messaggio A: Sì; Messaggio B: no
- Osservazione: DMARC a livello di messaggio; Messaggio A: Passa attraverso DKIM ; Messaggio B: Fallito
Il messaggio A supera DMARC perché una firma DKIM verifica e allinea. Il suo risultato SPF non allineato non annulla quel percorso valido. Il messaggio B ha due passaggi di autenticazione non elaborati, ma nessuno dei due domini autenticati è allineato con il dominio dell'autore, quindi non esiste alcun percorso DMARC di passaggio.
Questa tabella è anche un utile record di modifiche. Mostra se la riparazione appartiene all'identità della busta, alla configurazione della firma o al dominio Da visibile. Un'icona verde senza questi domini non è una prova sufficiente per autorizzare una modifica DNS .
Ispeziona ogni firma DKIM
Un messaggio può contenere più di una firma DKIM . Un servizio in uscita, un gateway e un intermediario possono aggiungerne uno ciascuno. Valuta ogni firma in modo indipendente. Una firma di passaggio allineata può fornire il percorso DKIM anche quando un'altra firma non è allineata o non funziona.
Non dedurre il selettore dal nome di un fornitore. Leggi il s= valore dall'intestazione DKIM-Signature effettiva, combinalo con quella firma d= dominio ed eseguire una query sul nome DNS risultante in RFC 6376 §3.6.2.1. La pubblicazione di una chiave rende disponibile solo il materiale di verifica. Il sistema mittente deve comunque creare una firma valida con la corrispondente chiave privata.
La posta indiretta può alterare il contenuto firmato o il percorso della busta. L'inoltro può quindi influire su SPF , mentre le modifiche all'elenco possono influire su DKIM . Tratta il percorso osservato come una prova su cui indagare, non come una prova che il mittente o l'intermediario originale fosse dannoso.
Utilizzare prove di ricezione attendibili
Authentication-Results può riassumere le identità e i risultati, ma la fiducia dipende da dove è stata aggiunta l'intestazione. Un mittente può inserire un'intestazione che attesti l'esito positivo. Sotto RFC 8601 §7.1, utilizza il risultato prodotto dal sistema ricevente che amministri o un altro confine di cui comprendi la gestione.
Se il messaggio è stato rifiutato prima della consegna, è possibile che non esista una copia consegnata. Utilizza la risposta di rifiuto, i log del provider e tutti i dati di telemetria di ricezione disponibili. Non inventare identità mancanti solo da un codice di errore.
Trasforma la catena di identità in un record operativo
Per ogni mittente materiale conservare:
- il proprietario dell'azienda e l'applicazione;
- i domini From di cui è autorizzato l'utilizzo;
- l'identità dell'involucro osservato;
- ogni DKIM osservato d= dominio e selettore;
- il risultato dell'autenticazione per ciascun percorso;
- la modalità di allineamento e la conclusione;
- una data rappresentativa del test e un identificatore del messaggio.
Tale registrazione separa l'autorizzazione commerciale dalle prove del protocollo. Inoltre previene un errore comune: cambiare la radice dell'organizzazione Registro SPF per risolvere un problema di allineamento DKIM o modificare la policy DMARC quando la configurazione del mittente è il vero difetto.
Una volta chiara la catena di identità, utilizzare il file guida alla risoluzione dei problemi di allineamento per riparare un percorso fallito e il inventario del mittente assegnare la proprietà.
Mantieni la conclusione all'interno delle prove
Per il messaggio A, scrivi SPF superato/non allineato e DKIM superato/allineato come fatti separati. Per B, non convertire due passaggi grezzi non correlati in un passaggio DMARC . Conserva ogni firma in modo indipendente e non dedurre l'identità SMTP esclusivamente dal nome visualizzato. Questi casi e la firma abbreviata sono esempi didattici, non materiale di firma valido o verifica eseguita.