Classificeer de route voordat u beslist wat er is mislukt
Een ontvanger kan e-mail rechtstreeks zien van een oorspronkelijke dienst, na een doorstuursprong of nadat een mailinglijst deze heeft gewijzigd. Een bron-IP en authenticatiefout maken op zichzelf geen onderscheid tussen deze paden en imitatie. De onderzoeker moet het gerapporteerde resultaat verbinden met een bepaalde route en de onzekerheid behouden waar de route ontbreekt. Anders kan een reparatie bedoeld voor een legitieme afzender niet-gerelateerde infrastructuur autoriseren.
Deze gids maakt gebruik van RFC 9989 En RFC 9990 vanaf mei 2026, SPF RFC 7208 en het experimentele ARC specificatie RFC 8617 . De richtlijnen voor aanbieders zijn op 8 november 2026 herzien. Alle routevoorbeelden zijn fictieve papieren cases. Er is geen bericht verzonden, geïmporteerd of geverifieerd, er is geen DNS query uitgevoerd en er is geen instelling voor doorsturen of vertrouwen van de ontvanger gewijzigd.
Definieer direct verzenden ten opzichte van de ontvangstgrens
Voor dit onderzoek betekent direct zenden dat de beoogde uitgaande dienst op de ontvangende grens aflevert zonder dat er een doorstuurdienst op de onderzochte route tussenbeide komt. Het betekent niet dat de oorspronkelijke organisatie slechts één interne server gebruikt. Interne relais en uitgaande gateways kunnen voorafgaan aan de waargenomen verbinding, dus noteer de grens die wordt gebruikt bij het toepassen van het label.
RFC 7208 evalueert een verbindende host op basis van een gedefinieerde SMTP identiteit. Bij een directe route kan een storing wijzen op een configuratieprobleem, een onverwacht pad of ongeautoriseerd gebruik. Het is niet voldoende om de oorzaak alleen op basis van het resultaat te benoemen. Bewaar het geëvalueerde domein, de verbindingscontext en de foutstatus voordat u een wijziging in de autorisatie voorstelt.
Leg uit waarom doorsturen het SPF bewijs kan veranderen
Wanneer een expediteur een origineel bericht doorstuurt, ziet de volgende ontvanger het verbindingsadres van de expediteur. Als de oorspronkelijke identiteit van de envelop behouden blijft, wordt dat adres mogelijk niet geautoriseerd door het SPF beleid van het oorspronkelijke domein. Als de envelop wordt herschreven, kan SPF in plaats daarvan de identiteit van de expediteur verifiëren. Geen van beide omstandigheden biedt automatisch een uitgelijnd SPF pad voor het oorspronkelijke zichtbare Van-domein eronder RFC 9989.
Dat is de reden waarom het toevoegen van elke waargenomen forwarder aan de SPF van het oorspronkelijke domein geen goede standaardreactie is. Het kan de autorisatie verbreden zonder de daadwerkelijke route of het andere authenticatiepad aan te pakken. Stel eerst vast of er sprake is van doorzending, of de ontvanger dit verwachtte en welke identiteiten zijn gewijzigd. Een doorstuurachtig patroon is een hypothese totdat representatief routebewijs dit ondersteunt.
Onderzoek of de originele DKIM handtekening bewaard is gebleven
Een bericht kan een geldige uitlijning behouden DKIM -handtekening door doorzending als het ondertekende materiaal compatibel blijft met verificatie. RFC 6376 definieert wat de handtekening omvat en hoe deze wordt gecontroleerd. Wijzigingen in ondertekende kopteksten of hoofdtekst kunnen die handtekening verbreken; alleen het verplaatsen van het bericht via een andere server betekent niet noodzakelijkerwijs dat dit ook het geval is. Generaliseer niet van één expeditieproduct naar alle routes.
Een mailinglijst kan de inhoud wijzigen, een voettekst toevoegen of het bericht anderszins transformeren voordat het opnieuw wordt verspreid. Een nieuwe geldige handtekening uit de lijst kan het domein van de lijst authenticeren, terwijl deze niet op één lijn blijft met het oorspronkelijke Van-domein. Een gerapporteerd DKIM Pass heeft daarom zijn handtekeningidentiteit nodig en uitlijning context. Het kan niet worden gelezen als bewijs dat het domein van de oorspronkelijke auteur is verstreken DMARC.
Gebruik ARC als bewijs wiens vertrouwen nog steeds een beslissing nodig heeft
RFC 8617 is een experimenteel protocol voor het uitvoeren van authenticatiebeoordelingen tijdens de stappen voor het verwerken van berichten. ARC ketenvalidatie en vertrouwen in de sealpartijen zijn aparte vragen. Een cryptografisch geldige keten maakt de boodschap niet veilig en garandeert niet dat elke zeehondenjager betrouwbaar is. Een ontbrekende of kapotte ketting bewijst ook niet dat het bericht vervalst is.
Ontvangers kunnen ARC informatie gebruiken bij lokale beschikkingsbesluiten. Herschrijf dat niet in een universele regel dat ARC een onderliggende SPF of DKIM uitlijningsfout omzet in een protocolpassage. Bewaar de waargenomen authenticatieresultaten en eventuele gerapporteerde beleidsoverschrijvingen afzonderlijk. RFC 9990 onderscheidt door DMARC geëvalueerde velden van onbewerkte authenticatieresultaten en biedt context voor rapportage over beleidsoverschrijvingen. Ontvangeracceptatie en authenticatieresultaat blijven verschillende feiten.
Vergelijk vier fictieve paden zonder te overclassificeren
De ingehouden papieren oefening contrasteert vier mogelijkheden: een beoogde directe dienst; een ongewijzigde expediteur met behoud van de afgestemde DKIM ; een wijzigingslijst waarvan de originele handtekening niet langer geldig is; en een afzender die het Van-domein nabootst zonder een bekende geautoriseerde route. Dit zijn verklarende alternatieven, geen vier geteste berichten. Er is geen echte host, account of bedrijfseigenaar aan hen toegewezen.
De eerste drie mogelijkheden vereisen routespecifieke configuratie en berichtbewijs voordat ze kunnen worden behandeld als legitiem waargenomen verkeer. De vierde blijft verdacht spoofen totdat het beschikbare bewijsmateriaal en de veiligheidsbeoordeling deze classificatie ondersteunen. Een authenticatiefout alleen kan het geval van de wijzigingslijst niet onderscheiden van imitatie. Omgekeerd kan het passeren van authenticatie geen goedaardige inhoud of een momenteel goedgekeurd zakelijk doel opleveren.
Respecteer de feitelijke vertrouwensconfiguratie van de ontvanger
Die van Microsoft vertrouwde ARC sealerbegeleiding is een providerspecifiek voorbeeld: het beschrijft het selecteren van legitieme, vereiste tussenpersonen voor het ontvangstgedrag Microsoft 365 . Er wordt geen universele toelatingslijst, het beleid van een andere provider of de configuratie van een klanttenant vastgelegd. Dit ontwerp voegt geen zeehondenjager toe en raadt ook niet aan om een tussenpersoon te vertrouwen louter omdat de naam bekend is.
Bewaar voor toekomstig onderzoek het representatieve bericht, de vertrouwde ontvangsttracering, de relevante serviceconfiguratie en de verwachte route van de ontvanger. Authentication-Results velden moeten worden geïnterpreteerd binnen een vastgestelde ontvangende vertrouwensgrens, zoals RFC 8601 legt uit. Een niet-vertrouwde gekopieerde header kan alles beweren. Zorg ervoor dat de openbaarmaking van berichten, wijzigingen in de beveiliging van de ontvanger en productie DNS acties afhankelijk zijn van hun eigen menselijke goedkeuring.
Vereist een geobserveerde route voordat u de remedie bewezen noemt
De exacte inlaatpoort blijft open: valideer de huidige primaire specificaties en bewaar een uitgewerkt voorbeeld voordat u het opstelt. Primaire bronnen en fictieve vergelijkingen zijn behouden, maar het in opdracht gegeven originele bewijsmateriaal ontbreekt nog steeds: een route-naar-vereiste-kaart met actueel bewijsmateriaal van de leverancier en een gecontroleerde testboodschap.
Een eventuele gecontroleerde test moet gebruik maken van een goedgekeurde ontvanger en route, de relevante diagnostiek behouden en onderscheid maken tussen levering, authenticatie en afhandeling van lokaal beleid. Het moet de specifieke onzekerheid aanpakken in plaats van universele doorstuurcompatibiliteit te beloven. Bewaar de classificatie van de kandidaat en de volgende onderzoeksstap totdat dat bewijs bestaat. Claim geen succesvolle oplossing, bevestigde spoofing of een goedgekeurde afzender op basis van de documentaire voorbeelden alleen.