Vælg en DKIM nøglekonfiguration, der opfylder protokollen og fungerer på tværs af de systemer, der sender og modtager din post. Et større antal i et kontrolpanel er ikke en fuldstændig sikkerhedsbeslutning. Registrer algoritmen, nøgletypen og modtagerbeviset, og hold kryptografisk styrke adskilt fra levering og justering.
Brug de opdaterede RSA-krav
RFC 8301 opdaterer den ældre DKIM specifikation. For RSA skal signeringsnøgler være på mindst 1024 bit, og underskrivere skal bruge mindst 2048 bit. Verifikatorer skal understøtte validering med RSA-nøgler fra 1024 til 4096 bit, understøtter muligvis større nøgler og må ikke acceptere RSA-nøgler under 1024 bit som gyldige. En verifikator kan stadig anvende en lokal politik baseret på nøglelængde.
Den samme RFC forbyder rsa-sha1 til signering og verifikation. Brug ikke et forældet selvstudies SHA-1-eksempel som en aktuel implementeringsanbefaling. Tjek den faktiske a= værdi i en modtaget DKIM-Signature og nøgletypen nåede gennem dens vælger, i stedet for at stole på en administrators erindring om den oprindelige opsætning.
Minimum og anbefaling besvarer forskellige spørgsmål. En 1024-bit RSA-nøgle kan opfylde den angivne bund uden at opfylde det stærkere anbefalede valg. Hvis organisationen beholder den på grund af en dokumenteret systembegrænsning, skal du registrere undtagelsen, ejeren og fjernelsestilstanden. Beskriv ikke denne undtagelse som den universelle bedste konfiguration.
Tjek tjenesten, før du genererer nøgler
Afgør, om udbyderen administrerer nøgler eller accepterer kundeleveret materiale. Amazon SES Easy DKIM dokumenterer en 2048-bit misligholdelse; at produktadfærd ikke bør generaliseres til alle mailplatforme. Nogle tjenester viser kun et understøttet sæt af muligheder. En genereret 4096-bit nøgle er ubrugelig, hvis den tilsigtede underskriver ikke kan indlæse den, eller DNS klargøringsstien ødelægger dens offentlige registrering.
RFC 8463 tilføjer Ed25519-SHA256: underskrivere bør implementere det, og verifikatorer skal implementere det under denne specifikation. Dens nøglestørrelser er ikke numerisk sammenlignelige med RSA-størrelser som tilsvarende sikkerhedsforanstaltninger. Support i standarden demonstrerer ikke understøttelse i enhver installeret underskriver, modtager eller administrationsgrænseflade. Behandl en algoritmemigration som en kompatibilitetsændring med eksplicitte beviser, ikke som en kosmetisk indstilling. RFC 8463 afsnit 6 tillader parallel RSA og Ed25519 underskrifter under overgang; de skal bruge separate vælgere, fordi hver vælger identificerer en enkelt nøglepost. Kontroller, at den faktiske signeringstjeneste understøtter denne tilgang, før du planlægger den.
Byg en nyttig valideringsmatrix
For hver afsendelsesrute skal du registrere softwaren eller udbyderen, algoritme, nøglestørrelse, hvor det er relevant, vælger, udgivelsesmetode og et repræsentativt modtagesystem. Adskil tre tests: underskriveren accepterer konfigurationen, den offentlige nøgle løses intakt, og en modtager bekræfter en meddelelse, der er produceret af denne underskriver.
En illustrativ migrering starter med en ældre 1024-bit RSA-faktureringsunderskriver. Det foreslåede mål er 2048-bit RSA med SHA-256. Udgiv en ny vælger ved hjælp af platformens understøttede proces, verificer nøglen, send gennem faktureringsapplikationen og inspicér det modtagende resultat. En test fra en medarbejderpostkasse beviser ikke, at faktureringsapplikationen er skiftet. Behold kun den gamle afhængighed for den planlagte overgang og lovlig forsinket post, medmindre hændelsessvar dikterer andet.
Fortolk fejl præcist
Hvis en større post ikke offentliggøres, skal du undersøge DNS grænsefladen og TXT -repræsentationen, før du svækker kryptografien. Hvis verifikationen rapporterer en ikke-understøttet algoritme, skal du beholde denne konstatering mod den faktiske modtager og softwareversion. Hvis DKIM består men DMARC mislykkes, inspicér identitetsjustering i stedet for at ændre nøglestørrelse igen.
Dokumenter, hvad der blev testet, og hvad der forbliver ukendt. En prøve af vellykkede modtagere er nyttigt operationelt bevis, ikke en garanti, der dækker hele internettet. Planlæg gennemgang, når udbyderen, kryptografisk vejledning eller vigtig modtagerpopulation ændres. Beslutningen er forsvarlig, når dens krav, implementeringsgrænser og observerede resultater alle er synlige.
Relateret læsning
RSA og Ed25519 DKIM signaturer: implementeringsspørgsmål og interoperabilitet · DKIM public-key syntaks: identificer trunkerede eller misdannede DNS værdier.
Registrer beslutningen før udrulning
- Aktuel rute: applikation, ejer, signeringsdomæne, vælger og udsendt algoritme.
- Foreslået valg: understøttet RSA-SHA256 ved 2048 bit eller stærkere, hvor det er berettiget, eller en understøttet Ed25519-overgang.
- Acceptbevis: underskriver indlæser nøglen; DNS serverer den intakt; et betroet modtagende system bekræfter en besked fra denne applikation.
- Stoptilstand: Ikke-understøttet algoritme, forkert udformet nøgle eller manglende signatur. Løs den defekt, før du trækker den fungerende vælger tilbage.
- Undtagelse: hvis du beholder 1024-bit RSA, navngiv begrænsningen, risikoejeren og datoen for revurdering.