Tilføjelse af en anden rua-destination kan hjælpe med at sammenligne samlere eller bevare en uafhængig kopi. Det skaber også to leverings- og behandlingsveje, der kan være uenige. Definer, hvad den anden destination skal bevise, før du behandler dens dashboard som en sikkerhedskopi af den første.
Forstå leveringsanmodningen
Referencer: RFC 9990 §3.5, RFC 9990 §4.
RFC 9990 afsnit 3.5 kræver, at en rapportør evaluerer de anførte URI'er i rækkefølge og forsøger at levere til de resterende gyldige URI'er op til dens understøttede grænse. Dette er ikke et løfte om, at hver modtager implementerer den samme destinationskapacitet, eller at hvert forsøg på levering lykkes. Tjek hver destinations berettigelse, inklusive autorisation til ekstern destination, hvor det er relevant.
To mailto-destinationer i den samme gyldige anmodning er ikke instruktioner til at dele rapportens meddelelsesantal mellem dem. Når tilsvarende rapporter når begge, beskriver deres tællinger de samme observationer. Tilføjelse af begge samleres totaler kan dobbelttælle trafik.
Forbered begge indsamlingsveje
Registrer den nøjagtige offentliggjorte anmodning, postkasserouting, destinationsejer og relevante autorisationsposter. Få ejerne til at bekræfte accept af vedhæftede filer, postkassekapacitet og parserunderstøttelse. Tilføjelse af en tredjepartsdestination udvider også, hvem der modtager driftsdata, så godkend dette adgangs- og opbevaringsformål, før du foretager ændringen.
Behold den eksisterende arbejdssti under en kontrolleret sammenligning, hvis det er godkendt. Foretag kun den tilsigtede destinationsændring og bevar dens tidligere værdi. Ændr ikke håndhævelsespolitikken og parseren samtidigt, hvis målet er at forstå indsamlingsforskelle.
Sammenlign rapporter før dashboards
Referencer: RFC 9990 §3.5.1, RFC 9990 §3.5.4.
Byg en sammenligning, der indtastes efter reporter, politikdomæne, rapportidentitet og rapporteringsinterval. Behold vedhæftede fingeraftryk og ankomsttidsstempler. Tjek, om en manglende dashboardpost aldrig blev modtaget, blev filtreret, mislykkedes ved parsing eller blev udelukket af et displayfilter.
Illustrativ case: samler A viser 800 observationer, mens samler B viser 600 for samme nominelle dag. Undersøgelsen finder én 200-observationsrapport i B's karantæne. Uoverensstemmelsen er samlingsside; det er ikke bevis for 200 yderligere meddelelser sendt gennem A. Hvis selve filerne er forskellige, bevar begge og undersøg i stedet for at tvinge totalerne til at matche.
Definer sammenligningens grænser
Referencer: RFC 9989 §5.3.8, RFC 9990 §3.5.
En vellykket parret ankomst demonstrerer netop disse leverancer. Den etablerer ikke fuldstændig modtagerdækning eller garanterer identiske fremtidige ankomster. Rapporter kan blive forsinket, prøvet igen eller kasseret, når levering ikke er tilgængelig. Forskellige dashboard-tidszoner og deduplikeringsregler kan også ændre viste totaler.
Luk kun migreringen efter en repræsentativ observationsperiode, matchede rapportprøver og en forklaret undtagelsesliste. Behold den gamle destination, indtil de godkendte fjernelseskriterier er opfyldt. Hvis en uoverensstemmelse forbliver uforklarlig, skal du markere sammenligningen som ufuldstændig i stedet for at vælge det større dashboard som sandheden.
Før et destinationssammenligningsregister
Gem for hver destination anmodningsrevision, autorisationskontrol, første matchede ankomst, sidste matchede interval og uafklarede undtagelser. Sammenlign det samme rå rapportsæt, før du sammenligner en leverandørs afledte kategorier. En samler kan klassificere en delt kilde anderledes uden at have modtaget anden XML. Adskil disse fortolkningsforskelle fra transporttab. Før du fjerner en adresse, skal du kontrollere dens kontraktmæssige opbevaring og eksportordninger og opnå godkendelse til fjernelsen. Behold en dateret eksport af sammenligningen, så en senere ændring kan skelnes fra den oprindelige migreringsbeslutning.
Fortsæt undersøgelsen
Brug gennemgang af samlet rapport at fortolke de underliggende felter og de alignment diagnose guide når et rågodkendelseskort ikke opfylder DMARC.
Udført syntetisk bevismateriale
Følgende er en lokalt genkørt offline syntetisk opstilling, ikke en live DNS , SMTP eller kundeobservation. Dens XML-input blev parset med Pythons standardbibliotek, og påstande kontrollerede de resulterende felter og beregninger. De simulerede DNS og e-mail-trin er leveret testinput, ikke bevis for, at en rigtig modtager udførte disse operationer. Fuld skemavalidering og produktionskildegodkendelse er uden for denne lille opstilling; levende beviser forbliver afventende.
Den leverede anmodning er _dmarc.brand.example TXT "v=DMARC1; p=none; rua=mailto:aggregate@collector.example,mailto:archive@archive.example". Disse reserverede eksempeldomæner antages at være separate organisatoriske domæner i armaturet. De to syntetiske godkendelsessvar er brand.example._report._dmarc.collector.example TXT "v=DMARC1" og brand.example._report._dmarc.archive.example TXT "v=DMARC1". Den lokale model matcher både de angivne autorisationsejernavne og deres versionsværdier under RFC 9990 §4. Den udfører ikke DNS forespørgsler eller den komplette autorisationsalgoritme. En produktionsimplementering skal udføre den komplette opdagelses- og godkendelsesprocedure i stedet for at antage disse domænegrænser.
Den bevarede rapport har ID R1, politikdomæne brand.example , date_range start 1772409600 and end 1772496000, source IP 192.0.2.10 og count 100. Dens evalueret justeret DKIM resultatet er bestået og justeret SPF er mislykket. Det rå SPF resultat er bestået for vendor.example , der illustrerer, hvorfor rå succes ikke er tilpasset succes. Disse felter parses fra XML i stedet for at udledes fra et dashboard.
Testen modellerer en vellykket 250-kvittering på hver destination og parser den samme vedhæftede fil på begge. Hver parser returnerer R1 og tæller 100. Sammenligningen registrerer to ankomster, men et observationssæt på 100, ikke et kombineret volumen på 200. Dette etablerer kun armaturets duplikat-kopi-aritmetik. For at erstatte simuleringen med ægte bevis, behold det faktiske anmodningsopslag, autorisationsopslag, kvitterings-id'er, beskyttede vedhæftede hashes og parserjoboutput for hver destination. Hvis en kvittering mangler, skal du registrere en uobserveret levering i stedet for at fremstille en matchende kopi.
Hold resultatet inden for det testede omfang
Den medfølgende lokale demonstration verificerer kun dens lille syntetiske parser, medfølgende scene-input og beregninger. Ingen reel DNS autorisation, SMTP levering, samlermigrering, udbyderdeltagelse eller produktionsdatabaseadfærd blev testet. Originale input forbliver arkiverede, og enhver live-sammenligning kræver sit eget beskyttede bevis og ansvarlig godkendelse.