Alavirtaan DMARC pass ei vahvista, että viestin lähettäneellä henkilöllä oli oikeus käyttää sen näkyvää lähettäjää. Engage Securityn joulukuun 2025 LaunDroMARC-tutkimus kuvaa epäsuoran reitin, jossa uudelleenpostittaminen muuttaa arvioiman identiteetin. SPF. Ymmärrä yksittäisiä hyppyjä, ennen kuin kuvailet löydön yleiseksi DMARC ohitukseksi tai oletat, että jokainen Microsoftin vuokralainen käyttäytyy samalla tavalla nykyään.
Erottele kaksi todisteiden lähdettä
Alkuperäinen tutkija kuvailee saapuvaa viestiä, joka läpäisi SPF omalle kirjekuorialueelleen, mutta epäonnistui DMARC ssa jäljiteltyä näkyvää lähettäjäaluetta vastaan. Raportoidussa tapauksessa Microsoft 365 edelleenlähetyspolku kirjoitti kirjekuoren uudelleen edelleenlähetystoimialueeseen, joka myös vastasi näkyvää Lähettäjä-toimialuetta. Lopullinen vastaanotin havaitsi sitten kohdistetun SPF . Tutkijat raportoivat alkuperäisten ja edelleen lähetettyjen kopioiden erilaisen käsittelyn. Nämä ovat heidän tutkimuksensa aiheuttamia havaintoja, eivät tämän tarkastelun yhteydessä tehtyjä havaintoja. Osallistu tietoturvatutkimukseen.
Microsoftin dokumentaatio selittää sen SRS muutoksia POSTIA LÄHETTÄJÄ, ei näkyvää From-kenttää, ja antaa uudelleenkirjoituskuvioita soveltuville edelleenlähetysreiteille. Se myös varoittaa, että SRS ei normaalisti ratkaise DMARC linjaus edelleen lähetetylle postille. Nämä väitteet ovat yhteensopivia tutkimuksen erityisen identiteettisattuman kanssa: tavallisesti alkuperäinen From-alue eroaa välittäjän toimialueesta; ilmoitettu tapaus koskee tarkoituksellisesti samaa aluetta. Microsoft SRS -dokumentaatio.
Ymmärrä loppupään tuomio
Viitteet: RFC 9989 §4.4, RFC 8601 §5.
SPF kysyy, onko yhdistävä isäntä valtuutettu kirjekuoren identiteetille kyseisessä hyppyssä. DMARC vertaa todennettua verkkotunnusta näkyvään Lähettäjä-verkkotunnukseen. Kumpikaan tulos ei yksinään rekonstruoi sitä, kuinka alkuperäinen toimija pääsi edelleenlähetystyönkulkuun. Myöhemmin kohdistettu tulos voi siksi olla oikea arvioiduille identiteeteille, vaikka se ei silti ole riittävä todiste yrityksen toimiluvasta.
Älä tulkitse SRS:n näköistä Return-Path todisteena siitä, että Microsoft on tuottanut sen. Säilytä lopullisen vastaanottajan luotettavat tulokset, vertaistiedot ja viestijäljitys ja vertaa todisteita vastaanotto- ja edelleenlähetysrajoista. Mielivaltainen upotettu Authentication-Results teksti ei ole luotettava tuomio. RFC 8601 selittää luottamusrajavaatimuksen; RFC 9989 tarjoaa toimialueen tasauskontekstin.
Toista vain identiteettivertailu
Yksityisen arvostelupaketin ei-toimitusmalli sisältää kaksi kuvitteellista tapausta. Normaalissa tapauksessa alkuperäinen näkyvä author.test-verkkoalue eroaa uudelleen kirjoitetusta forwarder.test-kuoresta, joten oletettu loppupään SPF passi pysyy kohdistamattomana. Toisessa tapauksessa näkyvä toimialue on forwarder.test; sama uudelleenkirjoitettu kirjekuori nyt kohdistuu. Molemmat alkavat eri alkuperäisellä kirjekuoren verkkotunnuksella, eikä niitä ole tasattu DKIM.
Säilytetyt kalustesyötteet laskettiin uudelleen offline-tilassa 8.11.2026 käyttämällä tätä tarkan verkkotunnuksen vertailua. Se ei lähetä huijauspostia, luo edelleenlähetyssääntöjä, harjoita Exchange Online , käytä SRS-hajautusarvoja tai todista, että nykyinen vuokralainen hyväksyy reitin. Sen tarkoituksena on selittää, miksi nämä kaksi tuomiota eroavat toisistaan ilman, että se toistaa hyökkäystä todellista palvelua vastaan. Toimittajan historiallinen käyttäytyminen, nykyinen vuokralaisen käyttäytyminen ja abstrakti vertailu merkitään erikseen.
Tutki puolustuksellisesti
Varaston valtuutettu ulkoinen edelleenlähetys ja sen yritysten omistajat. Säilytä epäillyn tapahtuman varalta alkuperäiset ja edelleen lähetetyt kopiot, aikaleimat, reititysmenetelmä, välitystä edeltävä todennus ja lopulliset tulokset. Tarkista palveluntarjoajan nykyiset asiakirjat ja viestien jäljitys ennen säännön muuttamista. Microsoft-lähde erottaa sovellettavan edelleenlähetyksen välityspoolista ja paikallisista tapauksista, joten yksi määritysvaatimus ei riitä kattamaan kaikkia polkuja.
Ota muutokset käyttöön organisaation hyväksymän sähköpostin suojausprosessin kautta ja testaa laillisia työnkulkuja jälkeenpäin. Vältä laajoja sallimissääntöjä, jotka perustuvat yksinomaan palveluntarjoajan infrastruktuuriin tai lopputuloksiin. Tässä artikkelissa perustetaan mekanismi ja tutkimuskysymykset. Se ei väitä vahvistamatonta korjauspäivää, yleistä altistumista, onnistunutta hyödyntämistä tai nykyistä Microsoftin palveluvirhettä.