Reverse DNS und Ihr Versandserver

Modul 5: Reputation und die großen Empfänger · Lesezeit: 9 Minuten

Lernziel: Nach dieser Lektion können Sie erklären, warum die IP-Adresse des Servers, der Ihre Mail versendet, eine saubere Reverse-DNS haben muss, feststellen, welcher Server das bei Ihnen ist, und kontrollieren, ob Hin- und Rückweg übereinstimmen.

Kernbegriffe: Versandserver, PTR-Record, forward-confirmed reverse DNS (FCrDNS), HELO/EHLO-Name, generischer Name, Shared Hosting, eigener Server (VPS), Eigentümer des IP-Blocks

Welcher Server versendet Ihre Mail eigentlich?

In Modul 4 ging es um Ihre Domain: SPF, DKIM und DMARC stehen in der DNS von example.com. In diesem Modul betrachten wir etwas anderes: den Server, der Ihre Mail beim Empfänger zustellt. Dieser Server hat eine IP-Adresse, und Empfänger beurteilen diese Adresse unabhängig von Ihrer Domain.

Welcher Server das ist, hängt davon ab, wie Sie mailen:

Die IP-Adresse des Versandservers finden Sie in den Headern einer Mail, die Sie an sich selbst oder an eine andere Adresse geschickt haben (Lektion 1.5). Sehen Sie sich die oberste Received:-Zeile an, die vom empfangenden Server hinzugefügt wurde. Darin steht etwas wie:

Received: from smtp.hosting.example (smtp.hosting.example [192.0.2.25])
        by mx.example.net with ESMTPS id 4f2a...

Die Adresse in eckigen Klammern, 192.0.2.25, ist die IP-Adresse, mit der sich der versendende Server verbunden hat. Der Name davor (smtp.hosting.example) ist der Name, den der Empfänger zu dieser Adresse per Reverse DNS gefunden hat.

Reverse DNS im Kurzüberblick

Reverse DNS verknüpft eine IP-Adresse zurück mit einem Namen, mit einem PTR-Record. Die Grundlagen haben Sie im DNS-Kurs gelernt (Lektion 4.6): Der Record steht nicht in der Zone Ihrer Domain, sondern in der Reverse-Zone der IP-Adresse, und die gehört der Partei, die den IP-Block verwaltet.

Für E-Mail sind drei Dinge wichtig:

1. Es gibt eine PTR. Eine IP-Adresse ohne Reverse DNS wirkt wie eine beliebige Maschine im Internet. Gmail lehnt solche Mail ab mit der Meldung 550 5.7.25 ... the sending IP address doesn't have a PTR record.
2. Der Name verweist zurück auf dieselbe Adresse. Die IP-Adresse 192.0.2.25 hat PTR smtp.hosting.example, und smtp.hosting.example hat A-Record 192.0.2.25. Das nennt man forward-confirmed reverse DNS (FCrDNS). Gmail, Yahoo und T-Online nennen dies ausdrücklich in ihren Anforderungen.
3. Der Name sieht wie ein Mailserver aus. Ein Name wie 192-0-2-25.dsl.provider.example oder host25.dynamic.provider.example verrät einen Heim- oder Kundenanschluss. Spamfilter geben dafür Minuspunkte oder lehnen die Verbindung sofort ab.

Für IPv6 gilt alles erneut. Versendet ein Server über IPv6, muss auch die IPv6-Adresse eine PTR haben und mit einem AAAA-Record zurückverweisen. Ein Server, der über IPv4 einwandfrei ist, aber über IPv6 nicht, bekommt vor allem bei Gmail Probleme: Google nennt eine fehlende IPv6-PTR als Ursache für einen "IPv6 authorization error".

Der HELO-Name

Wenn sich ein Server verbindet, stellt er sich mit EHLO (oder dem älteren HELO) und einem Namen vor (Lektion 1.2). RFC 5321 besagt, dass dies der vollständige Name des Servers sein sollte. In der Praxis prüfen Empfänger, ob dieser Name:

• ein echter, existierender Name ist (kein localhost, keine nackten IP-Adressen, kein Name, der nicht in der DNS steht);
• zur Reverse DNS passt oder zumindest zur selben Domain gehört.

Bei einem Hostingpaket oder Maildienst regelt der Anbieter dies. Betreiben Sie selbst einen Mailserver, stellen Sie den HELO-Namen in Ihrer Mailsoftware ein (in Postfix heißt das myhostname) und sorgen Sie dafür, dass dieser Name, die PTR und der A-Record alle übereinstimmen.

Shared Hosting: die PTR muss nicht Ihre Domain sein

Eine häufig gestellte Frage: "Muss die Reverse DNS nicht mail.example.com sein, das ist doch meine Domain?" Nein. Bei Shared Hosting und bei großen Maildiensten versendet ein einziger Server Mail für Hunderte oder Tausende Domains. Die IP-Adresse kann nur eine PTR haben, und die enthält also den Namen des Servers selbst, zum Beispiel server12.hosting.example.

Das ist so gewollt. Empfänger prüfen, ob die PTR existiert, zurückverweist und nicht generisch ist. Sie prüfen nicht, ob Ihr eigener Domainname darin steht. Die Verknüpfung zwischen Ihrer Domain und dem Server stellen Sie mit SPF her (der Server steht in Ihrem SPF) und mit DKIM (der Server signiert im Namen Ihrer Domain).

Bei WebOké ist das zum Beispiel so geregelt: Die Server eines Hostingpakets haben eine Reverse DNS mit dem Namen des Servers selbst, unter webawere.nl, die ebenfalls zurückverweist. Bei anderen Hostinganbietern und Maildiensten funktioniert es auf dieselbe Weise, mit deren eigenen Servernamen.

Ein eigener Server: Was müssen Sie regeln?

Versenden Sie Mail direkt von einem eigenen Server, zum Beispiel einem VPS mit einem Webshop oder einem eigenen Mailserver, dann sind Sie selbst der Versender und müssen mehr regeln:

1. Wählen Sie einen Namen, zum Beispiel mail.example.com.
2. Erstellen Sie den A-Record (und AAAA-Record) dieses Namens zur IP-Adresse des Servers, in der DNS Ihrer Domain.
3. Beantragen Sie die PTR beim Anbieter des Servers. Meist gibt es im Kundenpanel ein Feld "Reverse DNS" oder "rDNS". Dort tragen Sie denselben Namen ein.
4. Stellen Sie den HELO-Namen Ihrer Mailsoftware auf denselben Namen ein.
5. Tragen Sie die IP-Adresse in Ihr SPF ein (ip4: und ip6:) und aktivieren Sie DKIM in Ihrer Mailsoftware.
6. Prüfen Sie, ob Port 25 ausgehend offen ist. Viele Anbieter schließen diesen standardmäßig, um Missbrauch zu verhindern; dann müssen Sie ihn öffnen lassen oder über ein Relay Ihres Anbieters oder einen Versanddienst versenden.

Ein Mailserver an einem gewöhnlichen Internetanschluss zu Hause oder im Büro ist fast immer eine schlechte Idee. Diese Adressen stehen oft auf Listen von "Endnutzeradressen" (wie der Policy Block List von Spamhaus, Lektion 5.2), die PTR können Sie meist nicht selbst wählen, und T-Online schreibt ausdrücklich vor, dass solche Systeme über ein Relay eines geeigneten Anbieters versenden müssen.

Kontrollieren

Mit einem Befehlsfenster (DNS-Kurs Lektion 8.2):

dig -x 192.0.2.25 +short
smtp.hosting.example.

dig A smtp.hosting.example +short
192.0.2.25

Kommt bei der zweiten Abfrage dieselbe Adresse zurück, stimmt FCrDNS. Bei IPv6 machen Sie dasselbe mit dig -x 2001:db8::25 und dig AAAA.

Sie können auch nachsehen, wie ein Empfänger es gesehen hat. In den Headern setzt der empfangende Server den gefundenen Namen in Klammern hinter from. Steht dort unknown, fand er keine PTR. Manche Server fügen auch eine eigene Prüfung hinzu, wie iprev=pass in der Zeile Authentication-Results: (RFC 8601).

Zusammenfassung

• Der Versandserver ist der Server, der Ihre Mail beim Empfänger zustellt. Empfänger beurteilen seine IP-Adresse unabhängig von Ihrer Domain.
• Diese IP-Adresse braucht eine PTR, die zur selben Adresse zurückverweist (FCrDNS), für IPv4 und IPv6, mit einem Namen, der nicht generisch ist.
• Der HELO-Name sollte ein existierender Name sein, der zur PTR passt.
• Bei Shared Hosting und Maildiensten steht der Name des Servers in der PTR, nicht Ihre Domain. Das ist so gewollt.
• Mit einem eigenen Server regeln Sie selbst Name, A/AAAA, PTR (über Ihren Anbieter), HELO, SPF und DKIM.

Quiz

Aufgabe

Aufgabe Z5.1: Der Versandserver Ihrer eigenen Domain. Senden Sie eine Mail von Ihrer eigenen Adresse an eine andere eigene Adresse (zum Beispiel eine Gmail- oder Outlook.com-Adresse) und öffnen Sie die Header. Suchen Sie die IP-Adresse des Servers, der die Mail zugestellt hat, den PTR-Namen dieser Adresse, und geben Sie an, ob der Name auf dieselbe Adresse zurückverweist (ja/nein). Haben Sie keine eigene Domain, verwenden Sie die IP-Adresse des Mailservers mx00.t-online.de. Das Programm fragt die PTR und den A/AAAA-Record live ab und vergleicht sie.

Weiterführende Lektüre

Die Schritte in diesen Artikeln gelten für die Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• E-Mails von Ihrem VPS versenden und Reverse DNS einrichten
• Kostenloser DNS-Kurs 4.6: Reverse DNS (PTR): vom Nummer zurück zum Namen
• So funktioniert der Versand von E-Mails (SMTP)
• RFC 5321 (SMTP), Abschnitt 4.1.1.1 über den EHLO-Namen; RFC 8601 über den Header Authentication-Results