Definiera frågan och mottagaren först
En leverantör kan behöva bevis för att diagnostisera ett signeringsproblem, en inriktning oöverensstämmelse eller en rapporteringsavvikelse. Det behöver sällan varje rapport för varje domän i organisationen. Börja med att ange den exakta frågan, vilken produkt och konto som är inblandade, den avsedda mottagaren och vilket beslut bevisen ska möjliggöra. Detta förhindrar en begäran om "den DMARC data” från att bli ett onödigt brett avslöjande.
Bekräfta att mottagaren är den auktoriserade support- eller ingenjörskontakten för relevant tjänst. Ett välbekant visningsnamn eller vidarebefordrad begäran räcker inte för att fastställa att varje bilaga ska skickas dit. Att utarbeta ett paket är separat från tillstånd att överföra det. Den här artikeln beskriver endast förberedelser och tillåter inte e-post, uppladdning eller extern delning.
Håll räckvidden knuten till den berörda rutten och intervallet. En leverantör som undersöker sitt eget kvittoarbetsflöde bör inte ta emot icke-relaterad personalpost, marknadsföring eller annan leverantörstrafik bara för att dessa observationer upptar samma samlade fil.
Förstå vad rapporten kan avslöja
Sammanlagda rapporter innehålla tekniska observationer och policyinformation som kan avslöja aspekter av avsändarens infrastruktur och trafik. RFC 9990 diskuterar integritetshänsyn för mottagare och rapporterar data. Även när ett fält inte är en meddelandetext, kan det fortfarande vara onödigt för en leverantörs uppgift. Behandla minimering som ett fält-för-fält-beslut snarare än att anta att all samlad information är ofarlig.
Felrapporter ha en separat och potentiellt mer detaljerad exponeringsyta under RFC 9991. Kombinera inte dem med samlade sammanfattningar under ett generiskt godkännande för "rapporter". Identifiera rapporttyp, innehåll och mottagarens syfte uttryckligen. Om en diagnostisk fråga kan besvaras med en mindre sammanfattning eller redigerat utdrag, föredra det framför en komplett rå artefakt. RFC 9990 , avsnitt 7.1 och 7.2; RFC 9991 , avsnitt 7.1 och 7.2
Bygg en datafältskarta innan redigering
Fältkartan bör lista varje kandidatobjekt, varför det behövs, om ett exakt värde är nödvändigt, den föreslagna behandlingen och konsekvensen av att ta bort den. Potentiella objekt inkluderar relevant Från-domän, signeringsdomän, väljare, kuvertdomän, källadress, rapportintervall, antal och utvärderingsresultat. Deras nödvändighet beror på frågan; det finns ingen universell bunt som alltid ska skickas.
Vissa exakta tekniska identiteter kan behövas för att diagnostisera anpassning eller hitta en kontospecifik konfiguration. Om dessa värden inte kan delas inom den godkända omfattningen, förklara den diagnostiska begränsningen i stället för att ersätta dem med vilseledande värden. Andra identifierare kan tas bort eller konsekvent pseudonymiseras samtidigt som relationer bevaras. Behåll en privat mappning endast när det är nödvändigt och auktoriserat, och inkludera det inte i leverantörspaketet som standard.
Ta bort orelaterade rader och domäner, onödiga mottagaradresser, meddelandeinnehåll, interna anteckningar och hemligheter. Inkludera aldrig lösenord, API-nycklar, sessionstokens eller referenser i en supportartefakt. Granska filnamn, metadata, skärmdumpar och dolt kalkylbladsinnehåll samt synlig text; ett redigerat stycke garanterar inte att bilagan minimeras.
Bevara diagnostiska relationer
Ett användbart bevisprov bör behålla distinktionen mellan råa autentiseringsresultat och anpassning. Om frågan gäller varför DMARC misslyckades, kan en ersättning av varje domän med samma platshållare radera relationen som leverantören behöver förstå. Bevara om identiteter är lika, relaterade eller olika, och märk tydligt syntetiska ersättningar så att de inte förväxlas med riktiga DNS namn att fråga efter.
Håll rapporteringsintervallet, relevanta resultatfält och omfattningsanteckningar tillsammans. Om endast markerade rader delas, ange att urvalet är filtrerat och identifiera urvalsregeln. Ändra inte ett resultat för att få exemplet att se enklare ut, och antyd inte att ett filtrerat antal representerar organisationens totala trafik. Vid behov, ge en kortfattad analytikerförklaring tillsammans med de bevarade fälten. RFC 9989 , avsnitt 4.4; RFC 9990 , avsnitt 3.1
Arbetsblad för godkännande och retention
Förbered en godkännandepost med mottagare, organisation, produkt, syfte, exakta filer eller fält, påverkad domän eller rutt, tidsintervall, känslighet, överföringsmetod och lagringsbeslut. Identifiera om säljaren får behålla materialet endast för ärendet, använda det för ett annat ändamål eller dela det vidare. Anta inte att en allmän supportrelation tillåter icke-relaterad återanvändning eller bred åtkomst.
Beslutet om lagring bör ta upp både säljarkopian och organisationens arbetskopia. Registrera den avsedda varaktigheten eller raderingsutlösaren och vem som kan verifiera slutförandet där det är viktigt. Detta är en föreslagen styrningsprocess, inte ett påstående om att ett leverantörskontrakt redan innehåller specifika villkor. Om de tillgängliga villkoren eller mottagaråtkomsten är otydliga, lös det innan överföringen.
Acceptans kräver att en granskare jämför det slutliga paketet med den godkända fältkartan. Den faktiska bilagan, inte bara en beskrivning, bör kontrolleras för orelaterade rader, dolda data och oavsiktliga hemligheter. En ändrad mottagare, utökad datauppsättning eller nytt syfte bör utlösa förnyad granskning snarare än att behandlas som en ofarlig fortsättning på samma andel.
Fiktivt stödpaket för en signeringsrutt
Föreställ dig en fiktiv kvittoleverantör som undersöker en aligned DKIM fel. Organisationens råa sammanlagda rapport innehåller också observationer från anställdas e-post och kampanj. Ingen riktig rapport eller leverantörsbegäran fick åtkomst för detta exempel. Det föreslagna paketet innehåller endast de relevanta mottagningsvägsraderna, det avgränsade rapporteringsintervallet, de relevanta identitetsrelationerna och en kort förklaring av vad som är osäkert.
Medarbetar- och kampanjraderna är exkluderade eftersom de inte svarar på leverantörens fråga. Om leverantören behöver en exakt signeringsdomän eller väljare måste organisationen godkänna dessa värden för den mottagaren och syftet. Ett redigerat prov som döljer dem kan fortfarande vara användbart för en konceptuell diskussion men kan inte presenteras som tillräckligt för en live DNS diagnos.
Det slutliga godkännandet registrerar också ett ärendespecifikt beslut om kvarhållande. Inget paket skickas bara för att utkastet är komplett. Om leverantören senare ber om fullständiga meddelandeprov, är det en ny innehållsbegäran med en annan sekretessprofil, särskilt om den introducerar mottagare eller meddelandeinstanser. Nästa steg är en omfattande granskning, inte automatisk expansion.
Bevis och frigivningsstatus
Katalogen kräver en datafältskarta och ett godkänt minimalt bevisprov med ett uttryckligt beslut om lagring. Den här artikeln tillhandahåller endast en förberedelsemetod och fiktiv förpackningsdesign. Inget faktiskt prov har godkänts, ingen mottagare har lösts och ingen överföring eller radering av leverantör har verifierats.
Alla sex utsläppsgrindarna förblir öppna. En kvalificerad granskare bör kontrollera att den föreslagna minimeringen bevarar den diagnostiska frågan samtidigt som mottagar- och ändamålsgränser respekteras. Innan någon verklig delning skaffas, skaffa den nödvändiga auktoriseringen för de faktiska uppgifterna och destinationen. Ett säkert förberett utkast är ett värdefullt framsteg, men det är inget bevis på att säljaren tagit emot eller hanterat något.