Een doorgestuurd bericht kan legitiem zijn en toch mislukken DMARC. De laatste ontvangende server evalueert de verbinding en het bericht dat hij daadwerkelijk ontvangt, niet de intentie van de afzender of het resultaat van een eerdere bezorging. De nuttige vraag is welke geauthenticeerde identiteit na de doorstuursprong nog steeds overeenkomt met het zichtbare Van-domein. Behoud dat onderscheid voordat u een beleidsuitzondering overweegt.
Reconstrueer de route
Referenties: RFC 8601 §1.2, RFC 8601 §5.
Verzamel het originele onbewerkte bericht, het doorgestuurde onbewerkte bericht, tijdstempels, doorstuurconfiguratie en door de ontvanger gegenereerde authenticatieresultaten. Houd de SMTP envelop gescheiden van de zichtbare headers: een opgeslagen bericht bewaart niet noodzakelijkerwijs de envelop die bij elke hop wordt gebruikt. Verkrijg sporen van de systemen die verantwoordelijk zijn voor deze hop. Behandel een ingevoegde afzender niet Authentication-Results veld als een vertrouwde ontvangerobservatie. RFC 8601 verklaart die grens.
Label de oorspronkelijke afzender, tussenpersoon en uiteindelijke ontvanger. Noteer vervolgens het verbindende IP-adres, het envelopdomein, het zichtbare Van-domein en elke DKIM ondertekeningsdomein op elk toepasselijk evaluatiepunt. Een routediagram is alleen nuttig als het waargenomen transfers weergeeft. Een onbekende hop blijft onbekend in plaats van dat er een verondersteld authenticatieresultaat aan wordt toegewezen.
Identificeer het overgebleven pad
Referenties: RFC 7208 §2.3, RFC 9989 §4.4, RFC 9989 §5.3.5, RFC 6376 §3.4.
SPF beoordeelt het verbindingssysteem op basis van een envelopidentiteit. Bij de uiteindelijke ontvanger kan een doorstuurserver zich buiten de autorisatie van het oorspronkelijke envelopdomein bevinden. Een bewaard gebleven DKIM -handtekening kan nog steeds een uitgelijnde pas opleveren omdat verificatie is gekoppeld aan het ondertekende bericht en het ondertekeningsdomein. Het herschrijven van inhoud kan dat resterende pad verwijderen. DMARC heeft een uitgelijnd, geverifieerd resultaat nodig, niet zomaar een SPF of DKIM -pas. RFC 9989, RFC 7208 En RFC 6376 definieer deze afzonderlijke controles.
Een met SRS herschreven envelop kan SPF doorgeven voor het domein van de doorstuurder zonder uit te lijnen met het Van-domein van de oorspronkelijke auteur. Een nieuwe handtekening van diezelfde expediteur heeft de analoge beperking. Geen van beide observaties betekent dat het bericht noodzakelijkerwijs kwaadaardig is, en geen van beide herstelt automatisch de afgestemde authenticatie van de auteur.
Voer het begrensde voorbeeld uit
Referenties: RFC 9989 §4.4, RFC 9989 §5.3.5.
Het behouden strikte afstemmingsmodel kan afzonderlijk van de SMTP opname worden geïnspecteerd. De directe case levert uitgelijnde SPF en DKIM pasjes. Het geval van behouden doorsturen levert SPF falen en afgestemd DKIM succes op, dus het strikte afstemmingsmodel gaat nog steeds door. Het voettekstgeval levert fouten op voor beide paden en mislukt. De SRS gevallen isoleren hoe een succesvolle maar niet-afgestemde SPF identiteit niets aan deze redenering verandert.
Deze booleans zijn doelbewuste invoer en geen resultaat van live DNS query's of verificatie van cryptografische handtekeningen. De gegenereerde onbewerkte berichten zijn synthetisch en zijn nooit ontvangen. Ze illustreren een gecontroleerde lichaamsverandering, maar voldoen niet aan de eis van echte originele en doorgestuurde berichten met betrouwbare resultaten. Het bewaarde SMTP laboratoriumgedeelte hieronder levert historisch lokaal ontvangen bewijsmateriaal; extern productiebewijs blijft open.
Herstel de smalle oorzaak
Referenties: RFC 9989 §7.4.
Vraag de tussenpersoon om ondertekende inhoud waar mogelijk te behouden en verifieer de plaatsing van de ondertekening in de oorspronkelijke service. Test een representatieve geautoriseerde route voordat u het brede domeinbeleid wijzigt. Als een ontvanger een lokale uitzondering toepast, behoud dan de reikwijdte, eigenaar, vervaldatum en onafhankelijke filtervereisten. Levering onder een uitzondering is geen DMARC pas.
Sluit het onderzoek alleen af als het verloren pad, de aangebrachte wijziging en de waargenomen beslissing van de ontvanger afzonderlijk zijn gedocumenteerd. Test periodieke en kleine workflows opnieuw, evenals het voor de hand liggende dagelijkse pad. Een organisatiebrede stap naar monitoring om slechts één doorstuurfout te verbergen, kan de bescherming van niet-gerelateerde e-mail verminderen zonder de tussenpersoon te repareren.
Bewaarde SMTP laboratoriumbewijsmateriaal
Referenties: RFC 7208 §4, RFC 6376 §6.
De bewaarde opname gedateerd 7 november 2026 om 21:29:16 UTC registreert dat de loopback-ontvanger directe, bewaarde doorstuurberichten en in de voettekst gewijzigde berichten heeft vastgelegd via daadwerkelijke SMTP . Het observeerde peer 127.0.0.2 voor de oorspronkelijke verbinding en 127.0.0.3 voor de doorsturende verbinding. pyspf evalueerde die IP's aan de hand van geïsoleerde armatuur DNS ; dkimpy heeft daadwerkelijke RSA-handtekeningen geverifieerd. Het directe geval slaagde voor beide controles, de bewaarde doorgestuurde kopie faalde voor SPF maar slaagde voor de uitgelijnde DKIM , en de voettekstkopie faalde voor beide. Door de ontvanger gegenereerde Authentication-Results en volledige onbewerkte berichten worden bewaard, samen met enveloppen en SHA-256-waarden.
De historische runner- en bewaarde berichten zijn voor deze revisie geïnspecteerd; het netwerkexperiment werd niet herhaald. De oorspronkelijke uitvoering ervan maakte alleen gebruik van loopback en verzond geen internetmail. De ontvanger creëert Authentication-Results op basis van zijn eigen controles, waardoor de laboratoriumherkomst van die velden bekend is. Authenticatieresultaat en -dispositie blijven gescheiden: alle zes SMTP samples ontvangen er 250 onder een expliciet capture-beleid, inclusief falende samples. De vertrouwensgrens is dit gecontroleerde laboratorium, niet een aanbieder van productiemailboxen. De DNS adapter levert bewaarde antwoorden in plaats van het opvragen van openbare DNS , en de DMARC -evaluator gebruikt alleen strikte domeingelijkheid. Volledige ontdekking van het organisatiedomein, parsering van productiebeleid en live-implementatieresultaten blijven ongetest.