Un messaggio inoltrato può essere legittimo e tuttavia fallire DMARC. L'ultimo server ricevente valuta la connessione e il messaggio che riceve effettivamente, non l'intenzione del mittente o il risultato di una consegna precedente. La domanda utile è quale identità autenticata è ancora in linea con il dominio Da visibile dopo l'hop di inoltro. Preservare questa distinzione prima di considerare un’eccezione politica.
Ricostruire il percorso
Riferimenti: RFC 8601 §1.2, RFC 8601 §5.
Raccogli il messaggio non elaborato originale, il messaggio non elaborato inoltrato, i timestamp, la configurazione di inoltro e i risultati dell'autenticazione generati dal destinatario. Conserva la busta SMTP separata dalle intestazioni visibili: un messaggio salvato non conserva necessariamente la busta utilizzata ad ogni hop. Ottenere prove di tracce dai sistemi responsabili di tali luppoli. Non trattare un mittente inserito Authentication-Results campo come osservazione attendibile del ricevitore. RFC 8601 spiega quel confine.
Etichettare il mittente originale, l'intermediario e il destinatario finale. Quindi registrare l'IP di connessione, il dominio della busta, il dominio visibile dal dominio e ogni DKIM dominio di firma in ciascun punto di valutazione applicabile. Un diagramma del percorso è utile solo se riflette i trasferimenti osservati. Un hop sconosciuto rimane sconosciuto anziché ricevere un risultato di autenticazione presunto.
Identificare il percorso sopravvissuto
Riferimenti: RFC 7208 §2.3, RFC 9989 §4.4, RFC 9989 §5.3.5, RFC 6376 §3.4.
SPF valuta il sistema di connessione rispetto all'identità di una busta. Presso il destinatario finale, un server di inoltro potrebbe trovarsi al di fuori dell'autorizzazione del dominio della busta originale. Un conservato Firma DKIM può comunque fornire un passaggio allineato perché la verifica è legata al messaggio firmato e al dominio di firma. La riscrittura del contenuto può rimuovere quel percorso rimanente. DMARC necessita di un risultato autenticato allineato, non semplicemente di qualsiasi passaggio SPF o DKIM . RFC 9989, RFC 7208 E RFC 6376 definire questi controlli separati.
Una busta riscritta da SRS può superare SPF per il dominio dello spedizioniere senza allinearsi con il dominio Da dell'autore originale. Una nuova firma da parte dello stesso spedizioniere presenta la limitazione analoga. Nessuna delle due osservazioni significa che il messaggio è necessariamente dannoso e nessuna delle due ripara automaticamente l'autenticazione allineata dell'autore.
Esegui l'esempio limitato
Riferimenti: RFC 9989 §4.4, RFC 9989 §5.3.5.
Il modello di allineamento rigoroso mantenuto può essere controllato separatamente dall'acquisizione SMTP . Il caso diretto fornisce pass SPF e DKIM allineati. Il caso di inoltro preservato fornisce il fallimento SPF e il successo DKIM allineato, quindi il modello di allineamento rigoroso continua a passare. Il caso del piè di pagina fornisce errori per entrambi i percorsi e fallisce. IL SRS i casi isolano come un’identità SPF di successo ma non allineata non cambi nulla di questo ragionamento.
Questi valori booleani sono input deliberati, non risultati di query DNS in tempo reale o di verifica della firma crittografica. I messaggi grezzi generati sono sintetici e non sono mai stati ricevuti. Illustrano un cambiamento del corpo controllato ma non soddisfano il requisito di messaggi realmente originali e inoltrati con risultati affidabili. La sezione conservata del laboratorio SMTP di seguito fornisce prove storiche ricevute a livello locale; le prove della produzione esterna rimangono aperte.
Riparare la causa ristretta
Riferimenti: RFC 9989 §7.4.
Chiedi all'intermediario di preservare i contenuti firmati ove possibile e di verificare il posizionamento della firma nel servizio di origine. Testare un percorso autorizzato rappresentativo prima di modificare la politica del dominio ampio. Se un destinatario applica un'eccezione locale, mantieni i requisiti di ambito, proprietario, scadenza e filtro indipendente. La consegna in base a un'eccezione non è un pass DMARC .
Chiudere l'indagine solo quando il percorso perduto, il cambiamento apportato e la decisione del destinatario osservata sono documentati separatamente. Ritestare i flussi di lavoro periodici e a basso volume, nonché l'ovvio percorso quotidiano. Un passaggio a livello di organizzazione al monitoraggio semplicemente per nascondere un difetto di inoltro può ridurre la protezione per la posta non correlata senza correggere l'intermediario.
Conservazione delle prove di laboratorio SMTP
Riferimenti: RFC 7208 §4, RFC 6376 §6.
L'acquisizione conservata datata 7 novembre 2026 alle 21:29:16 UTC registra che il ricevitore di loopback ha acquisito messaggi diretti, con inoltro preservato e modificati nel piè di pagina sull'effettivo SMTP . Ha osservato il peer 127.0.0.2 per la connessione di origine e 127.0.0.3 per la connessione di inoltro. pyspf ha valutato quegli IP rispetto DNS di dispositivi isolati; dkimpy ha verificato le firme RSA effettive. Il caso diretto ha superato entrambi i controlli, la copia inoltrata conservata non ha superato SPF ma ha superato DKIM allineato e la copia del piè di pagina non ha superato entrambi i controlli. Authentication-Results generati dal destinatario e i messaggi non elaborati completi vengono conservati insieme alle buste e ai valori SHA-256.
Per questa revisione sono stati controllati il runner storico e i messaggi conservati; l'esperimento di rete non è stato ripetuto. La sua esecuzione originale utilizzava solo il loopback e non inviava posta Internet. Il suo ricevitore crea Authentication-Results dai propri controlli, fornendo a quei campi la provenienza nota del laboratorio. Il risultato e la disposizione dell'autenticazione rimangono separati: tutti e sei i campioni SMTP ne ricevono 250 in base a una politica di acquisizione esplicita, inclusi i campioni non riusciti. Il confine di fiducia è questo laboratorio controllato, non un fornitore di cassette postali di produzione. L'adattatore DNS fornisce risposte fisse conservate anziché interrogare DNS pubblico e il valutatore DMARC utilizza solo la rigorosa uguaglianza del dominio. L'individuazione completa del dominio organizzativo, l'analisi delle policy di produzione e i risultati della distribuzione in tempo reale non sono ancora stati testati.