Start med en adfærd, ikke en erstatningspost
En standardmigrering bliver håndterbar, når hver implementeringsbeslutning har en navngiven specifikation og en ansvarlig ejer. En DNS -editor, en justering motor og en samlet rapportparser udfører ikke det samme job. Ringer alle tre "DMARC support" skjuler afhængigheder, der betyder noget, når en komponent ændres, og en anden forbliver på en ældre implementering. Den praktiske leverance er et komponent-til-krav-kort, med versioner, grænseflader og bevaret acceptbevis, snarere end en erklæring om, at hele ejendommen er blevet opgraderet.
Det nuværende dokumentsæt blev offentliggjort i maj 2026. RFC 9989 definerer kernemekanismen og forælder RFC 7489 og RFC 9091 . RFC 9990 dækker samlet rapportering; RFC 9991 dækker fejlrapportering og opdaterer også RFC 6591 . Friske RFC Editor-poster identificerer RFC 9989 og RFC 9990 som foreslåede standarder. Den offentliggjorte RFC 9991 tekst identificerer dens standardsporkategori. Disse er offentliggjorte specifikationer, ikke ufærdige udkast, men offentliggørelsen etablerer ikke en bestemt modtagers implementering.
Giv kernemotoren en præcis kontrakt
Tildel registreringsparsing, politikopdagelse, organisationsdomæneopdagelse og identifikatorjustering til RFC 9989 afsnit 4.7-4.10. Forfatterdomænet kommer fra meddelelsens RFC5322 .Fra felt. Et opdaget politikdomæne kan afvige fra det pågældende forfatterdomæne og organisatorisk domæne bruges til afslappet justering er et andet eksplicit output. At miste disse distinktioner i en grænseflade kan gøre et korrekt parser-feed til en forkert beslutningsmotor.
DNS posten begynder stadig med v=DMARC1. “DMARCbis” er et navn for standardarbejdet, ikke tilladelse til at opfinde DMARC2. Nuværende opdagelse bruger afgrænset DNS trævandring i stedet for at behandle en historisk checkliste med offentlig suffiksliste som hele algoritmen. Psd-, np- og t-tags kræver separat beslutningsdækning. IANA register markerer pct, rf og ri historisk; det bekræfter ikke, om et implementeret produkt ignorerer, fortolker eller afslører dem.
Bevar skelnen mellem en normal DMARC fejl, utilgængelige DNS oplysninger, en ugyldig politik og en modtagers endelige beskeddisposition. RFC 9989 afsnit 4.10.1 indeholder særlig håndtering af ugyldige policy-tags, når en syntaktisk gyldig samlet-rapport-URI forbliver. En forenklet regel "enhver misformet politik bliver ingen"-regel ville slette dens betingelser. Optag den nøjagtige sektion ved siden af den parser-case, der udøver den.
Behandl samlet feedback som sin egen implementering
Kortlæg aggregatproducent, XML-validator, rapportforbruger, duplikathåndtering og leveringsintegration til RFC 9990 afsnit 3–4 og tillæg A. Rapporteringsgrænsefladen har brug for, at politikken faktisk evalueres, godkendelsesresultater, antal meddelelser og kontekst for rapporteringsperioden. Et dashboard, der viser XML, er ikke et bevis på, at upstream-modtageren valgte den korrekte politik, eller at alle relevante afsendere optrådte i dataene.
Eksterne rapportdestinationer fortjener deres egen komponentrække. Destinationsautorisation er en teknisk anti-misbrugskontrol, ikke samtykke til at overføre vilkårlige organisatoriske data. Sæt rapportgenerering, destinationsbekræftelse og adgangs-/retentionsbeslutninger under særskilte acceptkriterier. RFC 9990 afsnit 7 omhandler privatliv, mens afsnit 8 advarer om ondsindet eller falsk rapporteringsindhold. Parser-hærdning og kildetillid hører derfor til i kortet sammen med skemavaliditet.
Genbrug ikke en samlet parser til fejlrapporter
Fejlfeedback er en anden kanal med forskellige afsløringsrisici. RFC 9991 styrer dens generering og format og arbejder med de refererede specifikationer for godkendelsesfejlrapportering. Ruf-anmodnings- og fo-betingelserne svarer ikke til rua-sammenlægning. En modtager kan afvise fejlrapportering, og fraværet af en fejlrapport er ikke bevis for, at alle beskeder bestod.
En fejlrapportintegration kan støde på meddelelsesoverskrifter eller indhold, som en samlet pipeline er designet til ikke at bære. Identificer, hvem der kan anmode om det, hvor det kan sendes, hvordan indgående materiale er indeholdt, og hvilken fortrolighedsvurdering der gælder. Aktiver det aldrig blot for at få en funktionsmatrix til at se komplet ud. Kernekrav til deltagelse, valgfri fejlrapportering og et kommercielt produkts annoncerede muligheder er forskellige påstande, der kræver forskellige beviser.
Arbejd gennem en fiktiv komponentopgørelse
Overvej en fiktiv tjeneste med seks moduler: politikdekoder, opdagelsesløser, alignment evaluator, aggregatbygger, XML-forbruger og fejlindsamler. De første tre kort til RFC 9989 . De næste to kort primært til RFC 9990 . Samleren mapper primært til RFC 9991 . Delt lager- og sikkerhedskontrol arver krav fra hver rapporteringssti, de håndterer. Denne opgørelse er et originalt dokumentarisk eksempel, ikke en påstand om EmailAuth arkitektur.
For hvert modul skal du beholde dets faktiske build-id, relevante sektioner, input/output-kontrakt, ejer og acceptarmatur. Et fiktivt opdagelsesarmatur kan overføre en udvalgt politik og dets kildedomæne til et fiktivt aggregeret program; rapporteringsrækken bør bevare denne skelnen i stedet for i det stille at erstatte det synlige Fra-domæne. Indfør derefter en anmodning om fejlrapportering, og bekræft, at designet dirigerer den til en separat autoriseret behandlingssti. Disse er foreslåede kontroller, ikke afsluttede henrettelser.
Hold status, errata og implementering adskilt
Den nøjagtige kommission er: Map hver implementeringskomponent til RFC 9989 , 9990 eller 9991, og kontroller fejl. Faktisk implementeringsdækning er ikke leveret. Nuværende errata-hentning mislykkedes og blev stoppet, så dette udkast kan ikke hævde, at dokumenterne ikke har nogen fejl. RFC 9989 's diskussion af løste RFC 7489 errata er historisk kontekst, ikke en frisk errata check for de tre nye dokumenter.
Inden udgivelsen skal implementeringsejeren afstemme den faktiske beholdning, standardejeren skal løse aktuelle fejl, og modtagerens testejer skal bevare versionsbestemt interoperabilitetsbevis. Specialistgennemgang, kontrol af produktionsruter, visuel accept og publiceringsgodkendelse forbliver også åbne. Det nyttige resultat i dag er et kort, der kan gennemgås, der afslører manglende beviser uden at gøre en opdateret standard til en ikke-understøttet påstand om universel implementering.