Ett meddelande kan autentiseras framgångsrikt och fortfarande klassificeras som oönskat eller farligt. Omvänt kan en postlåda eller filtreringsundantag påverka hanteringen utan att reparera avsändarens autentisering. När någon frågar varför ett meddelande gick till skräppost, samla in autentiseringsresultat och filtrera bevis separat och koppla dem sedan till den faktiska leveransåtgärden.
Läs den aktuella Microsoft-guiden
Microsofts nuvarande rubrikreferens särskiljer Authentication-Results från X-Forefront-Antispam-Report och X-Microsoft-Antispam. Den beskriver BCL som sannolikhet för bulkklagomål snarare än domänautentisering. Det står också att i molnorganisationer bestämmer inte SCL klassificering eller åtgärder för skräppost; CAT och DIR tillhandahåller filtreringskontext istället. Använd inte en gammal SCL-till-mapp-tabell som en universell molnbeslutsregel. Detta betyder inte att SCL är irrelevant för konfigurationen: Microsoft dokumenterar fortfarande e-postflödesregler som begär förbikoppling eller skräppostbehandling. Den stämplade SCL och faktiska åtgärden måste undersökas med tillämplig regel och kategoriseringskontext. Microsoft header referens.
SCL förblir relevant i utbyte på plats och viss hybridbehandling. Fastställ vilken produkt och leveransväg som producerade fältet innan du tolkar det. Microsoft beskriver SCL i sin egen produktspecifika referens, och BCL har en separat referens. Spara dokumentationsdatumet eftersom servicebeteende och förklaringar kan ändras. SCL, BCL.
Bygg en bevistabell utan kollapsande betydelser
Referenser: RFC 8601 §5, RFC 8601 §7.
Spela in mottagarens SPF, DKIM och DMARC resultat med sina utvärderade domäner. I en separat grupp, registrera CAT, DIR, BCL och eventuella relevanta SFV-värden exakt som mottaget. Lämna odokumenterade fält otolkade. Lägg sedan till den faktiska dispositionen från en auktoriserad spårning, karantänpost eller postlådeobservation. Ett saknat fält är ett okänt resultat, inte en nolla eller ett godkänt resultat.
Verifiera källan till dessa observationer. Otillförlitliga meddelanden kan innehålla vilseledande rubriktext, och en vidarebefordrad kopia kan lägga till eller ta bort information. RFC 8601 beskriver behovet av en förtroendegräns kring autentiseringsresultat; samma undersökande försiktighet gäller när någon skickar en skärmdump av produktspecifik metadata. RFC 8601 avsnitt 7.
Jämför ett syntetiskt par resultat
Den medföljande fixturen innehåller ett avsiktligt uppfunnet meddelande med dmarc=pass, CAT:BULK, DIR:INB och BCL:7. Det visar samexistens av ett protokollpass och en bulkklassificering. Parsern extraherar fälten oberoende. Den kör inte Microsofts klassificerare, upprättar inte en verklig tröskel eller förutsäger mappen en mottagare skulle se.
I en faktisk undersökning, hämta policyn och bearbetningsbevis som gäller för den mottagaren vid den tidpunkten. Anta inte att ett numeriskt BCL-värde alltid leder till samma åtgärd mellan organisationer. En avsändare kan behöva bättre publiksamtycke, sändningsmetoder eller innehåll, medan ett annat fall behöver en autentiseringsreparation. Bevisen ska identifiera vilken uppgift som gäller.
Ändra endast det ansvariga lagret
Referenser: RFC 9989 §8.
Om autentiseringen misslyckas, korrigera sändningskonfigurationen och verifiera samma rutt. Om autentiseringen godkänns och en bulk- eller hotkategori förklarar hanteringen, undersök den klassificeringen genom den mottagande organisationens granskningsprocess som stöds. Behandla aldrig ett autentiseringskort som tillstånd att kringgå skydd mot skadlig programvara, identitetsstöld eller spam.
Anteckna gamla och nya bevis efter en godkänd rättelse. Ange om förbättringen var en autentiseringsändring, en policyändring eller en ny observerad disposition. Undvik att lova inkorgsleverans från en enda poäng eller ändra tröskelvärden för all post för att lösa ett meddelande.
Läs det kommenterade provet utan att ge förtroende
Referenser: RFC 8601 §5.
Det bibehållna anteckningsregistret listar varje råfält i ordning med dess faktiska generator, påstådda ursprung och förtroendegräns. Från är en identitet som tillhandahålls av författaren; Till är en visad mottagare snarare än bevis på SMTP kuvertet. Meddelande-ID, Datum och Ämne är avsändarkontrollerade sammanhang. Varje fält Authentication-Results gör anspråk på en rapporttjänst och ett resultat, men varken trusted.example eller untrusted.example fastställer äkta mottagarhärkomst. List-ID namnger listan med anspråk; Avregistreringsfälten beskriver en åtgärdsmekanism, inte listägande. I klassificeringsprovet är CAT, DIR, SCL och BCL uppfunna Microsoft-liknande domar, inte observationer från Microsoft. Ingen mottagen kedja, SPF -kuvertidentitet eller anslutande IP har upprättats.
Använd den här kartan som ett kommenterat undervisningsexempel. För ett verkligt meddelande, byt ut varje antaget ursprung med insamlings- och mottagarbevis och lämna alla overifierade gränser uttryckligen olösta.