Velg en DKIM nøkkelkonfigurasjon som tilfredsstiller protokollen og fungerer på tvers av systemene som sender og mottar e-posten din. Et større antall i et kontrollpanel er ikke en fullstendig sikkerhetsbeslutning. Registrer algoritme, nøkkeltype og mottakerbevis, og hold kryptografisk styrke atskilt fra levering og justering.
Bruk de oppdaterte RSA-kravene
RFC 8301 oppdaterer den eldre DKIM spesifikasjonen. For RSA må signeringsnøkler være minst 1024 biter, og signere bør bruke minst 2048 biter. Verifikatorer må støtte validering med RSA-nøkler fra 1024 til 4096 biter, kan støtte større nøkler, og må ikke akseptere RSA-nøkler under 1024 biter som gyldige. En verifikator kan fortsatt bruke en lokal policy basert på nøkkellengde.
Den samme RFC forbyr rsa-sha1 for signering og verifisering. Ikke bruk en foreldet opplærings SHA-1-eksempel som en gjeldende distribusjonsanbefaling. Sjekk den faktiske a= verdi i en mottatt DKIM-Signature og nøkkeltypen nådde gjennom dens velger, i stedet for å stole på en administrators erindring om det opprinnelige oppsettet.
Minimum og anbefaling svarer på forskjellige spørsmål. En 1024-bits RSA-nøkkel kan møte den angitte etasjen uten å møte det sterkere anbefalte valget. Hvis organisasjonen beholder den på grunn av en dokumentert systembegrensning, noter unntaks-, eier- og fjerningsbetingelsen. Ikke beskriv det unntaket som den universelle beste konfigurasjonen.
Sjekk tjenesten før du genererer nøkler
Avgjør om leverandøren administrerer nøkler eller godtar kundelevert materiale. Amazon SES Easy DKIM dokumenter a 2048-bit misligholde; at produktadferd ikke bør generaliseres til alle e-postplattformer. Noen tjenester viser bare et støttet sett med alternativer. En generert 4096-bits nøkkel er ubrukelig hvis den tiltenkte signeren ikke kan laste den eller DNS klargjøringsbanen ødelegger den offentlige posten.
RFC 8463 legger til Ed25519-SHA256: underskrivere bør implementere det og verifikatorer må implementere det under den spesifikasjonen. Nøkkelstørrelsene er ikke numerisk sammenlignbare med RSA-størrelser som tilsvarende sikkerhetstiltak. Støtte i standarden viser ikke støtte i alle utplasserte signerer, mottakere eller administrasjonsgrensesnitt. Behandle en algoritmemigrering som en kompatibilitetsendring med eksplisitte bevis, ikke som en kosmetisk setting. RFC 8463 seksjon 6 tillater parallell RSA og Ed25519 signaturer under overgang; de må bruke separate velgere fordi hver velger identifiserer en enkelt nøkkelpost. Kontroller at den faktiske signeringstjenesten støtter denne tilnærmingen før du planlegger den.
Bygg en nyttig valideringsmatrise
For hver senderrute registrerer du programvaren eller leverandøren, algoritme, nøkkelstørrelse der det er relevant, velger, publiseringsmetode og et representativt mottakssystem. Skill tre tester: underskriveren godtar konfigurasjonen, den offentlige nøkkelen løses intakt, og en mottaker bekrefter en melding produsert av den underskriveren.
En illustrativ migrering starter med en eldre 1024-biters RSA-faktureringsunderskriver. Det foreslåtte målet er 2048-bit RSA med SHA-256. Publiser en ny velger ved å bruke plattformens støttede prosess, verifiser nøkkelen, send gjennom faktureringsapplikasjonen og inspiser mottaksresultatet. En test fra en ansattpostkasse beviser ikke at faktureringsapplikasjonen er byttet. Behold den gamle avhengigheten kun for den planlagte overgangen og legitim forsinket post, med mindre hendelsesrespons tilsier noe annet.
Tolk feil presist
Hvis en større post ikke publiseres, undersøk DNS grensesnittet og TXT representasjonen før du svekker kryptografien. Hvis verifiseringen rapporterer en algoritme som ikke støttes, beholder du dette funnet mot den faktiske mottakeren og programvareversjonen. Hvis DKIM består men DMARC mislykkes, inspiser identitetsjusteringen i stedet for å endre nøkkelstørrelsen igjen.
Dokumenter hva som ble testet og hva som forblir ukjent. Et utvalg av vellykkede mottakere er nyttig operativt bevis, ikke en garanti som dekker hele internett. Planlegg gjennomgang når leverandøren, kryptografisk veiledning eller viktig mottakerpopulasjon endres. Beslutningen er forsvarlig når dens krav, gjennomføringsgrenser og observerte resultater er synlige.
Relatert lesing
RSA og Ed25519 DKIM signaturer: distribusjonsspørsmål og interoperabilitet · Syntaks for offentlig DKIM -nøkkel: identifiser avkortede eller misformede DNS verdier.
Registrer beslutningen før utrulling
- Gjeldende rute: applikasjon, eier, signeringsdomene, velger og utsendt algoritme.
- Foreslått valg: støttet RSA-SHA256 på 2048 biter eller sterkere der det er berettiget, eller en støttet Ed25519-overgang.
- Akseptbevis: underskriver laster inn nøkkelen; DNS serverer den intakt; et pålitelig mottakssystem bekrefter en melding fra denne applikasjonen.
- Stopptilstand: ustøttet algoritme, feil utformet nøkkel eller manglende signatur. Løs den feilen før du trekker tilbake den fungerende velgeren.
- Unntak: hvis du beholder 1024-bits RSA, navngi begrensning, risikoeier og dato for revurdering.