E-Mails aus selbst gehosteten Apps versenden

Welche selbst gehosteten Anwendungen E-Mails versenden müssen

Um E-Mails aus selbst gehosteten Anwendungen zu versenden, benötigen Sie keinen Mailserver. Sie benötigen ein Relay: ein authentifiziertes SMTP-Konto, das einmal auf dem Host konfiguriert wird und an das jede Anwendung auf diesem System ihre ausgehenden E-Mails übergibt. Ein eigenes Postfachsystem zu betreiben, ist die schwierige Aufgabe. Außerdem handelt es sich dabei um ein anderes Problem.

E-Mails zu empfangen bedeutet, Verbindungen aus dem gesamten Internet an Port 25 anzunehmen, Spam zu filtern, Postfächer zu speichern und zu sichern sowie den Ruf der IP-Adresse dauerhaft zu schützen. Diese Aufgabe ist tatsächlich schwieriger geworden. E-Mails zu versenden bedeutet dagegen: die E-Mail zum Zurücksetzen des Passworts, die Anmeldebestätigung, die Warnung „Sicherung fehlgeschlagen“ und die Benachrichtigung über eine Forumsantwort. Diese Nachrichten sind kurz, haben ein geringes Volumen und werden einzeln versendet. Ein Relay übernimmt diese Aufgabe. Die Einrichtung dauert einen Nachmittag.

Entscheiden Sie, welches der beiden Probleme Sie tatsächlich lösen möchten. Ob sich der Betrieb eines eigenen Postfachsystems noch lohnt, ist eine berechtigte Frage mit einer eindeutigen Antwort. Für die meisten lautet diese Antwort: nein. Wenn Ihre Antwort ja lautet, ist ein vollständiger Mailcow-Mailserver auf einem VPS der konsequente Weg. Die andere Hälfte, das Versenden, benötigen fast alle. Trotzdem plant es fast niemand ein.

Zuerst zwei Begriffe. SMTP (Simple Mail Transfer Protocol) ist das Protokoll, das alle beteiligten Komponenten verwenden. Ein Relay, auch Smarthost genannt, ist ein Server, der Ihre authentifizierten E-Mails annimmt und sie anschließend über seine eigenen Adressen und seinen eigenen Ruf zustellt.

Warum Ihr VPS über Port 25 keine E-Mails versenden kann

Fast alle VPS-Anbieter blockieren ausgehenden TCP-Port 25 standardmäßig. Port 25 wird von Mailservern verwendet, um andere Mailserver zu erreichen. Ein kompromittierter VPS mit offenem ausgehendem Port 25 könnte dadurch Spam direkt an jeden empfangenden Mailserver senden. Anbieter verwerfen diese Pakete, statt die Verbindung abzulehnen. Deshalb bleibt die Verbindung hängen und läuft anschließend in einen Timeout, statt einen Fehler zu melden.

Testen Sie dies auf dem Server:

sudo apt update && sudo apt install -y netcat-openbsd
nc -vz -w 5 gmail-smtp-in.l.google.com 25
nc -vz -w 5 smtp.relay.example 587

Wenn der erste Befehl die vollen fünf Sekunden wartet, während der zweite sofort antwortet, ist die Blockierung bestätigt. Einige Anbieter heben sie nach einer Prüfung des Kontos auf. Die meisten tun dies nicht.

Die Blockierung ist nicht der wichtigste Grund für den Einsatz eines Relays. Selbst bei offenem Port 25 landen direkt von einer neuen VPS-Adresse versendete E-Mails im Spam oder werden vollständig abgelehnt. Diese Adresse hat noch keine Versandhistorie und liegt in einem Adressbereich, den empfangende Server als Hosting-Bereich behandeln. Die Absender-Richtlinien von Google erfordern gültiges Forward- und Reverse-DNS für die sendende IP-Adresse. Außerdem verfügen viele VPS-Adressen über einen generischen PTR-Datensatz (Pointer), den Sie nicht ändern können. Ein Relay stellt Ihnen Adressen mit vorhandener Versandhistorie bereit.

Der Ausweg sind Submission-Ports. Port 587 verwendet STARTTLS. Dabei beginnt die Sitzung im Klartext und wird anschließend verschlüsselt. Port 465 verwendet implizites TLS (Transport Layer Security). Dabei ist die Sitzung bereits ab dem ersten Byte verschlüsselt. Beide Ports sind für authentifizierte Clients vorgesehen. Beide sind in VPS-Netzwerken geöffnet. Ihr Relay unterstützt mindestens einen davon.

Wählen Sie einen Relay-Dienst und eine Versand-Subdomain

Es gibt viele Anbieter für Transaktions-E-Mails. Sie erfüllen im Wesentlichen dieselbe Aufgabe. Bewerten Sie sie anhand von vier Kriterien:

• einen Submission-Port, 587 oder 465, mit SMTP AUTH
• DKIM-Signierung mit Ihrer eigenen Domain und Ihrem eigenen Selector, nicht nur mit denen des Anbieters
• auswertbare Daten zu Bounces und Beschwerden, über ein Dashboard oder einen Webhook
• ein Tarif, der zu Ihrem Versandvolumen passt. Im August 2026 bieten mehrere Anbieter weiterhin einige tausend Nachrichten pro Monat kostenlos an. Diese Bedingungen ändern sich häufig. Lesen Sie daher die aktuelle Preisseite und nicht irgendeinen Blogbeitrag.

Senden Sie E-Mails Ihrer Anwendungen über eine Subdomain. Verwenden Sie beispielsweise notify.example.com statt example.com. Empfänger bewerten die Reputation für jede Domain einzeln. Ein fehlerhafter Versand Ihrer Anwendungen wirkt sich dadurch nicht direkt auf die Domain aus, über die Ihre Rechnungen und die E-Mails Ihres Teams versendet werden. Berücksichtigen Sie jedoch die Einschränkung: Einige Empfänger übertragen Signale von Subdomains auf die Organisationsdomain. Eine Subdomain begrenzt den Schaden daher, schottet ihn aber nicht vollständig ab.

Relay für jede selbst gehostete Anwendung einmal konfigurieren

Der naheliegende Ansatz besteht darin, die Einstellungsseite jeder Anwendung zu öffnen und SMTP-Host, Benutzernamen und Passwort dort einzutragen. Nextcloud, das Forum, Grafana, Vaultwarden und der Uptime-Monitor haben alle ein entsprechendes Formular. Danach liegt das Zugangsdaten in sechs Stellen und sechs Formaten vor. Mehrere dieser Kopien befinden sich in einer Datenbank, die Sie als Daten und nicht als Konfiguration sichern. Wenn Sie das Passwort ändern, aktualisieren Sie fünf davon. Die sechste Anwendung sendet nicht mehr. Das geschieht still, weil die meisten Anwendungen den SMTP-Fehler serverseitig protokollieren und dem Benutzer trotzdem eine Erfolgsseite anzeigen.

Konfigurieren Sie den Versand stattdessen einmal auf dem Host und lassen Sie die Anwendungen lokal übergeben. Dafür eignen sich zwei Werkzeuge. Der Unterschied zwischen ihnen betrifft die Warteschlange.

msmtp ist ein sendmail-kompatibler Client ohne Daemon. Er verbindet sich, sendet die Nachricht und beendet sich. Er verwaltet keine Warteschlange. Ist das Relay nicht erreichbar, geht die Nachricht verloren und die aufrufende Anwendung erhält einen Exit-Status ungleich 0.

Postfix als Satellite ist ein vollständiger Mail Transfer Agent mit einer echten Warteschlange. Er nimmt die Nachricht sofort an, versucht die Zustellung bei Fehlern tagelang erneut und speichert die Relay-Zugangsdaten in einer nur für root lesbaren Datei. Verwenden Sie ihn, wenn während eines Relay-Ausfalls keine Warnung verloren gehen darf oder wenn mehrere Anwendungen unter verschiedenen Systembenutzern laufen.

msmtp, die kleine Variante

sudo apt update
sudo apt install -y msmtp msmtp-mta ca-certificates

msmtp-mta installiert den symbolischen Link /usr/sbin/sendmail. Dadurch erreicht jeder Aufruf von sendmail msmtp, ohne dass die aufrufende Anwendung davon wissen muss.

Schreiben Sie /etc/msmtprc:

defaults
auth            on
tls             on
tls_trust_file  /etc/ssl/certs/ca-certificates.crt
syslog          on

account         relay
host            smtp.relay.example
port            587
from            apps@notify.example.com
set_from_header on
user            <relay username>
password        <relay password>

account default : relay

set_from_header on setzt immer einen From-Header und überschreibt einen bereits vorhandenen Header. Dadurch ersetzt es den von der Anwendung erzeugten Wert durch die Adresse aus from. Ohne diese Einstellung sendet ein Cronjob als root@your-hostname. Das Relay lehnt diese Adresse ab, weil Sie sie nicht verifiziert haben. syslog on schreibt das Protokoll über syslog. Sie lesen es mit journalctl -t msmtp. Eine gemeinsame Datei unter logfile ist die Alternative. Dafür benötigt jeder Benutzer, der E-Mails sendet, Schreibrechte. Auf einem System mit mehreren Benutzern ist das eine häufige Fehlkonfiguration.

Setzen Sie die Berechtigungen selbst. msmtp erzwingt Berechtigungen für eine benutzerbezogene Konfiguration (~/.msmtprc). Mit contains secrets and therefore must have no more than user read/write permissions verweigert es dort den Start. Für /etc/msmtprc erzwingt es keine Berechtigungen, weil es diese Datei einfach lädt, wenn sie lesbar ist.

sudo chown root:root /etc/msmtprc
sudo chmod 600 /etc/msmtprc
printf 'Subject: relay test\n\nsent from the host\n' | sudo sendmail -v you@example.com

-v gibt den vollständigen SMTP-Dialog aus. Dadurch sehen Sie jede Antwort des Relays. Ein erfolgreicher Versand endet mit einer 250-Antwort, die die Nachricht annimmt. Eine authentication failed-Zeile bedeutet, dass Benutzername oder Passwort falsch sind oder dass das Relay anstelle des Kontopassworts einen API-Schlüssel erwartet.

Jetzt kommt der Nachteil. Er ist der Grund, warum viele Benutzer letztlich Postfix einsetzen. Bei Modus 600 und dem Eigentümer root kann nur root senden. Eine Anwendung unter www-data kann die Datei nicht lesen. msmtp überspringt sie und die Anwendung schlägt mit einem Fehler über das nicht gefundene Standardkonto fehl. Die Lösung ist eine Gruppe:

sudo chgrp mail /etc/msmtprc
sudo chmod 640 /etc/msmtprc
sudo usermod -aG mail www-data

Formulieren Sie die Bedeutung eindeutig: Jedes Mitglied der Gruppe mail kann das Relay-Passwort lesen und von diesem System aus E-Mails als Ihre Domain senden. Auf einem VPS, den Sie allein verwalten, ist das vertretbar. Wenn mehrere Anwendungen, die Sie nicht selbst geschrieben haben, unter verschiedenen Benutzern laufen, ist es das nicht. Dann ist Postfix die bessere Lösung, weil diese Anwendungen die Zugangsdaten nie sehen.

Postfix als Satellite

sudo debconf-set-selections <<'EOF'
postfix postfix/main_mailer_type select Satellite system
postfix postfix/mailname string notify.example.com
postfix postfix/relayhost string [smtp.relay.example]:587
EOF
sudo DEBIAN_FRONTEND=noninteractive apt install -y postfix libsasl2-modules

libsasl2-modules ist erforderlich. Ohne dieses Paket protokolliert Postfix warning: SASL authentication failure: No worthy mechs found, weil die Bibliotheken für die Mechanismen PLAIN und LOGIN unter /usr/lib/sasl2 nicht installiert sind.

Legen Sie den Rest mit postconf -e fest. Dieser Befehl bearbeitet /etc/postfix/main.cf direkt:

sudo postconf -e 'relayhost = [smtp.relay.example]:587'
sudo postconf -e 'smtp_sasl_auth_enable = yes'
sudo postconf -e 'smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd'
sudo postconf -e 'smtp_sasl_security_options = noanonymous'
sudo postconf -e 'smtp_tls_security_level = encrypt'
sudo postconf -e 'smtp_tls_CAfile = /etc/ssl/certs/ca-certificates.crt'
sudo postconf -e 'inet_interfaces = loopback-only'

Die eckigen Klammern um den Relay-Hostnamen verhindern, dass Postfix für diesen Namen einen MX-Record abfragt. Stattdessen verbindet es sich direkt mit dem angegebenen Namen. Einige Relay-Hostnamen veröffentlichen MX-Records, die auf einen anderen Server zeigen. Ohne die Klammern wird Ihre E-Mail an diesen falschen Server weitergeleitet.

smtp_tls_security_level = encrypt macht TLS verpflichtend. Die Nachricht wird dadurch niemals unverschlüsselt gesendet. Das Zertifikat wird damit jedoch nicht überprüft. Die Dokumentation von Postfix weist ausdrücklich darauf hin: Auf dieser Ebene wird die Zustellung fortgesetzt, auch wenn das Serverzertifikat nicht vertrauenswürdig ist oder den falschen Namen trägt. Wenn das Zertifikat geprüft werden soll, verwenden Sie verify oder secure und lassen Sie smtp_tls_CAfile aktiviert.

Die Zugangsdaten gehören in eine einzige Datei, die nur root lesen kann:

echo '[smtp.relay.example]:587 relay-username:relay-password' | sudo tee /etc/postfix/sasl_passwd
sudo chmod 600 /etc/postfix/sasl_passwd
sudo postmap hash:/etc/postfix/sasl_passwd
sudo systemctl restart postfix

postmap erstellt die indizierte Kopie, die Postfix tatsächlich liest. Wenn Sie die Textdatei später bearbeiten und postmap vergessen, verwendet Postfix weiterhin die alte Datenbank. Im Protokoll gibt es keinen Hinweis darauf. In Postfix 3.9 und neuer ist der Standardtyp der Map lmdb. Wenn Sie diesen Typ bevorzugen, schreiben Sie lmdb: sowohl in den Parameter als auch in das Argument postmap. Die Angabe des Typs in beiden Zeilen stellt sicher, dass beide Einstellungen zusammenpassen.

Die Anwendungen adressieren ihre E-Mails weiterhin als root@hostname. Schreiben Sie den Absender um:

echo '/.+/    apps@notify.example.com' | sudo tee /etc/postfix/sender_canonical
sudo postconf -e 'sender_canonical_classes = envelope_sender, header_sender'
sudo postconf -e 'sender_canonical_maps = regexp:/etc/postfix/sender_canonical'
sudo systemctl reload postfix

Eine regexp:-Tabelle wird direkt gelesen und benötigt daher kein postmap. Jede Nachricht wird nun mit demselben Envelope-Sender und demselben From-Header versendet. Das entspricht den Anforderungen des Relays. Der Nachteil ist, dass alle Antworten an dieselbe Stelle gehen. Setzen Sie daher in jeder Anwendung einen Reply-To-Header, wenn Antworten eine bestimmte Person erreichen sollen.

Senden Sie eine Testnachricht und lesen Sie das Protokoll:

printf 'Subject: postfix relay test\n\nsent through the queue\n' | sendmail you@example.com
sudo tail -n 20 /var/log/mail.log

Eine zugestellte Nachricht protokolliert status=sent, gefolgt von der Antwort des Relays in eckigen Klammern. Jede andere Ausgabe nennt den Grund für den Fehler. status=deferred zusammen mit Connection timed out bedeutet, dass noch etwas auf Port 25 zeigt. Host or domain name not found. Name service error for name=smtp.relay.example type=A bedeutet, dass der Relay-Hostname falsch ist oder DNS auf dem System nicht funktioniert. mailq listet die blockierten Nachrichten auf, und sudo postqueue -f versucht die Zustellung sofort erneut.

Den Host-Relay aus Docker-Containern erreichen

Ein Container kann den Host-sendmail nicht aufrufen, weil sich die Binärdatei nicht im Image befindet und die Queue nicht gemeinsam genutzt wird. Geben Sie den Containern stattdessen ein Netzwerkziel. Postfix kann auf der Adresse der Docker-Bridge lauschen.

ip -4 addr show docker0
sudo postconf -e 'inet_interfaces = 127.0.0.1, 172.17.0.1'
sudo postconf -e 'mynetworks = 127.0.0.0/8 172.17.0.0/16'
sudo systemctl restart postfix

Lesen Sie die eigene Bridge-Adresse aus dem ersten Befehl aus, statt diese hier zu übernehmen, weil ein Compose-Projekt sein eigenes Netzwerk in einem anderen Subnetz erstellt und docker network inspect <name> dieses ausgibt. Verwenden Sie hier restart und nicht reload: In der Postfix-Dokumentation steht, dass Sie Postfix nach einer Änderung an inet_interfaces stoppen und starten müssen. Ein Reload übernimmt die Änderung nicht. Jede Anwendung verwendet anschließend den SMTP-Host 172.17.0.1, Port 25, keine Authentifizierung und kein TLS, weil dieser Datenverkehr den Host nicht verlässt. Wenn Ihre Dienste in einem Compose-Netzwerk laufen, erklärt Docker Compose auf einem VPS ausführen, woher dieses Subnetz stammt.

Dies ist der Schritt, der Probleme verursachen kann. Ein Postfix, der auf einer öffentlichen Adresse mit einem weit gefassten mynetworks lauscht, ist ein offenes Relay: Unbekannte senden ihre E-Mails über Ihr Relay-Konto, der Provider sperrt es und der Ruf Ihrer Domain wird für Monate beschädigt. Prüfen Sie nach jeder Änderung beide Seiten.

ss -tlnp | grep ':25'

Die Ausgabe darf nur die Loopback-Adresse und die Bridge-Adresse enthalten. Von einem anderen Rechner aus muss nc -vz your.server.ip 25 fehlschlagen.

SPF, DKIM und DMARC für die Absenderdomain

Veröffentlichen Sie alle drei Records vor dem ersten echten Versand. Sie sind kostenlos, liegen im DNS und werden von empfangenden Servern zuerst geprüft.

SPF (Sender Policy Framework) listet auf, wer Ihre Domain im Envelope-Absender verwenden darf. Veröffentlichen Sie den Record auf der Versand-Subdomain:

notify.example.com.  IN  TXT  "v=spf1 include:_spf.relay.example -all"

Übernehmen Sie den Wert include: von der eigenen Einrichtungsseite Ihres Relays. Ein Include, das nicht aufgelöst werden kann, führt zu einem permanenten Fehler statt zu einem Pass. Die SPF-Auswertung endet nach zehn Mechanismen, die DNS-Abfragen auslösen, und gibt dann permerror zurück. Empfänger werten das als Fehler. Halten Sie die Anzahl der Includes daher gering. Veröffentlichen Sie pro Namen genau einen v=spf1-Record. Zwei davon ergeben ebenfalls einen permerror.

DKIM (DomainKeys Identified Mail) signiert jede Nachricht mit einem privaten Schlüssel, den das Relay verwaltet. Empfänger rufen den zugehörigen öffentlichen Schlüssel aus dem DNS ab. Ihr Relay stellt Ihnen einen Selector sowie entweder einen TXT-Record oder einen zu veröffentlichenden CNAME bereit:

sel1._domainkey.notify.example.com.  IN  CNAME  sel1.dkim.relay.example.

DKIM ist wichtiger als SPF, weil DKIM beim Weiterleiten erhalten bleibt. Wenn eine Mailingliste oder eine .forward-Regel Ihre Nachricht weiterleitet, kommt sie von der IP-Adresse des Weiterleiters. Dadurch schlägt SPF fehl, während die Signatur weiterhin verifiziert werden kann.

DMARC (Domain-based Message Authentication, Reporting and Conformance) teilt Empfängern mit, wie sie vorgehen sollen, wenn keine der beiden Prüfungen übereinstimmt, und fordert sie auf, Berichte zurückzusenden. Veröffentlichen Sie den Record auf der Organisationsdomain:

_dmarc.example.com.  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com; adkim=r; aspf=r"

Beginnen Sie mit p=none und werten Sie die Berichte zwei Wochen lang aus. p=none ändert nichts an der Zustellung. Es aktiviert nur die Berichterstellung. So finden Sie Systeme, die Sie vergessen haben und die Nachrichten mit Ihrer Domain als Absender versenden. Wechseln Sie anschließend zu p=quarantine und danach zu p=reject. Wenn Sie am ersten Tag p=reject veröffentlichen, entdecken Sie unter Umständen erst durch einen Kunden, der keine Rechnung erhalten hat, dass Ihr Rechnungssystem Nachrichten mit Ihrer Domain als Absender versendet hat.

Prüfen Sie, was im Internet sichtbar ist, nicht nur die Anzeige in Ihrem DNS-Panel:

dig +short TXT notify.example.com
dig +short TXT sel1._domainkey.notify.example.com
dig +short TXT _dmarc.example.com

Eine leere Ausgabe bedeutet, dass der Record noch nicht propagiert wurde oder der Name falsch ist. Ein Record, den Sie vor fünf Minuten korrigiert haben, kann wegen Caches noch so lange falsch erscheinen wie sein vorheriger TTL-Wert (Time to Live) gilt. Prüfen Sie daher den TTL-Wert, bevor Sie eine Schlussfolgerung ziehen.

Absender und Return-Path aufeinander abstimmen

Jede Nachricht enthält zwei Absenderadressen, die unterschiedlich geprüft werden. Der Envelope-Absender wird im SMTP-Befehl MAIL FROM angegeben und erscheint in der zugestellten Nachricht als Return-Path. Der Header From enthält die Adresse, die der Empfänger sieht.

SPF prüft die Domain des Envelope-Absenders gegen die IP-Adresse, die die Verbindung herstellt. DKIM gibt die signierende Domain als d= an. DMARC ist nur dann erfolgreich, wenn mindestens eine dieser beiden Domains mit der Domain im Header From übereinstimmt. Bei einer entspannten Ausrichtung (adkim=r, aspf=r, dies ist der Standard) zählt auch eine Subdomain. Daher ist ein Envelope-Absender unter notify.example.com auf die Domain eines Header From unter example.com ausgerichtet. Bei einer strikten Ausrichtung ist dies nicht der Fall.

Die praktische Regel ist einfach: Verwenden Sie für den Header From und den Envelope-Absender dieselbe Domain. Dann stellt sich diese Frage nicht. Genau das bewirkt set_from_header on in msmtp und sender_canonical_maps in Postfix.

Lesen Sie das Ergebnis in einer zugestellten Nachricht. In Gmail zeigt „Original anzeigen“ den Header an, den der Empfänger geschrieben hat:

Authentication-Results: mx.google.com;
       dkim=pass header.i=@notify.example.com;
       spf=pass (google.com: domain of apps@notify.example.com designates 198.51.100.25 as permitted sender) smtp.mailfrom=apps@notify.example.com;
       dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=example.com

Dort sind alle drei Prüfungen erfolgreich. In allen anderen Fällen wird die fehlgeschlagene Prüfung und meist auch der Grund genannt. Das ist die schnellste verfügbare Information zur Fehlersuche bei diesem Thema.

Bounces und Beschwerden, bevor das Versandvolumen steigt

Ein Bounce bedeutet, dass der empfangende Server Ihre Nachricht ablehnt. Ein Hard Bounce ist dauerhaft. Gmail bezeichnet ihn als 550 5.1.1 The email account that you tried to reach does not exist. Ein Soft Bounce ist vorübergehend. Ein 4xx-Code kann beispielsweise auf ein volles Postfach oder Greylisting hinweisen. Das Relay führt den erneuten Zustellversuch selbstständig aus.

Relays messen Ihre Hard-Bounce-Rate und sperren Konten, die weiterhin nicht vorhandene Adressen anschreiben. Dieses Muster entspricht dem typischen Verhalten beim Versand an eine gekaufte Adressliste. Beschwerden sind noch wichtiger. Eine Beschwerde entsteht, wenn jemand auf die Spam-Schaltfläche klickt. Die Google-Richtlinien für Absender (Stand August 2026) verlangen, dass die Spam-Rate laut Postmaster Tools unter 0.30% bleibt, und empfehlen weniger als 0.10%.

Vor dem Anstieg des Versandvolumens müssen vier Dinge vorhanden sein:

• ein Webhook oder eine wöchentliche Prüfung der Suppressionsliste des Relays, damit Sie Bounces überhaupt erkennen
• eine From-Adresse, die ein echtes Postfach ist und von jemandem gelesen wird, mit gesetztem Reply-To für die Zieladresse von Antworten
• eine Bestätigung, bevor eine Adresse irgendwo hinzugefügt wird, damit Sie nie an eine Adresse senden, die deren Inhaber nicht selbst eingegeben hat
• eine Rate-Limit-Begrenzung für jedes Formular, das den E-Mail-Versand auslöst

An diesen letzten beiden Punkten scheitern selbst gehostete Anwendungen zuerst. Ein ungeschütztes Anmeldeformular erlaubt es jedem, die Adresse einer anderen Person einzugeben. Ihr Server sendet daraufhin die Bestätigung, und die betroffene Person markiert sie als Spam. Subscription-Bombing am Anmeldeformular verhindern ist daher ebenso eine Aufgabe für die Zustellbarkeit wie für den Schutz vor Missbrauch.

Halten Sie Massenversand von diesem Pfad fern. Newsletter benötigen eine Listenverwaltung und Abmelde-Header, die bei transaktionalen E-Mails nicht erforderlich sind. Betreiben Sie sie daher über eine selbst gehostete Listmonk-Instanz auf einer eigenen Subdomain mit eigener Reputation. Benachrichtigungs-E-Mails aus einem selbst gehosteten Forum liegen dazwischen: Sie haben die Struktur transaktionaler E-Mails, aber das Versandvolumen von Massenmails. Meist zeigen sie zuerst, ob Ihre Konfiguration zuverlässig funktioniert.

Zur Einordnung: Die Regeln von Gmail für Massenversender gelten ab 5,000 Nachrichten pro Tag an Gmail-Adressen. Sie verlangen SPF, DKIM, DMARC und eine Abmeldung mit einem Klick für Marketing-E-Mails. Die meisten selbst gehosteten Anwendungen erreichen diese Grenze nie. Die Authentifizierung wird inzwischen unabhängig davon von jedem Absender erwartet.

Testen Sie die Konfiguration, bevor Sie ihr vertrauen

swaks ist dafür das passende Werkzeug. Es spricht SMTP und gibt die vollständige Kommunikation aus. Dadurch sehen Sie, an welchem Schritt der Fehler auftritt.

sudo apt install -y swaks
swaks --to you@example.com --from apps@notify.example.com --server smtp.relay.example --port 587 --tls --auth-user '<relay username>' --auth-password '<relay password>'

Damit testen Sie die Anmeldedaten direkt gegen das Relay. Um den Pfad zu testen, den Ihre Anwendungen tatsächlich verwenden, geben Sie stattdessen das Relay des Hosts an:

swaks --to you@example.com --from apps@notify.example.com --server 127.0.0.1

Prüfen Sie anschließend das Ergebnis Ende zu Ende mit echten E-Mails vom Server aus. Keine dieser Prüfungen lässt sich anhand von Konfigurationsdateien nachweisen. Führen Sie sie daher selbst durch:

• Senden Sie eine Nachricht an einen Bewertungsdienst wie mail-tester.com. Dieser liest Ihre SPF-, DKIM- und DMARC-Einträge sowie den Nachrichteninhalt und nennt die Gründe für die Bewertung.
• Senden Sie eine Nachricht an ein Postfach bei jedem der beiden Anbieter, die Ihre Benutzer tatsächlich verwenden, und lesen Sie Authentication-Results in der Rohfassung der Nachricht.
• Prüfen Sie eine Nachricht über learndmarc.com, wenn das Ergebnis der Ausrichtung nicht eindeutig ist.
• Lösen Sie den Versand direkt in der Anwendung aus, nicht nur über die Befehlszeile. Die Anwendung setzt den From-Header.

Zum Abschluss ein wichtiger Hinweis: Eine völlig neue Domain kann trotz korrekter Einträge für alle drei Verfahren gelegentlich im Spam-Ordner landen. Sie hat noch keine Reputation, und empfangende Mailserver sind gegenüber Domains vorsichtig, die erst seit der letzten Woche existieren. Beginnen Sie mit einem kleinen Versandvolumen und senden Sie Nachrichten, die die Empfänger erwarten. Die Reputation baut sich anschließend auf. Keine Konfiguration kann diesen Prozess überspringen.

FAQ

Warum ist der ausgehende Port 25 auf meinem VPS blockiert?

Nahezu jeder Anbieter blockiert den ausgehenden TCP-Port 25 standardmäßig, weil ein kompromittierter Server mit geöffnetem Port Spam direkt an empfangende Mailserver zustellen kann. Die Pakete werden verworfen und nicht abgelehnt. Das äußert sich als Verbindung, die hängen bleibt und anschließend in einen Timeout läuft, nicht als Fehlermeldung. Bestätigen Sie das, indem Sie nc -vz -w 5 gmail-smtp-in.l.google.com 25 neben nc -vz -w 5 smtp.relay.example 587 ausführen: Der erste Befehl wartet, der zweite antwortet sofort. Bitten Sie nicht darum, die Sperre aufzuheben. Senden Sie über ein Relay am Submission-Port 587 oder 465. Diese Ports bleiben geöffnet und sind für authentifizierte Clients vorgesehen.

Benötige ich SPF, DKIM und DMARC, wenn ich nur einige App-Benachrichtigungen senden möchte?

Ja. Das Versandvolumen ändert daran nichts. Empfänger wenden dieselben Prüfungen auf eine einzelne Kennwortzurücksetzung wie auf eine Kampagne mit fünfzigtausend Nachrichten an. Ohne SPF und DKIM ist Ihre Mail nicht authentifiziert. Die aktuellen Absenderanforderungen von Google verlangen von jedem Absender mindestens einen dieser beiden Mechanismen. Ohne DMARC erhalten Sie keine Reports. Das erste Anzeichen eines Problems ist dann, dass ein Benutzer meldet, der Link zur Kennwortzurücksetzung sei nicht angekommen. Alle drei Mechanismen werden als DNS-Records veröffentlicht, verursachen keine Kosten, und die Veröffentlichung dauert etwa zehn Minuten.

Sollte ich msmtp oder Postfix als Relay-Client verwenden?

Verwenden Sie msmtp, wenn eine Person den Server administriert und der Verlust einer Nachricht während eines Relay-Ausfalls akzeptabel ist. Es besteht aus einer einzelnen Konfigurationsdatei und benötigt keinen Daemon. Da es keine Warteschlange verwendet, ist eine Nachricht verloren, wenn das Relay nicht erreichbar ist. Verwenden Sie Postfix als Satellite, wenn Sie eine Warteschlange benötigen, die mehrere Tage lang erneut zustellt, oder wenn mehrere Apps unter verschiedenen Systembenutzern laufen. Postfix speichert das Relay-Kennwort in einer nur für root lesbaren Datei, auf die Apps nicht zugreifen. Bei msmtp muss die Konfiguration hingegen für jeden Benutzer lesbar sein, der Nachrichten sendet.

Warum wird die Mail meiner App abgelehnt, weil sie von root stammt?

Cron-Jobs und viele Apps erzeugen den Absender aus dem lokalen Benutzer und dem Hostnamen. Dadurch entsteht beispielsweise root@srv1.localdomain. Diese Adresse wurde beim Relay nicht verifiziert. Deshalb lehnt das Relay die Nachricht mit einer 553- oder 554-Antwort ab, in der die Absenderadresse genannt wird. Beheben Sie das auf Hostebene und nicht in jeder einzelnen App: mit set_from_header on zusammen mit einer from-Adresse in /etc/msmtprc oder mit sender_canonical_maps und sender_canonical_classes = envelope_sender, header_sender in Postfix. Setzen Sie Reply-To innerhalb der jeweiligen App, wenn Antworten eine Person erreichen sollen.

Schützt eine eigene Subdomain für App-Mail meine Hauptdomain tatsächlich?

Teilweise. Trotzdem ist diese Maßnahme sinnvoll. Empfänger führen die Reputation für jede Domain getrennt. Beschwerden gegen notify.example.com wirken sich daher größtenteils auf notify.example.com aus, während Ihre Hauptdomain weiterhin Nachrichten zustellt. Die Einschränkung ist relevant: Einige Empfänger übertragen Signale von Subdomains auf die Organisationsdomain. Außerdem gilt eine auf Organisationsebene veröffentlichte DMARC-Richtlinie auch für Subdomains, sofern Sie sp= nicht separat setzen. Betrachten Sie die Subdomain als Begrenzung möglicher Schäden und nicht als Garantie.