Kies een DKIM sleutelconfiguratie die voldoet aan het protocol en werkt op de systemen die uw e-mail verzenden en ontvangen. Een groter getal in een controlepaneel is geen volledige veiligheidsbeslissing. Registreer het algoritme, het sleuteltype en het bewijs van de ontvanger, en houd de cryptografische sterkte gescheiden van de levering en uitlijning.
Gebruik de bijgewerkte RSA-vereisten
RFC 8301 werkt de oudere DKIM specificatie bij. Voor RSA moeten ondertekeningssleutels minimaal 1024 bits zijn en moeten ondertekenaars minimaal 2048 bits gebruiken. Verificateurs moeten validatie met RSA-sleutels van 1024 tot en met 4096 bits ondersteunen, mogen grotere sleutels ondersteunen en mogen RSA-sleutels van minder dan 1024 bits niet als geldig accepteren. Een verificateur kan nog steeds een lokaal beleid toepassen op basis van de sleutellengte.
Dezelfde RFC verbiedt rsa-sha1 voor ondertekening en verificatie. Gebruik het SHA-1-voorbeeld van een verouderde tutorial niet als huidige implementatieaanbeveling. Controleer de werkelijke a= waarde in een ontvangen DKIM-Signature en het sleuteltype dat via zijn wordt bereikt keuzeschakelaar, in plaats van te vertrouwen op de herinnering van een beheerder aan de oorspronkelijke installatie.
Het minimum en de aanbeveling beantwoorden verschillende vragen. Een 1024-bits RSA-sleutel kan aan de gespecificeerde vloer voldoen zonder aan de sterkere aanbevolen keuze te voldoen. Als de organisatie het bewaart vanwege een gedocumenteerde systeembeperking, registreer dan de uitzondering, de eigenaar en de verwijderingsvoorwaarde. Beschrijf die uitzondering niet als de universeel beste configuratie.
Controleer de service voordat u sleutels genereert
Bepaal of de aanbieder sleutels beheert of door de klant aangeleverd materiaal accepteert. Amazon SES Easy DKIM documenten a 2048-bits standaard; dat productgedrag niet mag worden gegeneraliseerd naar alle mailplatforms. Sommige services bieden slechts een ondersteunde reeks opties. Een gegenereerde 4096-bits sleutel is nutteloos als de beoogde ondertekenaar deze niet kan laden of als het DNS inrichtingspad het openbare record ervan beschadigt.
RFC 8463 voegt Ed25519-SHA256 toe: ondertekenaars moeten het implementeren en verificateurs moeten het onder die specificatie implementeren. De sleutelgroottes zijn numeriek niet vergelijkbaar met RSA-groottes als gelijkwaardige beveiligingsmaatregelen. Ondersteuning in de standaard demonstreert geen ondersteuning in elke geïmplementeerde onderteken-, ontvanger- of beheerinterface. Behandel een algoritmemigratie als een compatibiliteitsverandering met expliciet bewijs, en niet als een cosmetische setting. RFC 8463 sectie 6 staat parallelle RSA en Ed25519 handtekeningen tijdens transitie; ze moeten afzonderlijke selectors gebruiken omdat elke selector één sleutelrecord identificeert. Controleer of de daadwerkelijke ondertekeningsservice deze aanpak ondersteunt voordat u deze plant.
Bouw een bruikbare validatiematrix
Leg voor elke verzendroute de software of provider, het algoritme, de eventuele sleutelgrootte, de selector, de publicatiemethode en een representatief ontvangstsysteem vast. Afzonderlijke drie tests: de ondertekenaar accepteert de configuratie, de openbare sleutel wordt intact opgelost en een ontvanger verifieert een bericht dat door die ondertekenaar is geproduceerd.
Een illustratieve migratie begint met een oudere 1024-bits RSA-factureringsondertekenaar. Het voorgestelde doel is 2048-bit RSA met SHA-256. Publiceer een nieuwe selector met behulp van het ondersteunde proces van het platform, verifieer de sleutel, verzend deze via de factureringsapplicatie en inspecteer het ontvangen resultaat. Een test uit de mailbox van een medewerker bewijst niet dat de factureringsapplicatie is overgestapt. Behoud de oude afhankelijkheid alleen voor de geplande transitie en legitieme vertraagde e-mail, tenzij de reactie op incidenten anders voorschrijft.
Fouten nauwkeurig interpreteren
Als een groter record niet kan worden gepubliceerd, onderzoek dan de DNS interface en TXT weergave voordat u de cryptografie verzwakt. Als de verificatie een niet-ondersteund algoritme meldt, bewaar die bevinding dan ten opzichte van de daadwerkelijke ontvanger en softwareversie. Als DKIM maar slaagt DMARC mislukt, inspecteer de identiteitsuitlijning in plaats van de sleutelgrootte opnieuw te wijzigen.
Documenteer wat er is getest en wat onbekend blijft. Een steekproef van succesvolle ontvangers is nuttig operationeel bewijs en geen garantie voor het hele internet. Plan een beoordeling wanneer de aanbieder, cryptografische richtlijnen of belangrijke ontvangerspopulatie veranderen. Het besluit is verdedigbaar als de vereisten, implementatielimieten en waargenomen resultaten allemaal zichtbaar zijn.
Gerelateerde lectuur
RSA en Ed25519 DKIM handtekeningen: implementatievragen en interoperabiliteit · Syntaxis van de openbare DKIM -sleutel: identificeer ingekorte of verkeerd opgemaakte DNS waarden.
Leg de beslissing vast vóór de uitrol
- Huidige route: applicatie, eigenaar, ondertekendomein, selector en uitgezonden algoritme.
- Voorgestelde keuze: ondersteunde RSA-SHA256 op 2048 bits of sterker waar gerechtvaardigd, of een ondersteunde Ed25519-overgang.
- Acceptatiebewijs: ondertekenaar laadt de sleutel; DNS dient het intact; een vertrouwd ontvangend systeem verifieert een bericht van deze applicatie.
- Stopvoorwaarde: niet-ondersteund algoritme, verkeerd opgemaakte sleutel of ontbrekende handtekening. Los dat defect op voordat u de werkende selector buiten gebruik stelt.
- Uitzondering: als u 1024-bit RSA behoudt, vermeld dan de beperking, de risico-eigenaar en de datum voor herbeoordeling.