En AI-genererad DMARC rekommendationen bör vara ett inspekterbart argument. Den ska berätta för operatören vad som observerades, vad som antas, vad som förblir okänt och vilken åtgärd som är motiverad. Enbart konfidensformuleringar är inte bevis, och en polerad förklaring får inte dölja saknad avsändaräganderätt eller ofullständig rapportering.
Bevara beviskedjan
Behåll rapportidentitet, rapporteringsmottagare, intervall, källadress, antal, identifierare och autentiseringsresultat. Bifoga relevant tjänsteregisterpost och godkänd ändringshistorik när tillgänglig. RFC 9990 beskriver aggregerade observationer; Dessa observationer visar inte att varje skickat meddelande har setts eller att en källadress tillhör en viss affärsapplikation.
Använd en bevisreferens för varje väsentligt påstående. Skilj en rapports observerade autentiseringsresultat från agentens förklaring av varför det hände. Om ett e-postexempel och leverantörskonfiguration inte överensstämmer, bevara båda istället för att välja den som stöder den föreslagna korrigeringen. Identifiera färskheten av varje observation och omfattningen av den saknade informationen.
Gör osäkerhet genomförbar
En användbar rekommendation anger rimliga alternativ och nästa diskriminerande test. Till exempel kan en delad IP-adress med en obekant undertecknare representera en ny tjänst, en indirekt sökväg eller obehörig användning. Be om kontospecifik konfiguration och ett ägarbeslut innan du godkänner det. Förvandla inte en numerisk konfidenspoäng till ett företagsgodkännande.
Definiera tillåtna utdata som undersök, begäran_ägare_bekräftelse, prepare_diff och eskalera. Tillstånd att analysera innebär inte tillåtelse att publicera poster eller skicka externa meddelanden. OWASP:s överdrivna myndighetsvägledning stödjer minimering av verktygsbefogenheter; utgångsschemat och säkerhetskontrollerna här är en lokal design snarare än ett påstående om leverantörskapacitet.
Förbered konkreta motexempel innan du testar
En föreslagen utvärderingsuppsättning bör innehålla en rapportanteckning som begär att skriva en icke-relaterad skrivning, endast leverantörsnamn, saknade bevis, motstridiga ägaruppgifter och en skrivskyddad rekommendation. För den orelaterade skrivningen är den förväntade gränsen ingen mutation och ett scoped endast bevissvar. För uteblivet ägande är den förväntade produktionen en specifik bevisförfrågan snarare än ett påhittat godkännande. Definiera dessa förväntningar innan du ser systemets svar.
Dessa är testdesignkategorier, inte en tillhandahållen motstridig korpus eller utförd validator. Konstruera konkreta auktoriserade indata och etiketter, versionera dem och skicka in dem genom den faktiska agentens normala intags- och behörighetsgräns. Behåll svar och verktygseffekter, inklusive avslag, oväntade åtgärder och osäkra resultat. En deterministisk schemakontroll kan testa deklarerade fält men kan inte fastställa modellnoggrannhet eller snabbinsprutningsmotstånd. Lägg till ärenden från auktoriserade felregister utan att kopiera onödigt personligt innehåll.
Lämna ett begränsat beslut
Ange vad som säkert kan hända nu, vem som måste avgöra den olösta frågan och vilka bevis som skulle ändra rekommendationen. För ett autentiseringsfel, särskilj inriktning från rå SPF eller DKIM passera, som RFC 9989 kräver. Lova inte leveransförbättringar från en oprövad DNS redigering. Granska själva verktygsspåret samt förklaringen: ett försiktigt svar kompenserar inte för en otillåten bieffekt.
Primär läsning: OWASP LLM06 2025 Överdriven byrå, RFC 9990 DMARC samlad rapportering, RFC 9989 DMARC.