Wählen Sie ein DKIM Schlüsselkonfiguration, die das Protokoll erfüllt und auf allen Systemen funktioniert, die Ihre E-Mails senden und empfangen. Eine größere Zahl in einem Control Panel ist keine vollständige Sicherheitsentscheidung. Notieren Sie den Algorithmus, den Schlüsseltyp und den Empfängernachweis und halten Sie die kryptografische Stärke getrennt von der Zustellung und Ausrichtung.
Verwenden Sie die aktualisierten RSA-Anforderungen
RFC 8301 aktualisiert die ältere DKIM Spezifikation. Für RSA müssen Signaturschlüssel mindestens 1024 Bit lang sein, und Unterzeichner sollten mindestens 2048 Bit verwenden. Prüfer müssen die Validierung mit RSA-Schlüsseln von 1024 bis 4096 Bit unterstützen, möglicherweise größere Schlüssel unterstützen und dürfen RSA-Schlüssel unter 1024 Bit nicht als gültig akzeptieren. Ein Prüfer kann weiterhin eine lokale Richtlinie basierend auf der Schlüssellänge anwenden.
Derselbe RFC verbietet rsa-sha1 zum Signieren und Verifizieren. Verwenden Sie nicht das SHA-1-Beispiel eines veralteten Tutorials als aktuelle Bereitstellungsempfehlung. Überprüfen Sie die tatsächliche a= Wert in einem empfangenen DKIM-Signature und der Schlüsseltyp, der durch ihn erreicht wird Wähler, anstatt der Erinnerung eines Administrators an das ursprüngliche Setup zu vertrauen.
Das Minimum und die Empfehlung beantworten unterschiedliche Fragen. Ein 1024-Bit-RSA-Schlüssel kann den angegebenen Mindestwert erreichen, ohne die stärkere empfohlene Auswahl zu erfüllen. Wenn die Organisation es aufgrund einer dokumentierten Systemeinschränkung behält, notieren Sie die Ausnahme, den Eigentümer und die Entfernungsbedingung. Beschreiben Sie diese Ausnahme nicht als die universell beste Konfiguration.
Überprüfen Sie den Dienst, bevor Sie Schlüssel generieren
Bestimmen Sie, ob der Anbieter Schlüssel verwaltet oder vom Kunden bereitgestelltes Material akzeptiert. Amazon SES Easy DKIM dokumentiert a 2048-Bit Standard; dass das Produktverhalten nicht auf alle E-Mail-Plattformen verallgemeinert werden sollte. Einige Dienste stellen nur einen unterstützten Satz von Optionen bereit. Ein generierter 4096-Bit-Schlüssel ist nutzlos, wenn der vorgesehene Unterzeichner ihn nicht laden kann oder der DNS Bereitstellungspfad seinen öffentlichen Eintrag beschädigt.
RFC 8463 fügt Ed25519-SHA256 hinzu: Unterzeichner sollten es implementieren und Prüfer müssen es gemäß dieser Spezifikation implementieren. Seine Schlüsselgrößen sind numerisch nicht mit RSA-Größen als gleichwertige Sicherheitsmaßnahmen vergleichbar. Die Unterstützung im Standard zeigt nicht die Unterstützung in allen bereitgestellten Unterzeichner-, Empfänger- oder Verwaltungsschnittstellen an. Behandeln Sie eine Algorithmusmigration als Kompatibilitätsänderung mit expliziten Beweisen und nicht als kosmetische Einstellung. RFC 8463 Abschnitt 6 erlaubt paralleles RSA und Ed25519 Unterschriften während des Übergangs; Sie müssen separate Selektoren verwenden, da jeder Selektor einen einzelnen Schlüsseldatensatz identifiziert. Stellen Sie sicher, dass der tatsächliche Signaturdienst diesen Ansatz unterstützt, bevor Sie ihn planen.
Erstellen Sie eine nützliche Validierungsmatrix
Notieren Sie für jede Senderoute die Software oder den Anbieter, den Algorithmus, gegebenenfalls die Schlüsselgröße, den Selektor, die Veröffentlichungsmethode und ein repräsentatives Empfangssystem. Trennen Sie drei Tests: Der Unterzeichner akzeptiert die Konfiguration, der öffentliche Schlüssel wird intakt aufgelöst und ein Empfänger überprüft eine von diesem Unterzeichner erstellte Nachricht.
Eine beispielhafte Migration beginnt mit einem alten 1024-Bit-RSA-Abrechnungssignierer. Das vorgeschlagene Ziel ist 2048-Bit-RSA mit SHA-256. Veröffentlichen Sie mithilfe des von der Plattform unterstützten Prozesses einen neuen Selektor, überprüfen Sie den Schlüssel, senden Sie ihn über die Abrechnungsanwendung und überprüfen Sie das Empfangsergebnis. Ein Test aus dem Postfach eines Mitarbeiters beweist nicht, dass die Abrechnungsanwendung gewechselt hat. Behalten Sie die alte Abhängigkeit nur für den geplanten Übergang und legitime verzögerte E-Mails bei, sofern die Reaktion auf Vorfälle nichts anderes vorschreibt.
Misserfolge genau interpretieren
Wenn die Veröffentlichung eines größeren Datensatzes fehlschlägt, untersuchen Sie die DNS Schnittstelle und TXT Darstellung, bevor Sie die Kryptografie schwächen. Wenn bei der Überprüfung ein nicht unterstützter Algorithmus gemeldet wird, vergleichen Sie diesen Befund mit dem tatsächlichen Empfänger und der Softwareversion. Wenn DKIM aber besteht DMARC Wenn dies fehlschlägt, überprüfen Sie die Identitätsausrichtung, anstatt die Schlüsselgröße erneut zu ändern.
Dokumentieren Sie, was getestet wurde und was unbekannt bleibt. Eine Stichprobe erfolgreicher Empfänger ist ein nützlicher betrieblicher Beweis und keine Garantie für das gesamte Internet. Planen Sie eine Überprüfung, wenn sich der Anbieter, die kryptografische Anleitung oder wichtige Empfängergruppen ändern. Die Entscheidung ist vertretbar, wenn ihre Anforderungen, Umsetzungsgrenzen und beobachteten Ergebnisse alle sichtbar sind.
Verwandte Lektüre
RSA- und Ed25519 DKIM Signaturen: Bereitstellungsfragen und Interoperabilität · DKIM Public-Key-Syntax: Identifizieren Sie abgeschnittene oder fehlerhafte DNS Werte.
Notieren Sie die Entscheidung vor dem Rollout
- Aktuelle Route: Anwendung, Besitzer, signierende Domäne, Selektor und ausgegebener Algorithmus.
- Vorgeschlagene Wahl: unterstütztes RSA-SHA256 mit 2048 Bit oder höher, sofern gerechtfertigt, oder ein unterstützter Ed25519-Übergang.
- Akzeptanznachweis: Unterzeichner lädt den Schlüssel; DNS stellt es intakt bereit; Ein vertrauenswürdiges Empfangssystem überprüft eine Nachricht von dieser Anwendung.
- Stoppbedingung: nicht unterstützter Algorithmus, fehlerhafter Schlüssel oder fehlende Signatur. Beheben Sie diesen Fehler, bevor Sie den funktionsfähigen Selektor aus dem Verkehr ziehen.
- Ausnahme: Wenn Sie 1024-Bit-RSA beibehalten, geben Sie die Einschränkung, den Risikoinhaber und das Datum für die Neubewertung an.