Mailversand

Benachrichtigungen an deine Abonnenten verschicken wir standardmäßig über unsere eigene Maildomain. Das hat einen Grund: An dieser Domain hängen die Signatur und die Zustellberechtigung, mit denen deine Mails durch die Spamfilter der Empfänger kommen. Wir können sie deshalb nicht einfach durch deine ersetzen.

Was du steuern kannst, steht auf dieser Seite — von der Antwortadresse bis zum kompletten Versand über deinen eigenen Server.

Absendername

Im Posteingang deiner Abonnenten steht als Absender der Name deiner Statusseite mit dem Zusatz „Statuspage“, zum Beispiel Rechnungskit Statuspage — auf einer englischen Seite „Rechnungskit Status Page“. So ist sofort klar, dass die Mail von deiner Statusseite kommt und nicht aus Vertrieb oder Buchhaltung. Den Namen änderst du über den Namen der Statusseite.

Antworten: Reply-To

Benachrichtigungen versenden wir über unsere eigene Maildomain. Das muss so sein — an dieser Domain hängen die Signatur und die Zustellberechtigung, mit denen deine Mails überhaupt durch die Spamfilter kommen. Ein Postfach gibt es dort aber nicht.

Ohne weitere Einstellung heisst das: Wer auf eine Störungsmeldung antwortet, bekommt eine Unzustellbarkeitsmeldung — und du erfährst nie, dass jemand dich erreichen wollte.

Deshalb gibt es unter Einstellungen → Abonnenten → Antworten das Feld Reply-To. Trag dort die Adresse ein, unter der Ihr erreichbar sein wollt — typischerweise euer Support-Postfach oder die Adresse eures Ticketsystems. Antworten deiner Abonnenten landen dann direkt dort.

Wir empfehlen das ausdrücklich. Eine Störungsmeldung ist der Moment, in dem Kunden Fragen haben; eine Absenderadresse, die nicht antwortet, wirkt genau dann abweisend.

• Der Absender der Mail bleibt unverändert unsere Domain, der angezeigte Name ist weiterhin der deiner Statuspage (siehe Absendername). Für den Empfänger sieht die Mail also aus wie bisher.
• Es gilt jede Adresse, auch eine bei einem fremden Anbieter. Sie muss dir nicht gehören und wird nicht geprüft — achte also auf Tippfehler, sonst gehen Antworten an Fremde.
• Das Feld ist in allen Tarifen verfügbar.
• Leer lassen ist eine bewusste Entscheidung: Dann setzen wir keinen Reply-To, und Antworten prallen ab. In dem Fall steht in der Fussnote jeder Benachrichtigung der Satz „Antworten auf diese E-Mail werden nicht gelesen." — damit ein Abonnent das erfährt, bevor er während einer Störung schreibt, und nicht erst durch die Unzustellbarkeitsmeldung danach. Sobald du eine Adresse einträgst, verschwindet der Satz.

Über die API: reply_to_email bei PATCH /api/v1/statuspage, null löscht den Eintrag wieder.

Über den eigenen Mailserver senden (Business)

Standardmäßig verschicken wir Benachrichtigungen über unsere Maildomain. Im Business-Tarif kannst du stattdessen deinen eigenen SMTP-Server hinterlegen — dann tragen die Mails deine Absenderadresse, und deine Domain signiert sie.

Die Zugangsdaten hinterlegst du einmal pro Workspace unter Konto → Mailserver. Die Absenderadresse ist trotzdem pro Statuspage überschreibbar, falls du mehrere Marken betreibst.

Den Mailserver richten nur Admins ein, im Dashboard wie über die API. Über diesen Server laufen die Mails aller Statusseiten des Workspaces. Ein Mitglied, das nur einzelne Seiten sehen darf, soll die Mails der anderen nicht umleiten können.

Du brauchst dafür von deinem Mailanbieter: Hostname, Port, Verschlüsselung (meist STARTTLS auf 587), Benutzername, Passwort und eine Absenderadresse, von der dein Server senden darf.

Zwei Knöpfe zum Prüfen — und warum es zwei sind

Oben auf der Seite stehen Verbindung testen und Testmail senden. Sie beantworten unterschiedliche Fragen, und beide zu haben spart dir das Raten:

Über die API gibt es beides unter POST /api/v1/mail-settings/test; mit send_test_mail: true geht die Testmail an die Adresse des Token-Inhabers.

Der Gedanke dahinter: Eine Fehlkonfiguration scheitert fast immer schon beim ersten Schritt — falscher Port, Passwort abgelaufen, falsche Verschlüsselung. Das ohne Mailversand feststellen zu können heisst, du kannst so oft probieren, wie du willst, ohne dein Postfach zu füllen oder deine Versandstatistik zu verzerren. Kommt die Verbindung dagegen zustande und die Testmail trotzdem nicht an, liegt es an der Absenderadresse oder an der Zustellung — zwei ganz andere Ecken.

Verbindung testen arbeitet mit dem, was gerade im Formular steht — du musst also nicht erst speichern. Lässt du das Passwortfeld leer, nehmen wir das gespeicherte — aber nur für denselben Server: Änderst du Host, Port, Benutzer oder Verschlüsselung, gib das Passwort erneut ein. So kann niemand mit Bearbeitungsrechten die Einstellungen auf einen eigenen Server umbiegen und sich dein Passwort schicken lassen. Bei einem Fehlschlag zeigen wir die Antwort deines Servers im Wortlaut an, weil „Anmeldung fehlgeschlagen" und „Verbindung abgelehnt" in völlig verschiedene Richtungen zeigen.

Wir warten dabei höchstens zehn Sekunden auf deinen Server. Meldet er sich nicht, gilt das als Fehlschlag — ein Mailserver, der im Test so lange braucht, ist auch im Ernstfall keine gute Grundlage.

Wenn dein Server ausfällt, geht die Benachrichtigung trotzdem raus. Wir versuchen es mehrfach; nimmt dein Server sie endgültig nicht an, verschicken wir sie über unsere eigenen Server — dann mit unserer Absenderadresse statt deiner. Du bekommst eine E-Mail darüber, und der Fehler steht auf der Einstellungsseite. Eine zugestellte Störungsmeldung aus der falschen Domain ist besser als gar keine.

Der Schalter Über diesen Server senden lässt sich jederzeit ausschalten, ohne die Zugangsdaten zu verlieren.

Zwei Dinge, die wir aus Sicherheitsgründen ablehnen:

• Hostnamen, die in private Netze zeigen (etwa 127.0.0.1 oder Adressen aus dem internen Bereich). Das wird beim Speichern und vor jedem Versand geprüft.
• Das gespeicherte Passwort geben wir nie wieder heraus — weder im Formular noch über die API. Die API sagt nur, ob eines hinterlegt ist.

Im Dashboard schaltest du den eigenen Server mit dem Schalter Aktiv ab; die Daten bleiben gespeichert. Ganz löschen geht über die API. Über die API: GET, PATCH und DELETE auf /api/v1/mail-settings. Die Verbindung ist immer verschlüsselt (encryption: tls oder ssl). Lässt du password weg, bleibt das gespeicherte erhalten, solange Host, Port, Benutzername und Verschlüsselung gleich bleiben; sonst antwortet die API mit 422.