Una valle DMARC pass non stabilisce che la persona che ha avviato un messaggio fosse autorizzata a utilizzare il suo mittente visibile. La ricerca LaunDroMARC di dicembre 2025 di Engage Security descrive un percorso indiretto in cui il remailing modifica l'identità valutata da SPF. Comprendere i singoli hop prima di descrivere il risultato come un bypass DMARC universale o presupporre che ogni tenant Microsoft si comporti allo stesso modo oggi.
Separare le due fonti di prova
Il ricercatore originale descrive un messaggio in entrata che ha superato SPF per il proprio dominio busta ma non ha superato DMARC rispetto al dominio Da visibile imitato. Nel caso segnalato, un percorso di inoltro Microsoft 365 ha riscritto la busta nel dominio di inoltro, che corrispondeva anche al dominio Da visibile. Il ricevitore finale ha quindi osservato SPF allineato. I ricercatori segnalano un trattamento diverso delle copie originali e inoltrate. A questi vengono attribuiti i risultati della loro indagine, non le osservazioni fatte per questa revisione. Coinvolgere la ricerca sulla sicurezza.
La documentazione di Microsoft lo spiega SRS cambiamenti MAIL DA, non il campo Da visibile e fornisce modelli di riscrittura per i percorsi di inoltro applicabili. Avverte inoltre che SRS normalmente non risolve DMARC allineamento per la posta inoltrata. Queste affermazioni sono compatibili con la speciale coincidenza dell'identità della ricerca: normalmente il dominio From originale differisce dal dominio dell'inoltro; il caso segnalato coinvolge deliberatamente lo stesso dominio. Documentazione di Microsoft SRS.
Comprendere il verdetto a valle
Riferimenti: RFC 9989 §4.4, RFC 8601 §5.
SPF chiede se l'host che si connette è autorizzato per l'identità della busta in quell'hop. DMARC confronta un dominio autenticato con il dominio Da visibile. Nessuno dei due risultati, da solo, ricostruisce il modo in cui l'attore originale ha ottenuto l'accesso a un flusso di lavoro di inoltro. Un risultato allineato a valle può quindi essere corretto per le identità valutate pur essendo una prova inadeguata dell’autorizzazione commerciale.
Non interpretare un aspetto SRS Return-Path come prova che Microsoft lo ha prodotto. Conserva i risultati attendibili del destinatario finale, le informazioni sui peer e la traccia dei messaggi e confronta le prove dai confini di ricezione e inoltro. Incorporato arbitrario Authentication-Results il testo non è un verdetto attendibile. RFC 8601 spiega il requisito del limite di fiducia; RFC 9989 fornisce il contesto di allineamento del dominio.
Riprodurre solo il confronto delle identità
Il modello di mancata consegna del pacchetto di revisione privata contiene due casi fittizi. Nel caso normale, il dominio originale autore.test visibile differisce dalla busta forwarder.test riscritta, quindi il passaggio SPF downstream presunto rimane non allineato. Nel secondo caso il dominio visibile è forwarder.test; la stessa busta riscritta ora è allineata. Entrambi iniziano con un dominio della busta originale diverso e non allineato DKIM.
Gli input degli incontri conservati sono stati ricalcolati offline l'8 novembre 2026 utilizzando questo confronto del dominio esatto. Non invia posta contraffatta, non crea regole di inoltro, non esercita Exchange Online , non implementa hash SRS né dimostra che un tenant attuale accetta il percorso. Il suo scopo è quello di spiegare perché i due verdetti differiscono senza riprodurre un attacco contro un servizio reale. Il comportamento storico del fornitore, il comportamento attuale del locatario e il confronto astratto rimangono etichettati separatamente.
Indagare sulla difensiva
Inventario autorizzato spedizioni esterne e relativi titolari dell'azienda. Per un sospetto incidente, conservare le copie originali e inoltrate, i timestamp, il metodo di instradamento, l'autenticazione pre-inoltro e i risultati finali. Esaminare la documentazione corrente del provider e la traccia dei messaggi prima di modificare una regola. La fonte Microsoft distingue l'inoltro applicabile dai casi del pool di inoltro e locali, quindi una singola attestazione di configurazione non è sufficiente per coprire ogni percorso.
Applica le modifiche attraverso il processo di sicurezza della posta approvato dall'organizzazione e successivamente testa i flussi di lavoro legittimi. Evitare regole di autorizzazione generali basate esclusivamente sull'infrastruttura del fornitore o sui risultati del passaggio a valle. Questo articolo stabilisce il meccanismo e le domande di indagine. Non afferma una data di riparazione non verificata, un'esposizione universale, uno sfruttamento riuscito o un difetto attuale del servizio Microsoft.