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.