En planlagt DKIM rotation ændrer, hvilken privat nøgle, der signerer ny post, samtidig med at det bekræftelsesmateriale, der er nødvendigt for meddelelser, der allerede er i transit, bevares. Udgivelse af en ny offentlig nøgle, skift af underskriver og tilbagetrækning af den gamle vælger er separate stadier.
Start med underskriftstjenesten og dens understøttede rotationsprocedure. En udbyderstyret vælgerdelegation har en anden driftsmodel end et nøglepar, der styres direkte af din organisation.
Etabler den aktuelle underskriftstilstand
Brug originale modtagne beskeder til at identificere de faktiske d=-signeringsdomæner og s=-vælgere. Korreler dem med signeringstjenesten, nøglestyringsmodellen og virksomhedsejeren.
En DNS post kan eksistere uden at blive brugt af aktuelle beskeder. Omvendt kan en gammel besked henvise til en vælger, der ikke længere er det aktive valg for ny post.
Gem de relevante offentlige svar og konfigurationstilstand. Opbevar private signeringsnøgler i det autoriserede signeringssystem, ikke i en billet, et lagerregneark eller en offentlig DNS post.
Bekræft algoritmen og udbyderens krav
Gennemgå den aktuelle kryptografiske vejledning og understøttet verifikationsadfærd. RFC 8301 §3 udelukker rsa-sha1 og stiller krav til RSA-nøglestørrelse; det anbefaler RSA-nøgler på mindst 2048 bit. RFC 8463 §5 definerer Ed25519-SHA256 som en ekstra metode.
En algoritmes specifikation og den faktiske støtte fra de involverede afsendere, udbydere og modtagere er forskellige beviser. Ændr ikke en produktionstjeneste til en metode, dens understøttede konfiguration ikke kan bruge.
For udbyderstyret signering skal du følge dens genererede værdier og rotationsproces. Et DNS alias kan uddelegere nøglehåndtering uden at give dit team den private nøgle eller en manuel cutover-kontrol.
Udgiv nyt verifikationsmateriale før cutover
Hvis det understøttede design bruger en ny vælger, skal du først offentliggøre dets korrekte offentlige verifikationsmateriale. Bekræft den endelige ejers navn, svar og eventuel delegationskæde.
Brug en anden vælger til en ny nøgle, hvor den understøttede procedure tillader det. Udskiftning af nøglen under én vælger kan efterlade meddelelser, der er signeret med den gamle nøgle, der ikke er i stand til at verificere mod erstatningen.
Fjern ikke den gamle nøgle, blot fordi det nye DNS svar ser korrekt ud. På dette stadium har du etableret offentliggørelse, ikke at underskriveren har skiftet, eller at hver modtager kan hente det tilsigtede materiale.
Skift signering og bekræft nye beskeder
Brug den autoriserede underskriftsprocedure til at begynde at underskrive med den nye nøgle. Send repræsentative beskeder gennem vigtige ruter og inspicer de originale modtagne signaturer og pålidelige resultater.
I en syntetisk rotation bruger tidligere mail s=old2026 og ny mail bruger s=new2026. Begge offentlige verifikationsnavne forbliver tilgængelige under det planlagte overlap, mens nye modtagne meddelelser demonstrerer den tilsigtede vælger og en forbigående signatur.
Hvis en gateway ændrer meddelelsen efter signering, er en direkte test før den gateway ufuldstændig. Tjek den komplette forretningsrute og DMARC justering samt det rå signaturresultat.
Vælg pensionering fra leveringsbetingelserne
RFC 6376 §3.1 beskriver samtidig offentliggørelse under overgangen, hvor post stadig kan være i transit. Det giver ikke én universel overlapningsvarighed for hver organisation.
Vurder køer, genforsøgsadfærd, forventede leveringsforsinkelser, DNS cache-adfærd, relevant signaturudløb og verifikationsbehov. Registrer årsagen til det valgte overlap og eventuelle udbyderbegrænsninger.
Træk kun det gamle verifikationsmateriale tilbage under den understøttede proces, når denne vurdering berettiger det. En senere kontrol af en gemt besked kan afvige fra dens oprindelige leveringstidsresultat efter nøgleudtrækning.
Behandl formodet kompromis som en anden beslutning
Rutinemæssig rotation sigter mod kontinuitet. Et mistænkt kompromittering af privat nøgle kan kræve akut begrænsning eller tilbagetrækning på trods af potentiel verifikationspåvirkning på ældre post.
Følg organisationens hændelsesproces og signeringsudbyderens understøttede svar. Bevar beviserne og forklar afvejningen. Lov ikke, at et overlap, der er egnet til rutinemæssig vedligeholdelse, er egnet under et aktivt kompromis.
Luk med en verificerbar underskriftspost
Behold tjenesten, ejeren, gamle og nye vælgere, publikationsbeviser, observation af cutover, overlapningsrationale, pensionsbeslutning og repræsentant modtagne resultater.
De vælgervejledning forklarer identitetsopslaget. Til Microsoft 365 eller Workspace skal du bruge deres lejerspecifik eller valgt domæne konfigurationsvejledning. En rotation er afsluttet, når den nye signeringsrute er verificeret, og den gamle afhængighed er blevet trukket tilbage af en dokumenteret årsag.
Brug tre separate acceptchecks
Denne foreslåede tjekliste er ikke en rekord af gennemført rotation. Før cutover skal du bekræfte, at den nye vælger løses til den genererede offentlige værdi, mens den gamle vælger forbliver tilgængelig. Efter cutover skal en nyligt modtaget ansøgningsmeddelelse vise s=new2026 og det tilsigtede d-domæne med et betroet pass. Inden pensionering skal du bekræfte, at de aftalte kø-/genforsøgs- og verifikationsbetingelser er opfyldt, og beslutningen registreres. Et pass fra en ikke-relateret applikation lukker ikke den berørte rute. Gør ikke et eksempelinterval til en universel ventetid.