Authentifizierung

DKIM-Signing — automatische Rotation, kein DNS-Streit.

Jede ausgehende Mail wird mit einem domain-spezifischen Schlüssel signiert. MailGuard generiert die Schlüssel, rotiert sie jährlich mit 30-Tage-DNS-Vorlauf und liefert dem Operator den fertigen DNS-TXT-Record. Operator klickt „Aktivieren", der Rest läuft automatisch.

Warum DKIM überhaupt

DKIM (DomainKeys Identified Mail, RFC 6376) ist der Industrie-Standard zur Authentifizierung ausgehender Mails. Zusammen mit SPF und DMARC bildet es die drei Säulen der modernen Mail-Authentifizierung. Ohne DKIM:

  • Microsoft 365, Gmail und alle größeren Empfänger-Mailserver markieren Ihre Mails als verdächtig oder direkt als Spam
  • DMARC-Reject-Policies anderer Domains gegen Sie sind nicht möglich (DKIM ist Voraussetzung)
  • Spoofing-Angriffe gegen Ihre Domain sind technisch nicht abwehrbar
  • Marketing-Versanddienste (Newsletter, Transaktions-Mails) leiden unter schlechter Zustellquote

Wie der Workflow läuft

  1. Domain hinzufügen — Operator legt im UI eine neue Domain an, MailGuard generiert sofort einen RSA-2048 oder ed25519 Schlüssel (wählbar).
  2. DNS-Record kopieren — UI zeigt den fertigen TXT-Record, den der Operator beim DNS-Provider seiner Domain einträgt: default._domainkey.example.com mit dem Public-Key.
  3. Aktivieren — Operator klickt „DKIM aktivieren". MailGuard prüft per DNS-Lookup ob der Record live ist, und schaltet die Signierung scharf wenn ja.
  4. Ausgehend signieren — Jede Mail die durch MailGuard geht wird mit dem privaten Schlüssel signiert. Empfänger-Mailserver verifizieren gegen den DNS-Public-Key.

Automatische jährliche Rotation

Schlüssel-Material altert. NIST und IETF empfehlen jährliche DKIM-Rotation — ein Schlüssel der 5 Jahre im DNS hängt und auf Festplatten von ehemaligen Mitarbeitern liegt, ist ein Risiko. MailGuard automatisiert die Rotation:

  1. Tag 335 (30 Tage vor Ablauf): MailGuard generiert einen neuen Schlüssel, zeigt dem Operator im UI den DNS-Record für den neuen Selector. Der alte Schlüssel ist weiter aktiv und signiert ausgehende Mails.
  2. Tag 335 – 365: Operator hat 30 Tage um den neuen DNS-Record zu publizieren. Im UI wird der Status angezeigt („Neuer Schlüssel im DNS — bereit zum Aktivieren" oder „Wartet auf DNS").
  3. Tag 365: Operator klickt „Neuen Schlüssel aktivieren". Ab jetzt wird mit dem neuen Schlüssel signiert. Der alte Schlüssel-DNS-Record kann nach 30 Tagen entfernt werden (in-flight Mails sind dann sicher zugestellt).

Wenn der Operator nichts tut, läuft die alte Lizenz weiter — keine harte Cliff-Edge. UI-Reminder erinnern an offene DKIM-Rotationen.

RSA 2048 oder ed25519?

Pro Domain wählbar. Empfehlung:

  • RSA 2048 — universell unterstützt, jeder Empfänger-Mailserver versteht es. Default für neue Domains.
  • ed25519 — kürzere Signaturen, schnellere Validierung, modern. Allerdings: einige ältere Mail-Empfänger (Exchange Server <2019) verifizieren ed25519 nicht. RSA 2048 ist die sichere Wahl wenn Empfänger-Vielfalt unklar ist.

Multi-Domain im Cluster

Bei einem Cluster mit mehreren Mandanten hat jede Domain eigene Schlüssel. Schlüssel-Synchronisation zwischen den Cluster-Knoten passiert automatisch — Mail die auf Node-2 ausgeht wird mit demselben Schlüssel signiert wie wenn sie auf Node-1 ausgeht. Operator pflegt Schlüssel an einer zentralen Stelle, alle Knoten ziehen nach.

DKIM ohne Operator-Wartungs-Termine.

Schlüsselgenerierung, Rotation, DNS-Workflow — automatisiert. Pro Domain eigene Schlüsselpaare im Multi-Domain-Setup.

Preise ansehen