Rapportér, hvad der blev observeret, før du kalder det sundt
A DMARC checker kan observere DNS -politikoplysninger og evaluere dele af dens syntaks eller opdagelsesadfærd. Det fastslår ikke, at enhver legitim afsendelsestjeneste autentificerer korrekt, at alle modtagere anvender den samme implementering, eller at en bestemt besked nåede en indbakke. Et nyttigt checkeroutput bør identificere dets nøjagtige input, resolverkontekst, observationstid, opdagelsesmetode og begrænsninger, før en konklusion præsenteres.
RFC 9989 definerer den aktuelle DMARC mekanisme, herunder policy discovery og justering. Denne artikel beskriver foreslåede beviskrav til en checker; det hævder ikke, at EmailAuth implementerer dem, eller at et domæne blev scannet. Der blev ikke udført nogen autoritativ eller rekursiv forespørgsel for et brugerdomæne, og der blev ikke indsamlet en prøve af modtaget meddelelse.
Skelne et nøjagtigt opslag fra politikopdagelse
En forespørgsel efter et bestemt _dmarc ejernavn er en observation ved det navn. Fastlæggelse af den gældende politik kan kræve den aktuelle standards opdagelsesproces, herunder dens DNS Tree Walk regler. Checkeren skal angive, om den blot viser et nøjagtigt TXT svar eller implementerer en defineret opdagelsesalgoritme. Det bør ikke kalde en manglende registrering ved ét navn bevis på, at der ikke findes nogen gældende politik uden at evaluere det relevante omfang.
Registrer hvert ejernavn, forespørgselstype, svar og gren, der bruges af den implementerede opdagelsesproces. Outputtet skal skelne mellem en gyldig politik, ingen gældende politik, en ugyldig kandidat og en DNS fejl i henhold til den understøttede algoritme. Opfind ikke en genvej, der kun er baseret på en velkendt organisationsdomæneliste, mens du hævder den nuværende standardadfærd. Produktversionen og standardreferencen skal opbevares sammen med resultatet.
Bevar autoritative og rekursive perspektiver
Et autoritativt svar og et rekursivt resolversvar kan være forskellige på grund af cachelagring, delegeringstilstand, timing eller opløsningsfejl. Registrer, hvilken server eller resolver der har leveret hvert svar, og hvornår det blev indsamlet. Et dashboard bør ikke slå dem sammen til én tilsyneladende tidløs værdi. Hvis en checker kun tilbyder rekursive beviser, så sig det i stedet for at antyde, at den autoritative konfiguration var uafhængigt verificeret.
RFC 1035 definerer DNS meddelelses- og ressourceregistreringsstrukturer, herunder TXT registreringer. Bevar svarkoder og poststruktur i stedet for kun at vise en fladtrykt politikstreng. Flere tegnstrenge inden for en TXT post er ikke det samme som flere TXT poster. Denne sondring har betydning, når det skal afgøres, om svaret indeholder konkurrerende DMARC -politikregistreringer eller blot én post repræsenteret i flere strenge.
Fortolk syntaks med den aktuelle standard
RFC 9989 angiver DMARC1 som den versalfølsomme versionsværdi og kræver versionskoden i den definerede position. En checker bør identificere den nøjagtige årsag til, at en kandidat ikke er en gyldig politik i stedet for at erstatte ethvert problem med en generisk rød advarsel. Det bør også skelne duplikerede politikkandidater fra ikke-relaterede TXT data. Den gældende opdagelsesprocedure bestemmer, hvordan kandidatposter udvælges og håndteres.
Ukendte tags er ikke automatisk en fatal politikfejl: RFC's formelle definition siger, at ukendte tags skal ignoreres. En checker kan stadig advare om, at et tag ikke understøttes af sin egen parser eller mangler i det aktuelle register, men det bør ikke forveksle denne advarsel med en normativ afvisningsregel. Omvendt kræver et anerkendt tag med en problematisk værdi den relevante standards håndtering, ikke en opfundet universel reaktion på alle syntaksfejl.
Statlige implementerings- og kompatibilitetsgrænser
Den nuværende RFC fjerner pct og introducerer testmærket t, som forklaret i appendiks A.6. En checker bør identificere, hvilket standard- og tag-register dens fortolkning følger og undgå at antyde, at hver ekstern modtager opfører sig identisk. Det bør ikke foreslå en mekanisk migration fra vilkårlige historiske procenter uden en beredskabsgennemgang. Udbyderspecifikke berettigelsesregler kan have behov for separat aktuel dokumentation.
En syntaktisk acceptabel DNS -politik er stadig kun en del af det operationelle billede. Checkeren har ikke etableret listen over legitime afsendere, deres tilpasning eller effekten af en politikændring. Hold anbefalinger betinget af de manglende input. En politik, der anmoder om håndhævelse, kan udgives korrekt, mens legitime arbejdsgange forbliver forkert konfigurerede; en DNS tjek kan ikke alene bekræfte, at håndhævelse er sikker for virksomheden.
Forbind DNS bevis til en betroet meddelelsesprøve
RFC 8601 forklarer tillidsgrænsen for Authentication-Results felter. En prøve af modtaget meddelelse skal identificere modtageren, der producerede resultatet, og bevare de relevante synlige, konvolut- og underskriftsidentiteter. En kopieret linje, der indeholder pass, er ikke nok til at fastslå, at den påtænkte modtager har evalueret den faktiske arbejdsgang. Prøven bør godkendes og redigeres uden at ødelægge de domæneforhold, der er nødvendige for analyse.
Sammenlign prøvetiden og identiteterne med DNS observationerne, men lad ikke som om, at en prøve dækker hver afsender eller modtager. En politik kan have ændret sig mellem afsendelse og kontrol, og rekursive caches kan afspejle forskellige tilstande. Angiv, hvad prøven viser, og hvad der forbliver ukendt. Denne artikel har intet meddelelseseksempel og påstår ikke, at en reel politik matchede et reelt modtaget resultat.
Et arbejdsark til accept af checker-output
Opret et regneark med forespurgt domæne, nøjagtige ejernavne, resolver eller autoritativ kilde, tidsstempler, svarkoder, bevarede transskriptioner og kandidatpoststruktur. Tilføj den implementerede opdagelsesalgoritme, parserversion, valgt politik, advarsler og eksplicit usikkerhed. Meddelelsessektionen skal registrere den autoriserede arbejdsgang, den betroede modtager, relevante identiteter, observerede resultater og begrænsninger i forbindelse.
Brug foreslåede fixtures til en gyldig politik, manglende nøjagtige navneregistrering med relevant registrering på højere niveau, duplikerede kandidater, ikke-understøttede tags og utilgængelig DNS . Adskil normativ forventet adfærd fra produktspecifik præsentation. En test skal verificere de bevarede beviser og forklaringer, ikke kun et grønt ikon. Der blev ikke udført noget fixtur her, og intet reelt DNS svar er repræsenteret af eksemplerne.
Fiktiv diagnose: en grøn rekord med en svigtende afsender
Et fiktivt team ser en checker vise en gyldig håndhævelsespolitik og konkluderer, at dens fakturaservice er klar. En godkendt prøve af modtaget meddelelse, hvis den senere indsamles, kan vise, at tjenesten bruger en ikke-justeret sti. DNS observationen og meddelelsesfejlen ville ikke modsige hinanden: den ene beskriver publicering, mens den anden beskriver en afsendende arbejdsgang.
Den foreslåede undersøgelse vil bevare begge observationer, identificere workflow-ejeren og gennemgå den tilsigtede tilpassede sti, før der ændres politik eller tilføjes autorisationer. Det ville ikke erklære domænet sikkert, blot fordi posten parses. Dette er en fiktiv øvelse, ikke en reel fakturaservicefejl, DNS scanning eller modtagerresultat. Dens formål er at holde checkerens bevisgrænse synlig.
Hold den endelige konklusion proportional
En nyttig checker-konklusion kan sige, at en specifik politik blev observeret og fortolket under en specificeret algoritme på et angivet tidspunkt. Det bør ikke love universel levering, fuldstændig modtageradoption eller beskyttelse mod enhver efterligning. Outputtet er stærkest, når det gør manglende operationelle beviser let at se.
Kataloget kræver autoritative og rekursive opslagsudskrifter, tidsstempler og et matchende eksempel på modtaget meddelelse. Disse originale artefakter forbliver åbne. Gennemgang af menneskelig specialist, kildeanvendelighed, produktionsruter, tilgængelighed og ejerfrigivelse forbliver også åbne. Dette udkast leverer en foreslået bevismodel, ikke udførte scanninger eller verificerede EmailAuth kontrolfunktioner.