Twee partijen maken de rapportagerelatie
Het publiceren van een rapportagebestemming in een domein DMARC beleid geeft uitdrukking aan het verzoek van de domeineigenaar. Er is niet eenzijdig een niet-gerelateerde bestemming vereist om de resulterende rapporten te accepteren. Externe bestemmingsverificatie beschermt ontvangers tegen selectie als onwillige rapportdoelwitten. De ontvangende kant publiceert toestemming via DNS , terwijl de rapporterende kant die toestemming controleert voordat de externe bestemming wordt gebruikt.
RFC 9990 past haar verificatieprocedure toe wanneer dit relevant is Organisatorisch domein vergelijking toont een externe bestemming voor geaggregeerde rapportage. Vervang die regel niet door een simplistische test dat de strings in het Van-adres en het rapportadres verschillen. Het ontdekte beleidsdomein, de bestemmingshost en de context van het organisatiedomein moeten behouden blijven, zodat de beslissing om verificatie uit te voeren reproduceerbaar is. RFC 9990 , sectie 4
Construeer de naam van de eigenaar in de juiste volgorde
Extraheer de doelhost uit de rapportage-URI. _rapport voorafgaan. _dmarc en plaats vervolgens de domeinnaam waarvan het beleid is opgehaald, en converteer dat domein indien nodig naar een A-label. De resulterende DNS eigenaar heeft de vorm policy-domain._report. _dmarc.destination-host. Er wordt naar gevraagd TXT records. Als de geconstrueerde naam DNS limieten overschrijdt, kan er geen positieve autorisatiebepaling worden gedaan.
Deze constructie maakt gebruik van het daadwerkelijke domein waaruit het beleid is opgehaald. Kort het niet in tot een bekende ouder alleen maar omdat die ouder op het merk van de organisatie lijkt. Op dezelfde manier wordt het lokale deel van een mailto-adres niet ingevoegd in de DNS eigenaarnaam. Behoud de oorspronkelijke URI en de geparseerde bestemmingshost, zodat reviewers kunnen zien hoe de geconstrueerde naam uit de invoer volgt. RFC 9990 , sectie 4
Valideer het antwoord in plaats van een bekende tekenreeks te herkennen
De geretourneerde records worden geparseerd als tag-waardelijsten. De verplichte v=DMARC1 tag moet eerst verschijnen en een puntkomma aan het einde is optioneel. Records die de opgegeven parseringstest niet doorstaan, worden verwijderd. Tenminste één overblijvend kwalificerend record legt de externe rapportageregeling vast in het kader van de procedure. Een leeg antwoord, een niet-gerelateerde TXT waarde of een record met de verkeerde versieplaatsing ontstaat er geen toestemming.
De waarde van de DMARC -versie is hoofdlettergevoelig: DMARC1 is de vereiste waarde, geen benadering in kleine letters of een nieuw uitgevonden protocolversie. Regels voor het vergelijken DNS namen mogen niet worden verward met de case-vereiste van de versiewaarde. Bij een beoordeling moeten de exacte antwoordbytes en recordgrenzen behouden blijven, in plaats van dat details vóór validatie worden weggenormaliseerd. RFC 9990 , sectie 4; RFC 9989 , sectie 4.7 en 4.8
Respecteer override- en faalgedrag
Een autorisatierecord kan volgens de procedure een overschrijving van de rapportagebestemming opleveren. De overschrijvende URI moet dezelfde bestemmingshost gebruiken die aan het begin is geëxtraheerd. Deze beperking voorkomt dat een autorisatiereactie het proces omleidt naar een keten van niet-gerelateerde ontvangers. Als de bevestiging een overschrijving met een andere host bevat, mag de rapportgenerator geen rapport genereren naar de oorspronkelijke of overschrijvings-URI.
Als verificatie de autorisatie niet bevestigt, moet de externe URI worden genegeerd. Een tijdelijke DNS fout heeft zijn eigen behandeling: de ontvanger kan ervoor kiezen om de bezorging tijdelijk te laten mislukken, zodat de verificatietest later kan worden herhaald. Bewaar die toestemming als MEI, niet als een universele garantie voor opnieuw proberen of een beschrijving van een geteste implementatie. Een succesvolle DNS controle bewijst nog steeds niet dat de bestemmingsmailbox bestaat, de rapportgrootte accepteert of het beoogde klantendashboard voedt. RFC 9990 , sectie 4
Maak onderscheid tussen verzamelde en mislukte rapportverzoeken
Voor geaggregeerde rapporten, de procedure is geassocieerd met rua. Storingsrapportage wordt afzonderlijk gespecificeerd in RFC 9991. Voor bestemmingen voor externe foutrapporten vereist dat document dezelfde externe verificatieprocedure, waarbij ruf wordt vervangen waar rua voorkomt. Beschouw foutrapportage niet als automatisch ingeschakeld, alleen maar omdat er verzamelde rapporten stromen, of kopieer de verzamelde bestemmingsafhandeling zonder het afzonderlijke rapporttype te bevestigen.
Mislukkingsrapporten zorgen voor extra zorgen over de blootstelling aan gegevens, omdat de inhoud gedetailleerder kan zijn dan geaggregeerde samenvattingen. Een correct DNS autorisatierecord is geen vervanging voor de beslissing van een organisatie over welke gegevens mogen worden gedeeld, met wie en voor welk doel. Dit manuscript geeft geen toestemming om feitelijke rapporten op te vragen, te verzenden of te uploaden. Elke echte opstelling moet voldoen aan de toepasselijke privacy-, ontvanger- en operationele goedkeuringen. RFC 9991 , sectie 5 en 7
Fictief constructie- en acceptatiewerkblad
Stel dat er een fictief beleid is opgehaald van blue.example.com en dat verzamelde rapporten worden opgevraagd via mailto:reports@red.example.net. De geconstrueerde autorisatie-eigenaar is blue.example.com._report._dmarc.red.example.net . Een hypothetisch TXT antwoord waarvan de volledige waarde v=DMARC1; voldoet aan de geïllustreerde versie-eerste vereiste. Er is geen DNS query uitgevoerd en dit voorbeeld beweert niet dat de namen records hebben gepubliceerd.
Het werkblad moet het resultaat van de beleidszoekopdracht, het ontdekte beleidsdomein, de oorspronkelijke rapportage-URI, de bestemmingshost, de vergelijking tussen organisatie en domein, de samengestelde eigenaar, het querytype, de tijdstempel, de exact geretourneerde records en het parseerresultaat behouden. Voeg een apart veld toe voor elke overschrijving en bevestig de hostbeperking ervan. Een recensent zou de naam moeten kunnen reconstrueren zonder te vertrouwen op een screenshot van de provider of de verkorte weergave van een DNS editor.
Gebruik een tweede acceptatiesectie voor verzameling: bedoeld account, bestemmingsmailbox, geautoriseerd rapporttype en pijplijneigenaar. Deze velden beschrijven een geplande verificatieworkflow en niet het voltooide opnamebewijs. Houd het resultaat van de DNS relatie gescheiden van ontvangst, parsering, toewijzing van tenants en dashboardpresentatie. Een toestemmingscontrole kan slagen terwijl een ander deel van het verzamelpad onopgelost blijft.
Publicatie en implementatie houden stand
De catalogus vereist de constructie van de exacte autorisatie-lookup van bron- en bestemmingsdomeinen en verificatie van het antwoord. Dit ontwerp levert slechts een fictieve constructie op. Een daadwerkelijk antwoord, het oorspronkelijke transcriptie van de zoekopdracht en de implementatie van het ontvangende domein blijven open. Er is geen DNS record gepubliceerd, er is geen mailbox geopend en er is geen rapport verzonden.
Voordat u het als operationele walkthrough vrijgeeft, moet u geautoriseerd bewijsmateriaal verkrijgen voor de exacte productierelatie en een gekwalificeerde reviewer de context voor het ontdekken van het beleid, het parseren van versies en de afhandeling van overschrijvingen laten bevestigen. Bewaar de brondatum en maak onderscheid tussen standaardvereisten en providerspecifieke account-onboarding. Alle zes de vrijgavepoorten blijven open, inclusief origineel bewijsmateriaal, menselijke beoordeling, toepasbaarheid van de bron, productieroutes, visuele toegankelijkheid en vrijgave door de eigenaar.
Een latere wijziging aan het doel- of beleidsdetectiedomein kan de vereiste autorisatie-eigenaar wijzigen. Beschouw het als een nieuwe relatie om te verifiëren, in plaats van aan te nemen dat een oude positieve controle elk toekomstig rapportageadres dekt. Het nuttige resultaat is een controleerbare toestemmingsketen, en niet slechts een gekopieerde TXT waarde.