A DMARC rollback bør genoprette den tilsigtede kommunikation, samtidig med at den nødvendige dokumentation bevares for at forklare, hvad der skete. Redigering af posten er kun en del af jobbet. Teamet skal også vide, hvilken lovlig tjeneste der fejlede, hvilken politik en modtager kunne have set, og hvad der retfærdiggør et nyt forsøg.
Forbered denne gendannelsessti før ændringen. Når en hændelse ankommer, er en tidligere værdi, navngivet ejer og testet godkendelsesrute mere nyttige end en improviseret søgning gennem skærmbilleder.
Registrer den tilstand, der kunne have brug for restaurering
Gem hele postsættet ved det nøjagtige berørte DNS ejernavn sammen med dets TTL, autoritative servere og indsamlingstid. Bevar gældende overordnede og underdomænepolitikker, når de har betydning for opdagelse. En kopieret p-værdi alene kan udelade rapporteringsadresser eller justering indstillinger, der blev ændret på samme tid.
Behold den godkendte ændring som en læsbar diff. Identificer formålet med hvert ændret tag og den autoriserede person, der kan gendanne den tidligere konfiguration. Gennemgå opdagelse af underdomænepolitik før man antager, at redigering af en overordnet post ændrer hvert barns vurdering.
Gem DNS administrationsbeviser adskilt fra følsomme meddelelsesprøver. Begge har brug for passende adgang, men en hændelsesregistrering behøver ikke at gengive en kundes fortrolige indhold.
Definer en trigger, der adskiller fiasko fra mistanke
Vælg konkrete tilbagerulningskriterier for ændringen: for eksempel en bekræftet afvisning af et kritisk legitimt flow, der kan tilskrives den nye politik, og en manglende evne til at reparere dette flow inden for det aftalte svarvindue.
En støtteklage alene starter en undersøgelse; det fastslår ikke DMARC som årsag. Indfang den fulde returnerede SMTP tekst, service og konto, tid, modtagerdomæne, synlig fra domæne og tilgængelige sendelogfiler. For leveret post skal du beholde en repræsentativ original meddelelse og betroede modtagergodkendelsesresultater under RFC 8601 §7.1.
En lav samlet beståelsesprocent alene kræver også kontekst. Uautoriseret trafik kan fejle under en sund implementering. Spørg, hvilken lovlig forretningsrute der er berørt, før du svækker politikken.
Adskil en afsenderreparation fra en politikgendannelse
Hvis en applikation har en forkert signeringsidentitet, kan en understøttet applikationskorrektion være den passende gendannelse. Hvis den brede politikændring har en konsekvens, skal du gendanne den godkendte tidligere politik, mens den pågældende ansøgning undersøges.
Undgå at ændre SPF, DKIM, DMARC og afsenderplatformen på én gang, medmindre hændelsen kræver det, og hver ændring registreres. Flere samtidige redigeringer gør det sværere at tilskrive forbedringer eller fejl.
Gendannelse af politikken reparerer ikke den underliggende godkendelses- eller justeringsfejl. Hold den defekt åben med en ejer, beviser og et krav om gentest.
Øv en kontrolleret gendannelse
Denne fiktive øvelse illustrerer registreringen, ikke en egentlig produktionstest:
- Tid: 10:00 UTC; Hændelse: Godkendte politikændringer fra ingen til karantæne; Bevarede beviser: Fuldfør gamle og nye rekordsæt, TTL og godkendelse
- Tid: 10:08 UTC; Hændelse: Faktura workflow modtager en politikrelateret afvisning; Bevaret bevis: Returneret svar, afsendelse af konto- og meddelelses-id'er
- Tid: 10:13 UTC; Hændelse: Hændelsesejeren godkender den planlagte gendannelse; Bevaret bevismateriale: Beslutning og berørt omfang
- Tid: 10:16 UTC; Hændelse: Tidligere komplet DMARC værdi gendannet ved samme ejernavn; Beviser bevaret: Autoritativt DNS svar og ændringskvittering
- Tid: 10:26 UTC; Hændelse: Et kontrolleret fakturagentagelsesforsøg accepteres hos en testmodtager; Bevarede beviser: Nyt SMTP resultat og modtaget autentificeringsbevis
Den sidste række viser det pågældende genforsøg gennem den rute. Det beviser ikke, at hver modtager har kasseret et tidligere cachelagret svar, eller at alle kundebeskeder er gendannet.
Under en genhør skal du udøve den rigtige administrations- og godkendelsesrute i et passende testmiljø. Registrer, hvem der kan foretage ændringen, og hvad der sker, hvis den pågældende person eller DNS udbyder ikke er tilgængelig.
Forvent at DNS visninger og rapportperioder overlapper hinanden
En resolver kan beholde et tidligere DNS svar; RFC 8767 §4 tillader kvalificerende brug af uaktuelle svar efter TTL-udløb, så TTL er ikke en garanteret global fjernelsesfrist. Sænkning af en TTL, efter at en resolver har cachelagt et tidligere svar med længere levetid, forkorter ikke svarets resterende cachelevetid med tilbagevirkende kraft.
Efter gendannelse af posten skal du forespørge på de autoritative servere og relevante rekursive visninger og derefter teste den berørte mailrute igen. Et frisk autoritativt svar beviser zonens aktuelle data; det beviser ikke, hvad enhver fjernmodtager bruger i øjeblikket.
Hold rapporteringen aktiv, hvor det er relevant. RFC 9990 §3.3 forklarer, at en politikændring inden for en rapporteringsperiode kan producere en rapport, der kombinerer dispositioner under forskellige politikversioner. Nogle implementeringer kan i stedet producere flere rapporter. Anmærk hændelsestidslinjen i stedet for at behandle et enkelt politikfelt som bevis på, at hver meddelelse i perioden brugte den nøjagtige version.
Gendan en komplet, gyldig konfiguration
Brug det nøjagtige tiltænkte ejernavn og afstem det eksisterende rekordsæt. Under RFC 9989 §4.10, tilføj ikke en anden DMARC politik ved siden af den første i et forsøg på at tilsidesætte den. Behold de godkendte rapporteringsdestinationer og enhver nødvendig ekstern destinationstilladelse i henhold til RFC 9990 §4 medmindre gendannelsen eksplicit ændrer dem.
Tjek hele den resulterende politik for utilsigtede ændringer. En gendannelse, der lydløst ændrer justering eller subdomæneomfang, er en ny politisk beslutning, ikke blot gendannelse.
Bruge rekordens arbejdsgang til udgivelse og rapporteringsvejledningen til fortolkning af de efterfølgende beviser.
Luk genopretning og afhjælpning separat
Gendannelse etableres, når de definerede berørte arbejdsgange opfylder de aftalte tests, og konfigurationen er verificeret inden for dens kendte grænser. Udbedring lukker kun, når årsagen er forstået, og afsendelsesruten er blevet rettet, eller den påtænkte politik er blevet genovervejet.
Den næste ændring bør omfatte de manglende beviser, der forårsagede, at det første forsøg mislykkedes. Interoperabilitetsvejledningen i RFC 9989 §7.4 betyder også, at afvisning kan være upassende for et generelt medarbejderdomæne. En mislykket ændring kan afsløre, at selve den foreslåede politik kræver en anden beslutning.
Behold de originale beviser, mislykket resultat, genskab beslutningen og vellykket gentest sammen. Det spor gør den næste godkendelse hurtigere, fordi den forklarer, hvad der er ændret, hvad der er genoprettet, og hvad der forbliver uløst.
Hold den næste handling specifik
I den fiktive tidslinje er 10:26-accepteringen én gendannelsesobservation, ikke et bevis på, at autentificeringsfejlen blev repareret. Hold afsender-afhjælpningselementet åbent, og sammenlign de faktiske nye metoderesultater separat. Tidslinjen på 26 minutter er ikke et løfte om genopretning eller et anbefalet venteinterval. Ingen DNS gendannelse, godkendelse eller meddelelsesforsøg fandt sted for denne artikel.