Transaktionale Mails über ein SMTP-Relay

Status: angenommen. Datum: 01.11.2026.

Anlass

VergabeFit verschickte bisher nur den Claim-Code, und dieser Weg brach mit gesetztem Anbieter-Schlüssel ab. Bestätigung der Anmeldung, Passwort-Reset und Mails zu Benachrichtigungen fehlten. Ohne bestätigte Adresse ließen sich Einladungen nicht sicher binden und Freigaben nicht sicher zustellen. Gewünscht waren Datensouveränität (kein weiterer US-Dienst für Nutzerdaten) und eine schnelle Einrichtung.

Entscheidung

Logik, Vorlagen und Tests liegen im eigenen System. Nur die Zustellung läuft über ein EU-Relay statt über einen eigenen Mailserver.
Produktionsziel ist Scaleway Transactional Email (Region Paris). Lettermint ist der dokumentierte Ersatz. Der Anbieter ist reine Konfiguration.
Es gibt einen Versandweg: SMTP mit denselben Variablen (SMTP_*, EMAIL_FROM, APP_PUBLIC_URL) für Frontend, Agent-Service und Supabase Auth. Resend entfällt.
Auth-Mails (Bestätigung, Passwort vergessen) versendet Supabase Auth mit versionierten Vorlagen aus services/frontend/public/email-templates/. Die Links führen auf /auth/confirm, das erst nach einem Klick auf einen Button bestätigt, damit Link-Vorabprüfungen den Einmal-Link nicht verbrauchen.
Die Tabelle procur_regx.notifications ist die Warteschlange für alle weiteren Mails. Ein Worker im Agent-Service holt offene Zeilen über Leases, bündelt sie pro Empfänger und schließt sie ab. Zeilen, die älter als 24 Stunden sind, und Altbestand werden nicht nachträglich verschickt.
Der Claim-Code wird synchron aus dem Frontend gesendet. Schlägt der Versand fehl, wird der Claim zurückgezogen und der Nutzer sieht es.
Nur Zustellfehler pro Nachricht (Empfänger oder Inhalt abgelehnt) markieren eine Benachrichtigung als failed. Fehler beim Verbinden, bei der Anmeldung am Relay oder ein abgelehnter Absender gelten als vorübergehend und werden wiederholt.
Lokal fängt Mailpit (Compose-Profil mail) alle Mails ab.

Folgen

Eine Domain mit SPF, DKIM und DMARC, ein Relay-Konto und ein Auftragsverarbeitungsvertrag sind Voraussetzung für den Produktivbetrieb. Die Datenschutzerklärung nennt den Anbieter.
Neue Konten müssen ihre Adresse bestätigen. Eine Freigabe durch Admins setzt eine bestätigte Adresse voraus, und Einladungen werden erst nach Bestätigung gebunden.
Mail-Benachrichtigungen sind mindestens einmal zugestellt, nie garantiert genau einmal. Ein Nutzer kann Alert-Mails im Profil abschalten. Mails zu Konto und Claims bleiben davon unberührt.
Rollout in fester Reihenfolge: erst das Frontend mit /auth/confirm und den Vorlagen, dann die Autobestätigung in Supabase Auth ausschalten. Ein Rollback läuft umgekehrt.
Fällt der Relay aus, schlagen Registrierung und Passwort-Reset sichtbar fehl, weil Supabase Auth die Mail synchron im Request versendet. Die Anmeldung bestehender Konten bleibt möglich, Benachrichtigungen laufen nach der Lease erneut.

Alternativen

Eigener Mailserver: volle Kontrolle, aber Port 25 und IP-Ruf einer frischen Cloud-VM machen Login- und Claim-Codes unzuverlässig.
Weiterer US-Dienst mit eigener API: schnell, widerspricht aber dem Souveränitätsziel und bindet Code an einen Anbieter.
Klartext-Code in einer Tabelle für einen Hintergrundjob: verworfen, weil das Einmal-Passwort dann gespeichert würde. Der Claim-Code bleibt deshalb synchron.
Eine zweite Warteschlange für Mails: unnötig, weil Benachrichtigungen bereits existieren.