Jedes Team, das E-Mail-Features baut, steht irgendwann vor derselben Gabel: die Entwicklung auf einen echten SMTP-Anbieter richten oder die Mail-Schicht faken und hoffen, dass sich die Produktion brav verhält. Option eins leckt Zugangsdaten, verbrennt Anbieter-Kontingente und mailt gelegentlich einen echten Kunden vom Laptop aus. Option zwei testet nichts weiter als bis zu dem Punkt, an dem Ihr Code die Nachricht einem Server übergibt. Es gibt einen besseren Mittelweg — sogar mehrere. Hier ist der Vergleich der Standard-Optionen für lokale Tests, und wann jede gewinnt.
Warum echtes SMTP in der Entwicklung eine schlechte Idee ist
Die Versuchung ist verständlich: echter Anbieter, echtes Verhalten, null Setup. Die Kosten erscheinen später:
- Zugangsdaten-Leck. API-Keys, die in .env-Dateien auf Entwicklermaschinen leben, landen in Logs, Screenshots und schließlich in einem Chat-Thread.
- Versehentliche echte Sends. Ein Testlauf gegen eine kopierte Produktionsdatenbank mailt echte Nutzer von Ihrem Laptop. Das passiert ständig, und es ist immer denkwürdig.
- Flaky Testsuiten. Wenn Unit-Tests von der Verfügbarkeit, den Rate-Limits und den Sandbox-Eigenheiten eines Drittanbieters abhängen, wird CI zur Wettervorhersage.
- Kosten und Kontingent. Selbst großzügige Gratis-Stufen leeren sich schnell, wenn eine Testsuite pro Lauf Hunderte Nachrichten sendet.
Die Lösung: Halten Sie echtes Senden komplett aus der inneren Schleife — die Argumentation in Entwickler- und QA-Tests mit temporärer E-Mail gilt auch für die lokale Entwicklung.
Option 1: Catch-All-lokale SMTP-Server (MailHog, Mailpit)
Ein Catch-All-Server lauscht auf einem lokalen Port, nimmt alles ohne Auth oder TLS an, speichert Nachrichten im Speicher und zeigt sie in einem Web-UI. Ihre App spricht ihn wie jeden SMTP-Host an:
SMTP_HOST=127.0.0.1 SMTP_PORT=1025
docker run -p 1025:1025 -p 8025:8025 axllent/mailpit
Mailpit ist der aktuell gepflegte Standard: HTML-Vorschau, MIME-Parsing, eine REST-API für Assertions und ein Chaos-Modus, der Fehler und Verzögerungen simuliert. MailHog, der Vorgänger, wird seit 2020 nicht mehr gepflegt, funktioniert aber noch und taucht in unzähligen Tutorials auf; greifen Sie für alles Neue zu Mailpit.
Gewinnt bei: Unit- und Integrationstests, Frontend-Arbeit, bei der Designer die E-Mails sehen müssen, und Laptops in Zügen ganz ohne Netz.
Option 2: Container-SMTP-Buckets im Dev-Stack
Die nächste Stufe bettet den Mail-Bucket als benannten Service mit persistentem Volume in Ihren docker-compose-Entwicklungsstack ein. Zwei Dinge verbessern sich:
- Geteilter Zustand. Die Mail jedes Entwicklers landet an einem vorhersagbaren Ort, und ein Neustart Ihrer App wischt den Posteingang nicht aus.
- Test-Assertions per API. Mailpit legt eine REST-API offen, sodass Integrationstests die letzte Nachricht an eine Adresse abholen und auf Betreff, Header und Body prüfen können, ohne Logs zu parsen.
Der Trade-off bleibt: Mail verlässt die Maschine nie. Authentifizierung, DNS und echte Zustellbarkeit bleiben ungetestet — eine grüne Suite kann trotzdem einen kaputten Sender-Record ausliefern. Bevor Sie Staging an echte Domains verdrahten, bestätigen Sie auch die Empfängerseite — der MX-Checker zeigt die Mail-Exchanger jeder Domain, die Sie gleich anschreiben wollen.
Option 3: Wegwerf-Postfächer für Staging-Realismus
Lokale Buckets können die Frage nicht beantworten, ob die Nachricht tatsächlich über das echte Internet ankam. Diese Frage braucht echte Zustellung, und dort verdienen Wegwerf-Postfächer ihren Platz. Richten Sie Staging auf Ihre echte Sende-Infrastruktur und nutzen Sie temporäre Adressen als Empfänger: Nachrichten durchlaufen echtes DNS, TLS und Anbieter-Filterung, und Sie können Ankunftszeit, Inhalt und Spam-Ordnerung prüfen — nicht nur Ihr eigenes Sende-Log.
Dieser Ansatz glänzt für:
- Ende-zu-Ende-Anmelde-Flows. Verifizierungslinks und Einmal-Codes, von der Postfach-Seite aus geprüft, mit dem Automatisierungsmuster in temporäre E-Mail-API-Automatisierung.
- Webhook-Pipelines. Bounce- und Inbound-Message-Webhooks brauchen echte Mail-Events zum Testen; unsere Anleitung zum Empfangen von E-Mail-Webhooks aus einem temporären Postfach geht die Verdrahtung durch.
- Generalproben vor der Produktion. Das vollständige Staging-Setup behandeln wir in Staging-Umgebungs-Tests.
Welche Option wann
- Lokale Unit-Tests und Vorschau: Mailpit auf localhost. Schnell, offline, null Nebenwirkungen.
- Team-Dev-Umgebung: Mailpit als Compose-Service mit Volume. Geteilt, einsehbar, per API prüfbar.
- Staging und Release-Verifikation: echtes Senden plus Wegwerf-Empfänger-Postfächer. Die einzige Option, die den echten Weg der Mail Ihrer Nutzer ausübt.
- Produktions-Monitoring: gar kein lokales Thema — dort übernehmen Placement-Checks und Seed-Tests.
Behandeln Sie sie als Schichten, nicht als Konkurrenten: Die meisten gereiften Setups fahren alle drei, jede auf der Höhe, die sie gut kann.
FAQ
Ist MailHog 2026 noch eine gute Wahl? Es funktioniert noch, wird aber seit Jahren nicht gepflegt und hinkt bei modernem MIME-Handling hinterher. Mailpit ist der aktiv entwickelte Nachfolger mit kompatiblem Feature-Umfang — wählen Sie ihn für alles Neue.
Kann ich DKIM und SPF mit einem lokalen SMTP-Server testen? Nein. Authentifizierung umfasst DNS- und Public-Key-Lookups, die ein Localhost-Server nie ausübt. Nutzen Sie echte Zustellung an Wegwerf-Adressen und verifizieren Sie dann die Signaturen auf der empfangenen Nachricht.
Wie hindere ich meine Dev-Umgebung daran, echte Menschen zu mailen? Richten Sie sie auf lokales SMTP, oder nutzen Sie einen Staging-Flag, der alle Empfänger auf Wegwerf-Postfächer umschreibt. Behalten Sie Produktions-Zugangsdaten nie auf einem Dev-erreichbaren Pfad.
Was ist der günstigste Weg, in CI das Eintreffen einer E-Mail zu prüfen? Legen Sie per API ein temporäres Postfach an, lösen Sie den Send aus, pollen Sie auf die Nachricht und lassen Sie den Build beim Timeout fehlschlagen. Das sind wenige Skriptzeilen und fängt die Fehler, die lokale Buckets nicht fangen.