Warum kommen meine Mails vom Root-Server nicht an?

Du hast einen Root-Server, Plesk ist installiert, der Mailserver läuft, und trotzdem landen Mails entweder im Spam oder kommen gar nicht an. Dieses Szenario ist häufiger als man denkt, und die Ursachen sind meistens dieselben. Hier ist der Debugging-Prozess der tatsächlich funktioniert.

Schritt 1: TLS-Zertifikat prüfen

Zuerst prüfen ob das Zertifikat des Mailservers überhaupt noch gültig ist:

echo | openssl s_client -connect mail.example.de:465 -servername mail.example.de 2>/dev/null | openssl x509 -noout -dates

Wenn notAfter in der Vergangenheit liegt, ist das Zertifikat abgelaufen. In Plesk unter Websites & Domains → example.de → SSL/TLS-Zertifikate das Let’s Encrypt-Zertifikat neu ausstellen. Wichtig: in Plesk gibt es ein separates Zertifikat für den Mailserver, darauf achten dass beide erneuert werden.

Schritt 2: Postfix-Logs nach der Queue-ID durchsuchen

Jede Mail die Postfix annimmt bekommt eine Queue-ID. Die findet sich in den SMTP-Logs oder im Response des Mailservers. Mit dieser ID den kompletten Weg der Mail verfolgen:

grep "QUEUE-ID" /var/log/maillog

Die letzte Zeile ist entscheidend, entweder status=sent oder eine Fehlermeldung vom Ziel-Server. Ein typischer Gmail-Bounce sieht so aus:

status=bounced (host gmail-smtp-in.l.google.com said:
550-5.7.26 Your email has been blocked because the sender is unauthenticated.
550-5.7.26 DKIM = did not pass
550-5.7.26 SPF [example.de] with ip: [1.2.3.4] = did not pass)

Gmail sagt dir hier genau was fehlt.

Schritt 3: SPF auf der richtigen Domain

Der häufigste Fehler überhaupt: SPF ist nur auf der Mail-Subdomain gesetzt (mail.example.de), aber die Mails kommen von der Hauptdomain (example.de). Gmail und andere Mailserver prüfen den Envelope-From, und der zeigt auf die Hauptdomain.

Prüfen:

dig TXT example.de | grep spf
dig TXT mail.example.de | grep spf

Wenn nur die Subdomain einen SPF-Record hat, fehlt das Entscheidende. Lösung: TXT-Record für @ (Hauptdomain) beim DNS-Anbieter hinzufügen:

v=spf1 ip4:DEINE-SERVER-IP ~all

Schritt 4: DKIM aktivieren

DKIM fehlt auf vielen Plesk-Installationen komplett. Prüfen:

dig TXT default._domainkey.example.de

Keine Antwort = kein DKIM. In Plesk unter Mail → example.de → Mail Settings DKIM aktivieren. Plesk generiert den DNS-Eintrag automatisch und zeigt ihn an, diesen TXT-Record beim DNS-Anbieter unter default._domainkey.example.de eintragen.

Schritt 5: DMARC-Record setzen

Optional, aber gut für die Reputation. Signalisiert empfangenden Servern dass die Domain aktiv verwaltet wird:

Name: _dmarc
Type: TXT
Value: v=DMARC1; p=none; rua=mailto:postmaster@example.de

p=none ist reines Monitoring, keine Mails werden abgelehnt, aber die Domain baut Reputation auf.

Schritt 6: DNS-Propagation abwarten und prüfen

Nach DNS-Änderungen kurz warten (5-30 Minuten) und dann direkt prüfen ob die Records aktiv sind:

dig TXT example.de
dig TXT default._domainkey.example.de
dig TXT _dmarc.example.de

Sonderfall: Mail landet nie an, auch kein Bounce

Wenn eine Mail laut Logs status=sent hat aber trotzdem nie ankommt: prüfen ob Absender und Empfänger auf demselben Server liegen. Postfix liefert Mails an lokale Domains intern zu, ohne sie extern zu routen. Eine Mail von newsletter@example.de an user@example.de landet direkt in der lokalen Mailbox, auch wenn der Absender eine externe Anwendung ist. In diesem Fall einfach eine externe Adresse zum Testen verwenden.

Die häufigsten Ursachen auf einen Blick

Fazit

Die gute Nachricht: die Ursachen sind fast immer dieselben. Ein abgelaufenes Zertifikat, ein fehlender SPF-Record auf der falschen Domain, oder kein DKIM. Die Postfix-Logs mit der Queue-ID sind dabei das wichtigste Werkzeug, damit lässt sich jede Mail lückenlos bis zur Zustellung oder zum Bounce verfolgen.

Verwandtes Problem: Wenn Mails zwischen zwei Domains auf demselben Plesk-Server fehlschlagen und du den Fehler User unknown in virtual mailbox table siehst, liegt das an einem anderen Plesk-Verhalten, hier habe ich das erklärt.