Öffentliche und private Schlüssel

Jede Organisation hat einen öffentlichen Schlüssel und bis zu 20 aktive private Schlüssel. Sie finden sie auf der Seite Sicherheit in den Abschnitten Öffentlicher Schlüssel und Private Schlüssel. Inhaber, Admins und Entwickler können sie sehen; erstellen, widerrufen und erneuern können Schlüssel nur Inhaber und Admins.

	Öffentlicher Schlüssel	Privater Schlüssel
Format	`pk_…`	`sk_…`
Geheim?	Nein – er ist im Quelltext Ihrer Seite sichtbar	Ja – wie ein Passwort
Einsatz in	Browsern, mobilen Apps, statischen Websites	Servern, Serverless-Funktionen, CI
Übergabe	im Body `user_id` oder im Header `X-Frontmail-Public-Key`	im Header `Authorization: Bearer sk_…` oder im Body `accessToken`
Origin-Prüfung	✓ muss zu den erlaubten Domains passen; ohne `Origin` ist Mobile Apps erlauben nötig	ein `Origin`-Header wird abgelehnt (`private_key_in_browser`), sofern nicht erlaubt
Turnstile	✓ wenn die Vorlage es verlangt	entfällt
Rate Limits	pro Organisation, pro IP, pro Schlüssel	pro Organisation, pro Schlüssel
Endpunkte	`send`, `send-form`, `uploads`, `messages/:id` (mit Status-Token)	alle, einschließlich `send-batch`, `history`, `templates`

Öffentlicher Schlüssel

Der öffentliche Schlüssel identifiziert lediglich Ihre Organisation. Jeder kann ihn von Ihrer Website kopieren – deshalb werden damit signierte Anfragen auf Herkunft, Bot-Signale und Häufigkeit geprüft, und deshalb können Vorlagen keine dynamischen Empfänger verwenden, sofern Sie das nicht ausdrücklich erlauben. Ein Client mit öffentlichem Schlüssel kann nur den Status seiner eigenen Nachrichten lesen, und zwar mit dem status_token, den send zurückgibt (gesendet im Header X-Frontmail-Status-Token).

Private Schlüssel

Private Schlüssel umgehen die auf Browser ausgerichteten Prüfungen und dürfen daher niemals in einen Browser gelangen. Typische Einsätze: Versand aus Ihrem Backend, das Node-SDK, Batch-Versand, Lesen des Verlaufs und npx frontmail types.

Erstellen Sie einen mit Neuer privater Schlüssel. Er wird einmal angezeigt – kopieren Sie ihn und bestätigen Sie mit Ich habe ihn sicher gespeichert. Frontmail speichert nur einen Hash und die letzten vier Zeichen.
Geben Sie jedem Schlüssel einen Namen (z. B. „Produktiv-Backend“, „CI“), damit Sie sehen, wo er verwendet wird – die Spalte Zuletzt verwendet zeigt, wann jeder Schlüssel zuletzt benutzt wurde.
Mit dem Schalter API mit privatem Schlüssel erlauben (Sicherheit → Schutz vor Missbrauch) können Sie den Zugriff mit privaten Schlüsseln für die Organisation komplett abschalten, wenn Sie nur aus Browsern senden; Anfragen mit privatem Schlüssel schlagen dann mit 403 forbidden fehl.
Anfragen mit privatem Schlüssel, die einen Origin-Header tragen – also von einer Webseite kommen –, schlagen mit 403 private_key_in_browser fehl. Das gilt auch für das EmailJS-Body-Feld accessToken und für die Lese-Endpunkte. Server senden keinen Origin, serverseitiger Code ist also nicht betroffen. Nur wenn Sie wirklich einen privaten Schlüssel im Browser brauchen (ein internes Admin-Tool, niemals eine öffentliche Seite), schalten Sie Private Schlüssel im Browser erlauben ein (Sicherheit → Schutz vor Missbrauch, standardmäßig aus).

Erneuerung

Private Schlüssel: Erstellen Sie einen neuen Schlüssel, spielen Sie ihn auf Ihre Server aus, prüfen Sie, dass sich Zuletzt verwendet beim alten Schlüssel nicht mehr ändert, und klicken Sie dann beim alten Schlüssel auf Widerrufen. Der Widerruf wirkt sofort; Anfragen mit einem widerrufenen Schlüssel schlagen mit invalid_private_key fehl.

Öffentlicher Schlüssel: Klicken Sie im Abschnitt „Öffentlicher Schlüssel“ auf Schlüssel erneuern. Sie erhalten sofort einen neuen Schlüssel; der alte funktioniert noch eine Übergangszeit von 24 Stunden, damit Sie Ihre Website neu ausrollen können, danach schlägt er mit invalid_public_key fehl. Erneuern Sie den öffentlichen Schlüssel, wenn Sie trotz erlaubter Domains und Turnstile Missbrauch feststellen oder wenn Sie eine App in eine neue Organisation umziehen.

Erstellen, Widerrufen und Erneuern von Schlüsseln wird im Audit-Log festgehalten.