Beim Testen einer Webanwendung, eines ERP-Systems oder einer Shop-Testinstanz besteht ein Risiko: Ein Testlauf verschickt echte E-Mails an echte Kundenadressen. Mailpit verhindert das, indem es sich als SMTP-Server ausgibt, alle Nachrichten annimmt und keine weiterleitet.

Mailpit ersetzt das nicht mehr gepflegte MailHog, läuft als einzelne Datei mit wenigen Megabyte Arbeitsspeicher und bietet neben der Weboberfläche eine API für automatisierte Tests.

Was Mailpit leistet und wo die Grenzen liegen

Mailpit speichert per SMTP empfangene E-Mails in einer eingebetteten Datenbank und zeigt HTML-Ansicht, Quelltext, Textfassung, Kopfzeilen, Rohfassung und Anhänge in der Weboberfläche. Dazu kommen Suche, HTML-Verträglichkeitsprüfung, Linkprüfung und optional ein POP3-Server.

Das Projekt (github.com/axllent/mailpit, MIT-Lizenz) wird aktiv gepflegt; aktuell ist v1.32.0 vom 22. Oktober 2026.

Grenzen: Mailpit ist kein Mailserver für den Produktivbetrieb, stellt nicht an externe Empfänger zu und hat keine Postfachverwaltung. Für echten Mailbetrieb eignen sich Postfix und Dovecot oder eine fertige Zusammenstellung.

Einzelne Nachrichten lassen sich auf Knopfdruck über einen echten SMTP-Server weiterleiten, ohne die Sperre für alle aufzuheben.

Voraussetzungen und Ressourcen

Ein Linux-Host mit Docker Engine und dem Compose-Plugin. Die Beispiele in dieser Anleitung wurden mit Docker 29.1.3 und Docker Compose 2.40.3 auf Ubuntu geprüft.
Etwa 100 MB Arbeitsspeicher einplanen; der Prozess selbst belegte im Test rund 9 MB.
Speicherplatz nach Bedarf. Die Datenbank wächst mit der Anzahl gespeicherter Nachrichten, standardmäßig sind maximal 500 Nachrichten vorgesehen, im Beispiel unten werden 5000 gesetzt.
Zwei freie Ports auf dem Host: 8025 für die Weboberfläche und 1025 für SMTP. Beide lassen sich verschieben.
Architekturen: unter anderem amd64 und arm64.

Installation mit Docker Compose

Legen Sie ein Verzeichnis für den Stack an, im Beispiel unter /opt:

sudo mkdir -p /opt/mailpit
cd /opt/mailpit

Legen Sie compose.yaml an. Sie folgt dem offiziellen Beispiel, ergänzt um eine feste Version, ein benanntes Volume und Ports nur auf 127.0.0.1:

services:
  mailpit:
    image: axllent/mailpit:v1.32.0
    container_name: mailpit
    restart: unless-stopped
    ports:
      - "127.0.0.1:8025:8025"
      - "127.0.0.1:1025:1025"
    volumes:
      - mailpit_data:/data
    environment:
      MP_DATABASE: /data/mailpit.db
      MP_MAX_MESSAGES: "5000"
      MP_SMTP_AUTH_ACCEPT_ANY: "1"
      MP_SMTP_AUTH_ALLOW_INSECURE: "1"
      TZ: Europe/Berlin

volumes:
  mailpit_data:

Die einzelnen Werte im Überblick:

image mit fester Version statt latest: nachvollziehbar, kein unbemerkter Versionssprung.
MP_DATABASE legt die Datenbankdatei in das eingebundene Volume. Ohne diesen Wert hält Mailpit die Nachrichten nur im Arbeitsspeicher und verliert sie beim Neustart.
MP_MAX_MESSAGES begrenzt die Anzahl gespeicherter Nachrichten. Ältere werden automatisch entfernt, sobald die Grenze erreicht ist. Der Standardwert der Anwendung liegt bei 500.
MP_SMTP_AUTH_ACCEPT_ANY nimmt beliebige Anmeldedaten am SMTP-Port an, auch gar keine. Das ist für Testumgebungen praktisch, weil die Anwendung ihre bestehende Konfiguration behalten kann.
MP_SMTP_AUTH_ALLOW_INSECURE erlaubt unverschlüsselte Anmeldeverfahren. In Verbindung mit dem vorigen Wert bedeutet das: Der SMTP-Port darf nie aus dem Internet erreichbar sein.
TZ sorgt dafür, dass die Zeitstempel in der Oberfläche der lokalen Zeit entsprechen.

Starten Sie den Stack:

sudo docker compose up -d

Verifizieren: sudo docker compose ps zeigt den Container nach etwa 30 Sekunden als healthy; die Prüfungen folgen im nächsten Abschnitt.

Funktionsprüfung

Die folgenden Prüfungen liefen im Test; die Ausgaben stammen aus diesem Lauf.

Zustand des Containers:

sudo docker compose ps

Ausgabe im Test (dort noch mit Veröffentlichung auf allen Schnittstellen):

NAME           IMAGE                     SERVICE   STATUS                   PORTS
mailpit-test   axllent/mailpit:v1.31.1   mailpit   Up 29 seconds (healthy)  0.0.0.0:1025->1025/tcp, 0.0.0.0:8025->8025/tcp, 1110/tcp

Port 1110 ist der POP3-Dienst; er wird erst mit einer Passwortdatei aktiv.

API abfragen:

curl -s http://127.0.0.1:8025/api/v1/info

Antwort aus dem Testlauf, gekürzt:

{"Version":"v1.31.1","LatestVersion":"v1.31.1","Database":"/data/mailpit.db","DatabaseSize":94208,"Messages":0,"Unread":0}

Liefern Sie eine Testmail mit Text- und HTML-Teil ein:

python3 - <<'EOF'
import smtplib
from email.message import EmailMessage

m = EmailMessage()
m["From"] = "app@example.test"
m["To"] = "admin@example.test"
m["Subject"] = "Testmail aus der Anwendung"
m.set_content("Klartext-Variante")
m.add_alternative("<h1>Rechnung</h1><p>HTML-Variante</p>", subtype="html")

s = smtplib.SMTP("127.0.0.1", 1025)
s.send_message(m)
s.quit()
print("gesendet")
EOF

Gespeicherte Nachrichten abrufen:

curl -s http://127.0.0.1:8025/api/v1/messages

Verifizieren: Die Antwort enthält die Testmail (Absender app@example.test, Empfänger admin@example.test), und SMTPAccepted in /api/v1/info steigt von 0 auf 1. So war es im Test.

Die Weboberfläche zeigt dieselbe Nachricht unter http://127.0.0.1:8025 (per SSH-Tunnel, siehe unten).

Absicherung und Netzwerkfreigabe

Mailpit ist standardmäßig offen: Die Weboberfläche hat keine Anmeldung, SMTP nimmt Nachrichten ohne Authentifizierung an. Im Internet wird daraus ein Datenleck, weil jede abgefangene Nachricht einsehbar ist.

Die Compose-Datei oben bindet beide Ports bereits an die lokale Adresse:

    ports:
      - "127.0.0.1:8025:8025"
      - "127.0.0.1:1025:1025"

Damit ist Mailpit nur vom Server selbst erreichbar. Die Oberfläche öffnen Sie über einen SSH-Tunnel:

ssh -L 8025:127.0.0.1:8025 benutzer@serveradresse

Läuft die sendende Anwendung in Docker, legen Sie sie ins selbe Compose-Netzwerk; dann genügt der Dienstname als SMTP-Host, und Port 1025 muss nicht veröffentlicht werden:

    # ports-Eintrag fuer 1025 entfaellt, stattdessen gemeinsames Netzwerk
    networks:
      - intern

networks:
  intern:

Zweiter Weg: Reverse Proxy mit TLS und der eingebauten Anmeldung per Passwortdatei. Das Mailpit-Image enthält kein openssl; erzeugen Sie den Hash deshalb auf dem Host und schreiben Sie die Datei ins Volume:

HASH=$(openssl passwd -apr1)   # fragt das Passwort ab
printf 'admin:%s\n' "$HASH" | sudo docker exec -i mailpit sh -c 'cat > /data/authfile'

Ergänzen Sie in der compose.yaml unter environment und starten Sie mit sudo docker compose up -d neu:

      MP_UI_AUTH_FILE: /data/authfile

Reverse Proxy mit Caddy:

mail-test.example.de {
    reverse_proxy 127.0.0.1:8025
}

Caddy holt das Zertifikat automatisch. Der SMTP-Port bleibt auch hier intern.

Verifizieren: curl -I https://mail-test.example.de liefert 401; mit -u admin und Passwort 200. Von einem anderen Rechner ist Port 1025 nicht erreichbar (nc -zv serveradresse 1025 schlägt fehl).

Ergänzend die Firewall (ufw unter Ubuntu):

sudo ufw status
sudo ufw deny 1025/tcp

Veröffentlichte Docker-Ports umgehen oft die Host-Firewall, weil Docker eigene Paketfilterregeln anlegt. Die Bindung an 127.0.0.1 ist deshalb die zuverlässigere Absicherung.

Persistente Daten und Rechte

Alle Daten liegen im Volume unter /data:

sudo docker run --rm -v mailpit_mailpit_data:/data alpine ls -la /data

Ausgabe im Test:

-rw-r--r-- 1 root root   4096 mailpit.db
-rw-r--r-- 1 root root  32768 mailpit.db-shm
-rw-r--r-- 1 root root 490312 mailpit.db-wal

Die Dateien -shm und -wal gehören zur Datenbank und müssen mitgesichert werden.

Ein Hostverzeichnis statt Volume ist möglich, etwa für einen bestehenden Sicherungsauftrag. Der Container läuft als root, besondere Rechte sind nicht nötig:

sudo mkdir -p /opt/mailpit/data
# in compose.yaml: - ./data:/data statt mailpit_data:/data

Auf NFS ist zusätzlich --disable-wal (bzw. die entsprechende Umgebungsvariable) nötig.

Backup und Wiederherstellung

Die folgenden Schritte liefen im Test erfolgreich. Sicherung des Volumes:

sudo docker run --rm \
  -v mailpit_mailpit_data:/data \
  -v /var/backups:/backup \
  alpine tar czf /backup/mailpit-$(date +%F).tgz -C /data .

Im Test entstand ein Archiv von rund 8 KB für eine Nachricht.

Wiederherstellung in ein neues Volume:

sudo docker volume create mailpit_restore
sudo docker run --rm \
  -v mailpit_restore:/data \
  -v /var/backups:/backup \
  alpine tar xzf /backup/mailpit-2026-09-13.tgz -C /data

Instanz auf dem wiederhergestellten Volume starten und prüfen:

sudo docker run -d --name mailpit-restore \
  -p 127.0.0.1:8125:8025 \
  -v mailpit_restore:/data \
  -e MP_DATABASE=/data/mailpit.db \
  axllent/mailpit:v1.32.0

curl -s http://127.0.0.1:8125/api/v1/messages

Verifizieren: Die Abfrage liefert die gesicherte Testmail (im Test so). Entfernen Sie danach die Prüfinstanz mit sudo docker rm -f mailpit-restore.

Für eine lesbare Langzeitablage schreibt der Unterbefehl dump alle Nachrichten als einzelne Dateien in ein Verzeichnis.

Updates und Rollback

Das Update erfolgt über die Versionsangabe in der compose.yaml:

cd /opt/mailpit
sudo docker compose down
sudo cp compose.yaml compose.yaml.bak
# image-Zeile auf die neue Version aendern
sudo docker compose pull
sudo docker compose up -d
sudo docker compose logs -f --tail 50

Ein Rollback ist möglich, solange keine neue Hauptversion das Datenbankschema migriert hat. Legen Sie vor Versionssprüngen die Sicherung an und lesen Sie die Versionshinweise.

Verifizieren: curl -s http://127.0.0.1:8025/api/v1/info zeigt unter Version die neue Version.

Update auf v1.32.0: Diese Version enthält Sicherheitskorrekturen, das Projekt empfiehlt das Update ausdrücklich. Ein präpariertes Bild im Anhang konnte den Vorschaubild-Generator von Weboberfläche und API in eine Endlosschleife bringen (GHSA-379p-g4f4-hq5h); der EXIF-Leser wurde ersetzt. Außerdem entfernt /view/{ID}.html jetzt <base>- und Meta-Refresh-Tags, und HTTP, SMTP und POP3 nehmen je höchstens 1000 gleichzeitige Verbindungen an. Neu sind Suchvorschläge mit Verlauf und ein zusammengesetzter Index auf den Tags. Neue Pflichtvariablen gibt es nicht. Im Test von v1.31.1 auf v1.32.0 genügte es, den Image-Tag zu ändern und die Befehle oben auszuführen; die gespeicherte Nachricht blieb erhalten, und /api/v1/info meldete v1.32.0. Beim Start schreibt v1.32.0 eine Warnung ins Log, wenn die Weboberfläche ohne --ui-auth-file oder --allowed-hosts lauscht. Im Container ist das erwartbar, solange der Port wie oben nur an 127.0.0.1 gebunden ist.

Typische Fehler und Lösungen

Verbindung verweigert auf Port 1025. Bei Anwendungen im Container ist oft localhost eingetragen; das zeigt auf den Container selbst. Tragen Sie den Dienstnamen mailpit ein und legen Sie beide Container ins selbe Netzwerk.

Nachrichten verschwinden nach einem Neustart. Volume oder MP_DATABASE fehlt; ohne Datenbankdatei hält Mailpit alles im Arbeitsspeicher.

Alte Nachrichten verschwinden im Betrieb. Begrenzung über MP_MAX_MESSAGES (Standard 500); Wert erhöhen.

Port 8025 ist bereits belegt. Hostseite ändern, etwa 127.0.0.1:8035:8025.

Weboberfläche hinter Reverse Proxy im Unterpfad leer. Option webroot (bzw. Umgebungsvariable) auf den Pfad setzen.

Datenbankfehler auf Netzlaufwerk. WAL abschalten oder Datenbank lokal ablegen.

Anmeldung greift nicht. Die Passwortdatei muss im Volume liegen und das Format benutzer:hash haben; Klartext funktioniert nicht.

Saubere Deinstallation

Container stoppen und löschen, Daten bleiben erhalten:

cd /opt/mailpit
sudo docker compose down

Sollen auch die Nachrichten weg, entfernen Sie das Volume. Achtung: Der folgende Befehl löscht alle gespeicherten Nachrichten und die Passwortdatei unwiderruflich. Legen Sie vorher eine Sicherung an, wenn Sie die Daten noch brauchen.

sudo docker compose down -v

Image und Verzeichnis entfernen:

sudo docker image rm axllent/mailpit:v1.32.0
sudo rm -rf /opt/mailpit

Stellen Sie die SMTP-Einstellungen der sendenden Anwendungen vor dem Abbau zurück.

Verifizieren: sudo docker volume ls | grep mailpit und sudo docker ps -a | grep mailpit liefern keine Treffer.

Was tatsächlich geprüft wurde

Im Test (Docker 29.1.3, Compose 2.40.3) ausgeführt: Start, Zustandsprüfung, Info-API, Testmail per SMTP, Abruf per API, Sicherung, Wiederherstellung in ein neues Volume und Start einer zweiten Instanz darauf.

Am 23.10.2026 lief außerdem das Update von v1.31.1 auf v1.32.0 mit der Compose-Datei aus dieser Anleitung: Die vorher per SMTP eingelieferte Testmail blieb im Volume erhalten, eine neue Nachricht kam an, die Weboberfläche antwortete mit HTTP 200, und der Container war healthy.

Passende Anleitungen auf S-EDV

Docker Compose unter Linux als Grundlage für Selfhosting erklärt die Bausteine, die hier verwendet werden.
Caddy als Reverse Proxy mit automatischem HTTPS ergänzt die Absicherung der Weboberfläche.
Eigener Mailserver mit Docker Mailserver ist die passende Lösung, wenn statt eines Auffangservers ein echter Mailbetrieb gebraucht wird.

Quellen

Projekt-Repository axllent/mailpit auf GitHub, Kennzahlen abgerufen am 13. September 2026
Mailpit-Dokumentation: Docker images
Mailpit: Veröffentlichungen, Version v1.32.0 vom 22. Oktober 2026