Reverse DNS und Mailserver und selbst generierte Zertifikate

Reverse DNS und Mailserver und selbst generierte Zertifikate

dies ist meine erste Frage hier, also bringen Sie mich nicht um, wenn sie dumm klingt.

Da ich nicht viel Ahnung von Serveradministration habe, haben wir zum Hosten unserer Kunden einen verwalteten Server gebucht.

Bisher haben wir das meiste eingerichtet, aber ich mache mir Sorgen um die Einrichtung des Mailservers.

Wir können den Reverse-DNS des Servers nicht ändern. Er verwendet einen generischen Namen wie xxx.IhrServer.com und ich befürchte, dass der generische Reverse-DNS-Server aufgrund seines schlechten Rufs zu E-Mail-Ablehnungen führen wird, da so viele Leute denselben Reverse-DNS verwenden.

Wir haben eine eigene dedizierte IP-Adresse und die Möglichkeit, weitere zu buchen.

Ich habe gesehen, dass einige Agenturen den Reverse-DNS in etwas wie isp.agencyname.com ändern und den Mailserver für Kunden auch wie folgt einrichten: mail.clientdomain.com

Ich frage mich, wie Hostname, Reverse-DNS und Mailserver tatsächlich zusammenarbeiten und wie man sie so einrichtet, dass sie harmonisch zusammenarbeiten.

Ich habe versucht, den Mailserver für Clientdomänen auf mail.clientdomain.com einzustellen, aber dann stimmten Hostname und Zertifikatsname nicht überein, da die beiden unterschiedlich sind. Außerdem verfügt Plesk über ein selbst generiertes Zertifikat von Rapid SSL für den Hostnamen. Kann ich es behalten oder muss ich ein eigenes Zertifikat kaufen, um eine zuverlässige E-Mail-Übertragung zu gewährleisten?

Wie kann ich für meine Kunden einen zuverlässigen Mailserver einrichten?

Vielen Dank für deine Hilfe

Antwort1

Auch ich zerbreche mir schon seit einiger Zeit den Kopf darüber. Anregungen und Korrekturen sind herzlich willkommen.

In den folgenden Beispielen beziehe ich mich auf xxx.yourdomain.comals hostname.yourdomain.com. Denn der PTR (Reverse DNS Record) sollte auf den Hostnamen auf jedem Host verweisen, unabhängig davon, ob auf dem Host ein Mailserver läuft.

Vorwärtszone yourdomain.com:

yourdomain.com.   IN    MX    hostname
hostname          IN    A     1.2.3.4

Der MXEintrag sollte auf den Host verweisen, der E-Mails für bereitstellt yourdomain.com. In Ihrem Fall ist dies wahrscheinlich ein Zeiger auf sich selbst, wenn Sie E-Mails über den auf diesem Host laufenden Mailserver bereitstellen. Der Hostname muss auf einen Aoder AAAAEintrag verweisen. Der Host, auf den MXverweist, muss immer ein Aoder AAAAEintrag sein und niemals ein Alias ​​mit CNAME.

Der Reverse-DNS-Eintrag sollte auf Ihren Hostnamen verweisen.

1.2.3.4    -->    hostname.yourdomain.com.

Vorwärtszone clientdomain.com:

clientdomain.com.   IN    MX     hostname.yourdomain.com.
mail                IN    CNAME  hostname.yourdomain.com.

Der MXEintrag sollte auf den Hostnamen Ihres Servers verweisen, der E-Mails bereitstellt clientdomain.com. Die Subdomäne maildient hier lediglich als Alias ​​für Ihren Mailserver-Host.

Der auf dem Host laufende Mailserver hostname.yourdomain.comsollte sich im SMTP-Dialog immer mit seinem Hostnamen bekannt geben. Viele Mailserver führen eine umgekehrte DNS-Suche durch und prüfen, ob die IP-Adresse auf denselben Hostnamen verweist, der von Ihrem Mailserver bekannt gegeben wurde.

Grundsätzlich reicht es aus, ein Mailserver-Zertifikat mit hostname.yourdomain.comdem CNNamen zu haben. Wenn Sie aber möchten, dass Ihre Clients auch über eine Verbindung zu Ihrem Mailserver herstellen können mail.clientdomain.com, muss diese Domain als im Zertifikat enthalten sein subjectAltName. Jede kommerzielle CA sollte dazu in der Lage sein. Als kostenlose Alternative können Sie verwendenLass uns verschlüsseln, wo Sie (zum Zeitpunkt des Schreibens) bis zu 100 SubjectAltNames pro Zertifikat verwenden können.

verwandte Informationen