To parter indgår rapporteringsforholdet
Udgivelse af en rapporteringsdestination i et domæne DMARC politik udtrykker domæneejerens anmodning. Det kræver ikke ensidigt at en ikke-relateret destination accepterer de resulterende rapporter. Ekstern destinationsbekræftelse beskytter modtagere mod at blive udvalgt som uvillige rapportmål. Den modtagende side udgiver tilladelse gennem DNS , mens rapporteringssiden kontrollerer denne tilladelse, inden den eksterne destination bruges.
RFC 9990 anvender sin verifikationsprocedure, når det er relevant Organisatorisk domæne sammenligning viser en ekstern destination for aggregeret rapportering. Udskift ikke den regel med en forenklet test om, at strengene i Fra-adressen og rapportadressen er forskellige. Det opdagede politikdomæne, destinationsvært og organisationsdomænekontekst skal bevares, så beslutningen om at udføre verifikation er reproducerbar. RFC 9990 , afsnit 4
Konstruer ejernavnet i den rigtige rækkefølge
Udpak destinationsværten fra rapporterings-URI'en. Indsæt _rapport. _dmarc , indsæt derefter domænenavnet, hvorfra politikken blev hentet, og konverter det domæne til en A-label, hvis det er nødvendigt. Den resulterende DNS ejer har formen policy-domain._report. _dmarc.destination-host. Det spørges efter TXT registreringer. Hvis det konstruerede navn overskrider DNS grænser, kan der ikke foretages en positiv godkendelsesbestemmelse.
Denne konstruktion bruger det faktiske domæne, hvorfra politikken blev hentet. Forkort det ikke til en kendt forælder, blot fordi denne forælder ligner organisationens brand. Ligeledes er den lokale del af en mailto-adresse ikke indsat i DNS ejernavnet. Bevar den originale URI og den parsede destinationsvært, så korrekturlæsere kan se, hvordan det konstruerede navn følger af input. RFC 9990 , afsnit 4
Valider svaret i stedet for at genkende en velkendt streng
De returnerede poster parses som tag-værdi-lister. Det obligatoriske v=DMARC1 -tag skal vises først, og et efterfølgende semikolon er valgfrit. Optegnelser, der fejler den angivne parsingtest, kasseres. Mindst én resterende kvalificerende registrering etablerer den eksterne rapporteringsordning under proceduren. Et tomt svar, en ikke-relateret TXT værdi eller en rekord med den forkerte version etablerer placering ikke tilladelse.
DMARC -versionsværdien skelner mellem store og små bogstaver: DMARC1 er den påkrævede værdi, ikke en tilnærmelse af små bogstaver eller en nyopfundet protokolversion. Regler for sammenligning af DNS navne må ikke forveksles med versionsværdiens krav til små og store bogstaver. En gennemgang bør bevare de nøjagtige svarbytes og registreringsgrænser i stedet for at normalisere detaljer før validering. RFC 9990 , afsnit 4; RFC 9989 , afsnit 4.7 og 4.8
Respekter tilsidesættelse og svigtadfærd
En autorisationspost kan levere en rapporterende destinationstilsidesættelse under proceduren. Den tilsidesættende URI skal bruge den samme destinationsvært, der blev udtrukket i begyndelsen. Denne begrænsning forhindrer et autorisationssvar i at omdirigere processen til en kæde af ikke-relaterede modtagere. Hvis bekræftelsen indeholder en tilsidesættelse med en anden vært, må rapportgeneratoren ikke generere en rapport til hverken den originale eller tilsidesættende URI.
Hvis verifikation ikke bekræfter godkendelse, skal den eksterne URI ignoreres. En midlertidig DNS fejl har sin egen behandling: Modtageren kan vælge midlertidigt at mislykkes med levering, så verifikationstesten kan gentages senere. Bevar denne tilladelse som MAJ, ikke en universel genforsøgsgaranti eller en beskrivelse af en testet implementering. Et vellykket DNS -tjek beviser stadig ikke, at destinationspostkassen eksisterer, accepterer rapportstørrelsen eller fodrer det tilsigtede kundedashboard. RFC 9990 , afsnit 4
Skelne aggregerede og fejlrapportanmodninger
For samlede rapporter, proceduren er forbundet med rua. Fejlrapportering er specificeret særskilt i RFC 9991. For eksterne fejlrapportdestinationer kræver dette dokument den samme eksterne verifikationsprocedure med ruf erstattet, hvor rua vises. Behandl ikke fejlrapportering som automatisk aktiveret, bare fordi aggregerede rapporter flyder, eller kopier aggregeret destinationshåndtering uden at anerkende den separate rapporttype.
Fejlrapporter rejser yderligere bekymringer om dataeksponering, fordi deres indhold kan være mere detaljeret end samlede resuméer. En korrekt DNS autorisationspost er ikke en erstatning for en organisations beslutning om, hvilke data der må deles, med hvem og til hvilket formål. Dette manuskript giver ingen tilladelse til at anmode om, overføre eller uploade faktiske rapporter. Enhver reel opsætning skal tilfredsstille de gældende fortroligheds-, modtager- og driftsgodkendelser. RFC 9991 , afsnit 5 og 7
Fiktiv konstruktion og accept arbejdsark
Antag, at en fiktiv politik blev hentet fra blue.example.com og anmoder om samlede rapporter på mailto:reports@red.example.net. Den konstruerede autorisationsejer er blue.example.com._report._dmarc.red.example.net . Et hypotetisk TXT svar, hvis fuldstændige værdi er v=DMARC1; opfylder det viste version-først-krav. Der blev ikke udført nogen DNS forespørgsel, og dette eksempel hævder ikke, at navnene har offentliggjorte poster.
Regnearket skal bevare politikopslagsresultatet, opdaget politikdomæne, original rapporterings-URI, destinationsvært, organisationsdomæne-sammenligning, konstrueret ejer, forespørgselstype, tidsstempel, nøjagtige returnerede poster og parsing-resultat. Tilføj et separat felt for enhver tilsidesættelse, og bekræft dens værtsbegrænsning. En korrekturlæser bør være i stand til at rekonstruere navnet uden at stole på et udbyderskærmbillede eller en DNS editors forkortede visning.
Brug en anden acceptsektion til indsamling: påtænkt konto, destinationspostkasse, godkendt rapporttype og pipelineejer. Disse felter beskriver en planlagt verifikationsarbejdsgang, ikke fuldført indtagelsesbevis. Hold DNS relationsresultatet adskilt fra kvittering, parsing, lejertilskrivning og dashboardpræsentation. En tilladelseskontrol kan lykkes, mens en anden del af indsamlingsstien forbliver uløst.
Offentliggørelse og implementering holder
Kataloget kræver opbygning af det nøjagtige autorisationsopslag fra kilde- og destinationsdomæner og verifikation af dets svar. Dette udkast leverer kun en fiktiv konstruktion. Et faktisk svar, original forespørgselstransskription og implementering af modtagedomæne forbliver åbne. Ingen DNS post blev offentliggjort, ingen postkasse blev tilgået, og ingen rapport blev transmitteret.
Inden udgivelse som en operationel gennemgang skal du indhente autoriseret bevis for det nøjagtige produktionsforhold og få en kvalificeret korrekturlæser til at bekræfte politikopdagelseskonteksten, versionsparsing og tilsidesættelseshåndtering. Bevar kildedatoen, og skeln standardkrav fra udbyderspecifik konto onboarding. Alle seks udgivelsesporte forbliver åbne, inklusive originale beviser, menneskelig gennemgang, kildeanvendelse, produktionsruter, visuel tilgængelighed og ejerudgivelse.
En senere ændring af destinations- eller politikopdagelsesdomænet kan ændre den påkrævede godkendelsesejer. Behandl det som et nyt omfang, der skal verificeres i stedet for at antage, at en gammel positiv check dækker alle fremtidige rapporteringsadresser. Det nyttige resultat er en reviderbar tilladelseskæde, ikke blot en kopieret TXT værdi.