En kunddriftsrapport bör förklara vad tjänsten gjorde, vad bevisen omfattar och vad kunden måste besluta härnäst. En agent kan sammanställa rapporten, men den bör inte förvandla ofullständiga observationer till en garanti eller sluta sig till tillstånd att skicka rapporten från tillstånd att utarbeta den.
Definiera rapporteringskontraktet
Ange kund, domänens omfattning, period, tjänsteansvar och kända undantag. Identifiera vem som äger DNS godkännande, avsändarens äganderättsbeslut, incidentrespons och rapportsignering. Separera leverantörens övervakningsarbete från system och mottagare utanför dess kontroll.
RFC 9990 samlade rapporter sammanfatta deltagande mottagarobservationer. Rapportera täckning i enlighet därmed snarare än att hävda att all kundpost observerades. Använd ett godkänt serviceregister som nämnare för servicetäckning och ange tysta eller oprövade tjänster separat. Visa autentiseringsresultat oberoende av leveransresultat.
Ta med livscykeln i rapporten
En föreslagen rapporteringslivscykel kan omfatta intag, domän- och tjänstinventering, implementeringsgodkännande, verifiering, övervakning, eskalering, periodisk rapportering och exit. För varje steg, nämn den ansvariga rollen, framtagna bevis och slutförandevillkor. Detta är en rekommenderad checklista, inte en medföljande runbook, avtalsenligt servicemål eller utförd kundoperation.
Vid intag bekräftar kundägaren omfattning. Vid implementering accepterar en namngiven DNS godkännare en exakt diff. Vid övervakning registrerar operatören daglig intagsstatus och tilldelar materialfel. Vid utträde stämmer auktoriserade operatörer av lagrade register, exporterar överenskomna bevis och återkallar åtkomst genom en godkänd plan. Ta inte bort delade DNS beroenden automatiskt vid uppsägning.
Beräkna mått med synliga nämnare
Antag att en hypotetisk rapport omfattar fyra registrerade tjänster under ett deklarerat intervall. Tre har användbara observationer och en incidentanmälare är tyst, vilket ger en täckning av observerade tjänster på 3/4 eller 75 %. I den deduplicerade mottagna rapportpopulationen för samma intervall, anta 200 meddelandeobservationer, varav åtta misslyckas DMARC: den observerade felfrekvensen är 8/200 eller 4 %. Detta är inte ett mått på all post som skickas, unika kunder eller företagsleverans.
Den tysta tjänsten är fortfarande okänd, inte hälsosam. Fråga dess ägare om den planerade aktiviteten eller ett auktoriserat rutttest. En pågående DNS -ändring hör under beslut som väntar på godkännande, ej avslutat arbete. Dessa är angivna indata och handarbetad aritmetik, inte en genererad rapport eller utförd fullständighetskontroll. Innan du delar en faktisk rapport, verifiera periodmetadata, åtgärdsägare och gränserna för varje nämnare.
Granska innan du delar
Låt operatören verifiera faktiska påståenden och den kundvända ägaren granska åtaganden. Ange bevisluckor, åldrandeundantag och nödvändiga beslut med hjälp av klarspråk. Dra inte slutsatsen att en godkänd signatur upprättar affärsgodkännande; RFC 9989s autentiseringsresultat tjänar ett annat syfte.
Håll känsligt meddelandeinnehåll och referenser borta från rapporten. Dela endast via den auktoriserade mottagaren och åtkomstomfånget. Den här artikeln tillhandahåller ett rapporteringsmönster, inte en accepterad kundrunbook eller uppmätt serviceprestanda. Den gör inga anspråk på produktkapacitet och godkänner inte leverans till någon extern mottagare.
Slutrapporten ska göra nästa åtgärd lättare utan att överdriva vad tjänsten kan kontrollera.
Primär läsning: RFC 9990 DMARC samlad rapportering, RFC 9989 DMARC, OWASP LLM06 2025 Överdriven byrå.