Domænekonsolidering er en afhængighedsmigrering, ikke kun en rebranding-øvelse. En virksomhed holder muligvis op med at vise et gammelt domæne, mens fakturaer stadig forlader sin underskriftstjeneste, afvisningshåndtering forbliver knyttet til det, og rapporter ankommer stadig i dens postkasse. Den sikre sluttilstand er et eksplicit ejet sæt af overlevende afhængigheder og en godkendt pensionsjournal for alt fjernet.
Adskil de identiteter, der flyttes
List hver synlig fra domæne, konvolutafsender domæne, DKIM underskrive domæne og vælger, svaradresse, indgående rute og rapporteringsdestination. Inkluder servicekontoen og teamet, der driver hver enkelt. DMARC justering relaterer en autentificeret identifikator til forfatterdomænet; ændring af den synlige adresse kan derfor ændre resultatet, selv når den gamle tjeneste fortsætter med at godkende. RFC 9989.
Kortlæg afhængigheder efter nøjagtigt DNS ejernavn og mål. An SPF include kan tjene flere applikationer. En vælger CNAME kan holde en udbyder i kontrol over nøglepublikation. En delegeret zone kan indeholde ikke-relaterede tjenester. Slet ikke alle poster, der bærer det gamle mærkenavn som en enkelt oprydningsoperation. Adskil beslutningen om at stoppe afsendelsen fra beslutningen om at stoppe med at modtage og fra beslutningen om at opgive registreringen.
Planlæg sameksistens omkring observeret trafik
Opret en overgangsrække for hver tjeneste med dens gamle og nye identiteter, ejer, planlagt overlap, køadfærd, testsager og tilbagerulningstilstand. Eksporter rapporthistorik og -konfiguration, før du fjerner adgangen til den tidligere administrationstjeneste. Et fungerende dashboard er ikke et bevis på, at den nye rapporteringsdestination modtager og behandler aktuelle data. Eksterne rapportdestinationer har autorisationskrav i rapporteringsspecifikationen. RFC 9990.
Hold overlapningen længe nok til at tage højde for den faktiske anvendelse og leveringsadfærd, du har målt. Foreskriv ikke et universelt antal dage. DKIM offentlige nøgler kan stadig være nødvendige for at bekræfte meddelelser, der er signeret før en vælgerændring; cachelagrede DNS og meddelelser i kø komplicerer en øjeblikkelig fjernelse. Dokumentér den risikobaserede beslutning om opbevaring med det team, der betjener underskriveren. RFC 6376.
Anvend en skriftlig afhængighedsport
Overvej illustrativ plan DEMO-RETIRE-01. Mail Operations er den foreslåede ejer, ikke et team, der har accepteret en reel ændring. Den gamle identitet er invoice@oldbrand.test med bounce@oldbrand.test og DKIM d=oldbrand.test, selector old1. Den foreslåede nye identitet er invoice@newbrand.test med bounce@newbrand.test og d=newbrand.test, selector new1. Nøjagtig lighed ville give justering, hvis godkendelsen bestå; faktiske signaturer, DNS tilstand og modtagerbeviser leveres ikke.
- Vælgerport: gammel1. _domainkey.oldbrand.test forbliver i venteposition, fordi scenariet angiver to meddelelser med gammel identitet i kø. Ny1. _domainkey.newbrand.test er kun et foreslået mål. Indhent ægte kø/afløb og modtagerbekræftelse, før du trækker den gamle nøgle tilbage.
- Reporting gate: reports@oldcollector.test er den gamle destination og reports@newcollector.test den foreslåede erstatning. Godkendelse til ekstern destination, ankomst af ny rapport, parsing, operatørmeddelelse og eksport af bevaret historik er alle ubekræftede. Hold kontinuiteten uløst i stedet for at behandle et dashboard som bevis.
- Shared-authority gate: en SPF -inkludering af shared-sender.test er fastsat til at understøtte både fakturering og kampagne. Behold det, indtil kampagnens ejer bekræfter migrering eller godkendt tilbagetrækning; faktureringsafslutning alene kan ikke fjerne delt autoritet.
Den foreslåede tilbagerulning er kun at genskabe den nøjagtige godkendte tidligere identitet og registrere forskel, hvis kritiske nye strømme fejler, efter at have kontrolleret, om denne gendannelse genindfører en eksponering. Tidligere konfigurationsbytes, eksporteret rapporthistorik og eksportsammendrag er ikke leveret. Ingen hash, kryptografisk signatur eller rapportpipeline blev udført for denne skriftlige plan. Før en reel ændring skal du bevare disse artefakter og definere evidensbaserede exitkriterier, et observationsvindue og en beslutningsejer.
Luk pension uden at miste domænet
Kør godkendte tests for kritiske gamle og nye flows, inklusive svar, afvisninger og mindre hyppige planlagte job. Fjern kun de afhængigheder, der er omfattet af ændringen, verificer autoritativt DNS og modtagerbevis, og registrer resterende undtagelser med en ejer- og gennemgangsdato. Opbevaring af registrering er en separat forretnings- og sikkerhedsbeslutning: ikke længere afsendelse betyder ikke, at domænet er sikkert at frigive.
Luk migreringen, når beviserne understøtter de aftalte exitkriterier, ikke når det nye logo vises i en meddelelse. Hold den tidligere tilstand og den nøjagtige godkendte forskel tilgængelig for respondenter. Hvis verifikationen mislykkes, skal du bruge den registrerede genopretningsplan og vurdere, om genoprettelse af en gammel myndighed ville genindføre en sikkerhedseksponering.