Grosse Mailprovider weisen E-Mails ab oder sortieren sie in den Spam-Ordner, wenn der Absender-Server technisch nicht sauber auftritt. Hier erfahren Sie, welche Angaben zusammenpassen müssen und wie Sie das prüfen.

Das Problem in Kürze

Eine Offerte oder Rechnung kommt beim Empfänger nicht an, landet im Spam oder wird mit einer Fehlermeldung zurückgewiesen. Der Mailserver läuft, die Mailprogramme Ihrer Mitarbeitenden funktionieren, und trotzdem scheitert die Zustellung bei T-Online, Gmail oder Outlook.

Die Provider prüfen heute schon beim Verbindungsaufbau, ob der sendende Server vertrauenswürdig wirkt. Dahinter stehen Spam- und Phishing-Abwehr sowie die Reputation des Absenders: Wer sich technisch sauber ausweist, wird eher angenommen als ein anonymer Server. Die wichtigsten Bausteine sind:

• Reverse-DNS (PTR): Die IP-Adresse Ihres Servers verweist auf einen Namen.
• Forward-DNS (A/AAAA): Dieser Name verweist wieder auf dieselbe IP-Adresse.
• HELO/EHLO: Der Name, mit dem sich Ihr Server beim Empfänger vorstellt, passt dazu.
• SPF, DKIM und DMARC: Die Absenderdomain ist authentifiziert (siehe DMARC-FAQ).

Die Anforderungen unterscheiden sich je nach Provider. Wo wir sie belegen können, nennen wir die Quelle am Ende des Artikels.

Typische Fehlermeldungen

Diese Meldungen sehen Sie oder Ihre Kunden in Unzustellbarkeitsberichten (Bounces):

Die Meldungen von Gmail stammen aus der Gmail-Dokumentation, jene von T-Online von der Postmaster-Seite. Der exakte Wortlaut kann sich beim Provider ändern. Suchen Sie im Bounce vor allem nach Hinweisen auf PTR, reverse DNS oder IPv6.

PTR, A/AAAA und Forward-Confirmed rDNS

Der PTR-Eintrag (Reverse-DNS) ordnet einer IP-Adresse einen Hostnamen zu. Er wird nicht in Ihrer Domain verwaltet, sondern vom Inhaber der IP-Adresse, in der Regel dem Hosting- oder Internetanbieter. Beim Hosting-Anbieter setzen Sie ihn meist im Kundenportal oder über den Support.

Beim Forward-Confirmed reverse DNS (FCrDNS) wird die Zuordnung in beide Richtungen geprüft:

1. Der PTR der Absender-IP zeigt auf einen Hostnamen.
2. Dieser Hostname löst per A-Record (IPv4) bzw. AAAA-Record (IPv6) wieder auf genau diese IP auf.

Das gilt pro IP-Adresse. Hat Ihr Server IPv4 und IPv6 (Dual-Stack), braucht der Hostname sowohl einen A- als auch einen AAAA-Record, und beide IP-Adressen brauchen einen PTR auf diesen Hostnamen. Beispiel mit Platzhaltern (example.com, Adressen aus den für Dokumentation reservierten Bereichen):

; Forward-DNS in der Zone example.com
mail.s1.example.com.  IN  A     192.0.2.10
mail.s1.example.com.  IN  AAAA  2001:db8::10

; Reverse-DNS beim Inhaber der IP-Adressen
10.2.0.192.in-addr.arpa.                                          IN  PTR  mail.s1.example.com.
0.1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa.  IN  PTR  mail.s1.example.com.

Häufiger Stolperstein: PTR gesetzt, Name löst nicht auf

Oft wird der PTR zuerst gesetzt, der zugehörige Hostname aber nie in der DNS-Zone angelegt. Dann zeigt dig -x scheinbar das richtige Ergebnis, doch der Name selbst hat weder A- noch AAAA-Record, und FCrDNS ist nicht erfüllt. Prüfen Sie deshalb immer beide Richtungen, am besten gegen die für die Domain zuständigen Nameserver.

Die IPv6-Falle

Hat der Server eine IPv6-Adresse, versendet Postfix standardmässig bevorzugt darüber. Fehlt der PTR für diese IPv6-Adresse, weist zum Beispiel Gmail die Mails ab (siehe Fehlermeldung oben), obwohl der IPv4-PTR korrekt gesetzt ist. Die Lösung ist, auch für IPv6 einen PTR einzurichten.

Als Notbehelf lässt sich der Versand über IPv6 in Postfix abschalten:

# /etc/postfix/main.cf
# Variante 1: Postfix nutzt gar kein IPv6
inet_protocols = ipv4

# Variante 2: IPv6 bleibt aktiv, ausgehend wird IPv4 bevorzugt
smtp_address_preference = ipv4

Beide Varianten sind eine Übergangslösung. Auch bei ipv4 sollte der IPv6-PTR korrekt sein, sobald IPv6 wieder genutzt wird.

Generische PTR-Einträge

Viele Anbieter setzen automatisch einen generischen PTR wie static.123.example-provider.net. Er erfüllt FCrDNS zwar oft formal, sagt aber nichts über den Betreiber aus. Mehrere Provider werten solche Namen ab. T-Online verlangt zudem, dass aus dem Hostnamen die Domain des Betreibers hervorgeht (siehe Abschnitt Impressum weiter unten). Verwenden Sie deshalb einen eigenen, sprechenden Hostnamen unter Ihrer Domain.

HELO/EHLO und Postfix

Zu Beginn jeder SMTP-Verbindung stellt sich Ihr Server mit einem Namen vor (HELO bzw. EHLO). In Postfix steuert das der Parameter smtp_helo_name. Ist er nicht gesetzt, gilt $myhostname.

Der gemeldete Name muss ein voll qualifizierter Domainname (FQDN) sein, der per DNS auflöst. Sinnvollerweise ist es derselbe Name wie im PTR. Wie der Server intern heisst, spielt keine Rolle: Entscheidend ist, dass HELO, PTR und A/AAAA übereinstimmen.

Der Servername muss dafür nicht geändert werden. Postfix kennt zwei Parameter: myhostname gilt für die gesamte Postfix-Konfiguration, smtp_helo_name betrifft nur den Namen, den Postfix bei ausgehenden Verbindungen meldet. Soll lediglich HELO zum PTR passen, ist smtp_helo_name die gezieltere Wahl. Der SMTP-Banner auf Port 25 (z.B. 220 s1.example.com ESMTP Postfix) betrifft den Empfang und darf deshalb weiterhin den Servernamen zeigen.

# /etc/postfix/main.cf
smtp_helo_name = mail.s1.example.com

Nach einer Änderung lädt postfix reload die Konfiguration neu.

Hat der Server mehrere IP-Adressen, wählt Postfix die Absenderadresse selbst. Mit smtp_bind_address (IPv4) und smtp_bind_address6 (IPv6) legen Sie fest, welche IP für ausgehende Verbindungen verwendet wird. Diese IP-Adressen müssen dann den PTR und den A/AAAA-Eintrag des HELO-Namens tragen. Pro Postfix-Instanz gibt es nur einen smtp_helo_name; setzen Sie daher für jede Absender-IP denselben Namen oder trennen Sie den Versand auf mehrere Instanzen.

TLS und Zertifikat

Beim Versand prüft der empfangende Server kein Client-Zertifikat. Gmail verlangt von allen Absendern aber eine TLS-Verbindung. Aktivieren Sie deshalb opportunistisches TLS für ausgehende Mails (smtp_tls_security_level = may). Ein gültiges Zertifikat auf dem HELO- bzw. MX-Namen ist wichtig, wenn derselbe Host auch Mails empfängt oder Mailprogramme sich anmelden (Submission), und gehört zu einer sauberen Gesamtkonfiguration.

Impressum bei T-Online

T-Online verlangt auf der Postmaster-Seite, dass aus dem Hostnamen (FQDN) zur IP-Adresse des anliefernden Systems die Domain und damit die Website des Betreibers mit unmittelbarer Kontaktmöglichkeit einfach nachvollziehbar hervorgeht. Für gewerbliche Massenmails ist ein Impressum anzugeben. Als Grundlage nennt T-Online unter anderem Art. 5 der E-Commerce-Richtlinie 2000/31/EG. Für deutsche Anbieter gilt dazu § 5 DDG (seit Mai 2024 anstelle des TMG), für Schweizer Firmen zusätzlich Art. 3 Abs. 1 lit. s UWG.

Technisch bedeutet das: Unter dem Hostnamen aus dem PTR (und unter der Absenderdomain) antwortet ein Webserver auf Port 80 und 443 mit gültigem Zertifikat. Ein 301-Redirect auf die Impressumsseite Ihres Unternehmens genügt. Es darf weder «Connection refused» noch die Standardseite des Servers erscheinen.

Weitere Vorgaben der Provider

• Gmail (seit Februar 2024): PTR und passender A/AAAA-Eintrag sowie TLS für alle Absender. SPF oder DKIM für alle, SPF, DKIM und DMARC für Absender von mehr als 5000 Mails pro Tag an Gmail-Adressen.
• Outlook.com, Hotmail, Live (seit Mai 2025): Absender von mehr als 5000 Mails pro Tag brauchen bestandenes SPF und DKIM sowie DMARC mit mindestens p=none. PTR und HELO nennt Microsoft in diesen Anforderungen nicht. Das heisst nicht, dass sie keine Rolle spielen, nur dass sie dort nicht ausdrücklich gefordert sind.

Ohne SPF, DKIM und DMARC nützt eine saubere PTR-/HELO-Konfiguration wenig. Die Details dazu finden Sie in der DMARC-FAQ.

Besonderheit Plesk

Auf Plesk-Servern gehört main.cf nicht allein Ihnen. Zwei Punkte sind zu beachten:

• Hostname und HELO trennen: Der Systemhostname des Servers (unter dem z.B. das Plesk-Panel auf Port 8443 erreichbar ist) muss nicht der HELO-Name für ausgehende Mails sein. Ihn auf den Mail-Namen umzustellen, würde auch die Panel-Adresse ändern. Setzen Sie stattdessen smtp_helo_name gezielt auf den Namen, der zum PTR passt.
• Änderungen können überschrieben werden: Laut Plesk-Support werden manuelle Anpassungen in /etc/postfix/main.cf und master.cf unter anderem durch plesk repair mail, Plesk-Microupdates, Änderungen unter «Mail Server Settings» im Panel oder die Email-Security-Erweiterung zurückgesetzt.

Einen offiziell unterstützten Weg, Postfix-Einstellungen dauerhaft vor dem Überschreiben zu schützen (etwa eine eigene Vorlage wie bei Apache oder nginx), sehen wir in der Plesk-Dokumentation nicht. Plesk selbst nennt als Behelf, die Änderungen regelmässig per Cron erneut anzuwenden.

Automatische Prüfung per Cron

Weil ein Update die Einstellung unbemerkt zurücksetzen kann, lohnt sich eine tägliche Kontrolle. Das folgende Skript vergleicht den aktuellen Wert mit dem Sollwert und meldet eine Abweichung per Mail. Es ändert nichts selbst. Das ist Absicht: Eine automatische Korrektur würde auch eine später bewusst vorgenommene Änderung unbemerkt zurücksetzen. Nach einer Meldung entscheiden Sie von Hand, ob der Wert wieder gesetzt werden soll. Lassen Sie das Skript mehrmals täglich laufen, z.B. alle sechs Stunden, damit ein überschriebener Wert rasch auffällt:

# /etc/cron.d/check-helo
17 6,12,18 * * *  root  /usr/local/sbin/check-helo.sh

Das Skript:

#!/bin/bash
# /usr/local/sbin/check-helo.sh - run daily via cron, e.g. /etc/cron.d/check-helo
EXPECTED="mail.s1.example.com"
ALERT_TO="admin@example.com"

ACTUAL="$(postconf -h smtp_helo_name)"

# Empty value means Postfix falls back to $myhostname
if [ -z "$ACTUAL" ]; then
  ACTUAL="$(postconf -h myhostname)"
fi

if [ "$ACTUAL" != "$EXPECTED" ]; then
  echo "smtp_helo_name is '$ACTUAL', expected '$EXPECTED'" \
    | mail -s "HELO mismatch on $(hostname -f)" "$ALERT_TO"
fi

Selbst prüfen

Ersetzen Sie die Platzhalter durch Ihre Werte.

PTR der IPv4-Adresse:

dig -x 192.0.2.10 +short

Korrekt ist genau ein Hostname, nämlich Ihr HELO-Name (mail.s1.example.com.).

PTR der IPv6-Adresse:

dig -x 2001:db8::10 +short

Korrekt ist derselbe Hostname wie bei IPv4. Bleibt die Antwort leer, fehlt der IPv6-PTR.

A- und AAAA-Record des Hostnamens:

dig A mail.s1.example.com +short
dig AAAA mail.s1.example.com +short

Korrekt sind genau Ihre Server-IP-Adressen (192.0.2.10 bzw. 2001:db8::10).

Postfix-Konfiguration:

postconf smtp_helo_name myhostname

Korrekt ist, dass smtp_helo_name Ihren HELO-Namen zeigt. Ist er leer, gilt myhostname, und dieser muss dann der HELO-Name sein.

TLS und Zertifikat des Mailservers:

openssl s_client -starttls smtp -connect mail.s1.example.com:25

Korrekt ist ein erfolgreicher TLS-Aufbau mit einem Zertifikat, das den Hostnamen abdeckt und nicht abgelaufen ist (Verify return code: 0 (ok)).

Impressum über HTTP und HTTPS:

curl -I http://mail.s1.example.com
curl -I https://mail.s1.example.com

Korrekt ist eine Antwort mit 301 und einem Location-Header, der auf Ihre Impressumsseite zeigt. «Connection refused» oder die Standardseite des Servers genügen nicht.

Checkliste

Wir helfen Ihnen

Werden Ihre Mails abgewiesen oder landen im Spam, schauen wir uns die Konfiguration gerne mit Ihnen an. Auf unseren eigenen Servern sind PTR, A/AAAA, HELO und Zertifikate je Server auf einen gemeinsamen Mail-Namen abgestimmt, und ein Skript meldet uns mehrmals täglich, falls der HELO-Name nicht mehr dem Sollwert entspricht. Für Websites und Mailkonten, die auf Actra-Servern gehostet sind, sprechen wir mit Ihnen ab, was Sie für Ihr Setup brauchen. Mehr zu unserem Angebot finden Sie unter Webhosting. Kontaktieren Sie uns für eine unverbindliche Beratung.

Quellen

• Postmaster-Seite der Deutschen Telekom (T-Online)
• Google: Richtlinien für E-Mail-Absender
• Google: Gmail-Richtlinien für Absender (PTR, IPv6)
• Google: Gmail-SMTP-Fehlercodes
• Microsoft: Outlooks neue Anforderungen für Massenversender
• Plesk: Warum Änderungen an main.cf und master.cf zurückgesetzt werden