MX Record - Verständnisfrage (best Practices)

[httPete]

Hallo zusammen,

ich habe mal eine Vertsändnisfrage bzw. eine Überlegung zum MX Eintrag was hier "best Practices" ist. Ich möchte meine vorhandenen zwei Linux V-Server neu aufteilen und nutze für die Verwaltung Plesk und einen externen DNS Server. Auf den neuen Linux Servern / in Plesk ist der DNS Server deaktiviert.

Sollte der MX Eintrag einer Domain immer auf den "Hostnamen" und somit auch dem Reverse DNS Eintrag des Servers gleichen (DNS Konfiguration Beispiel 1), oder kann jede Domain einen MX Eintrag besitzen, der auf eine Subdomain (innerhalb der Domain) mit entsprechendem A-Record zum Mailserver verweist (DNS Konfiguration Beispiel 2)?:

Beispiel 1

DNS Hauptdomain (Serververwaltung)

A-Record	host1.meine-domain.tld	IP Adresse Host 1
A-Record	host2.meine-domain.tld	IP Adresse Host 2

DNS Kundendomain

A-Record	domain-kunde.tld	IP Adresse Host 1
MX Record	domain-kunde.tld	host1.meine-domain.tld

Beispiel 2
DNS Kundendomain

A-Record	domain-kunde.tld	IP Adresse Host 1
A-Record	mail.domain-kunde.tld	IP Adresse Host 1
MX-Record:	domain-kunde.tld	mail.domain-kunde.tld

Auf den alten Servern mit aktivierten DNS Server in Plesk, wurden die DNS Einträge für die MX Records der Domains, aus dem DNS Zonen-Template von Plesk, immer wie in Beispiel 2 agelegt. Da ich die DNS Zonen nun extern verwalte kam mir halt die Überlegung wie ich es nun korrekt anlegen sollte?!

Welche Vor- und Nachteile ergeben die jeweilige Konfigurationen oder kann eine der Konfigurationen sogar zu Problemen führen?

 

[greystone]

Beispiel 2 ist wesentlich aufwändiger als Beispiel 1, weil Du dort ein Multidomain-Zertifikat mit alle Kundendomains benötigen würdest ohne irgend einen Gewinn. Diesen Fall kenne ich nur aus der Zeit, in der Mails auch noch unverschlüsselt angenommen wurden und kein SSL-Zertifikat benötigt wurde.

Im ersteren Fall wird das Zertifikat nur für host1.meine-domain.tld benötigt. Ich würde auf jeden Fall gemäß Beispiel 1 umsetzen.

 

[httPete]

@greystone Danke für deine Antwort. Okay, nach deiner Aussage muss ich meine bisherige Konfiguration doch mal ein wenig genauer durchleuchten.

Wie ich bereits geschrieben habe, verwalte ich meine V-Server mit Plesk. Hier lege ich die Domains der Kunden an und richte die Webpakete gemäß den Anforderungen der Kunden ein. Per Let's Encrypt Erweiterung erstelle ich dann ein kostenloses SSL Zertifikat für die Domain.

Für die Einrichtung der E-Mail Clients (Eingangs- und Ausgangsserver) auf Mobilgeräten, PCs und Laptop, haben sich meine Kunden bisher über eine meiner "Hauptdomains" (Beispiel 1: meine-domain.tld) am Mailserver angemeldet. Das möchte ich aber ändern, so dass jeder Kunde bei der Einrichtung der Clients, seine eigene Domain verwendet. Dafür muss für jede Domain des Kunden ja eh ein gültiges SSL-Zertifikat hinterlegt sein.

Wenn jeder Kunde seine eigene Domain nutzt, bin ich flexibler sobald ein Kunde mal auf einen anderen Server migriert werden soll. Ich habe bisher keine Mail-Cluster im Einsatz, sondern einzelen Server auf denen die Kunden verteilt sind.

Oder übersehe ich was?

 

[Thunderbyte]

Da der Reverse DNS Eintrag für eine IP nur ein FQDN sein kann, geht bei mehreren gehosteten Domains auf einem Mailserver nur Beispiel 1.

Es muss auflösungstechnisch gelten:
MX Record: host1.meine-domain.tld -> IP Adresse Host 1
UND ZUDEM REVERSE:
IP Adresse Host 1 -> host1.meine-domain.tld

Das geht für verschiedene Domains auf einem Mailserver nur, wenn für alle der gleiche MX Record (muss ein FQDN, keine IP Adresse sein) verwendet wird.

 

[Firewire2002]

Das ist nicht ganz korrekt. Der PTR ist für den eingehenden Mailverkehr (ausschließlich dafür ist der MX Record da) irrelevant.
Der MX muss auf einen A Record zeigen, der wiederum auf die IP des Mailservers zeigen muss. Wie der A Record dazwischen heißt und in welcher Zone er sich befindet ist völlig egal. Allenfalls wenn Zertifikate streng geprüft werden, greift greystone's Anmerkung zusätzlich. Die Erfahrungen zeigen allerdings, dass die meisten Mailserver das Zertifikat überhaupt nicht validieren.

Der PTR ist ausschließlich beim ausgehenden Mailverkehr relevant. Hier gilt gemäß RFC, die IP muss über einen PTR verfügen, der auf einen Namen zeigt, dessen A Record die identische IP zurück liefert. (1:1 Mapping PTR + A Record).
Für die Spamfilter dieser Welt ist es ratsam, den HELO der Mailservers (Anmerkung: wieder nur ausgehender Mailverkehrt relevant) mit dem PTR identisch zu halten. Viele prüfen darauf. Es gibt laut RFC aber keinen Zwang dazu.

Der PTR muss aber in keinsterweise mit dem A Record im MX zusammenpassen. Es gibt ja auch noch die Möglichkeit, auf den MX komplett zu verzichten, wenn der A Record der genutzten Domain in den E-Mail Adressen auf die gleiche IP des Mailservers zeigen würde. Nicht empfehlenswert. Aber SMTP sieht das so als Fallback vor, wenn kein MX Record existiert.

 

[Joe User]

Für die Spamfilter dieser Welt ist es ratsam, den HELO der Mailservers (Anmerkung: wieder nur ausgehender Mailverkehrt relevant) mit dem PTR identisch zu halten. Viele prüfen darauf.

Welche sollen das sein? Ich kenne keinen Einzigen...


Der ganze Rest stimmt

 

[httPete]

Hallo zusammen,

vielen Dank für eure Antworten. Ich hatte mir zu dem parallel Thema auch noch mal einiges durchgelesen und auch noch mal die Doku von Plesk dazu durchforstet. Beide Varianten sind also problemlos umsetzbar.

Danke für euren Support!

 

[greystone]

Um es nochmal zusammenzufassen:

Also wenn ich möchte, dass ich wenig Probleme habe mit Spamfiltern und anderen Mailservern und Aufwand haben möchte, dann wähle ich Variante 1. Wenn ich auf überflüssige Arbeit und jeder Menge Ärger mit anderen MTAs will, dann nehme ich Variante 2.

 

[httPete]

Mich wundert die Antwort jetzt wieder etwas. Denn wenn ich mir die Plesk Doku und das Standard DNS Template von Plesk ansehe, wird die DNS Zone für eine Domain genau wie in Variante 2 angelegt. Nun habe ich seit einigen Tagen testweise mal ein Mailkonto auf einer Testdomain aktiv, welches genau wie Variante 2 konfiguriert ist. Wenn ich bei MXTools allerlei DNS Abfragen mache, erhalte ich keinerlei Fehler Ausgaben. Auch ein E-Mail Test unter mail-tester.com oder experte.de gibt keinerlei Fehler zurück, sondern einen Score 10 von 10.

Das verwirrt mich alles jetzt wieder ein bisschen.

 

[Joe User]

Mich wundert die Antwort jetzt wieder etwas.

Mich auch, da beide Varianten gleichwertig, korrekt und "quasi Standard" sind.

 

[Firewire2002]

Welche sollen das sein? Ich kenne keinen Einzigen...

Sei froh.
Mit "viele" meinte ich das aber schon relativ. Also nicht im Sinne von "die meisten", sondern mehr als eine Hand voll. Auch wenn das gemessen an der Gesamtanzahl immer noch ein kleiner Prozentsatz sein sollte. Da liegen mir keine belastbaren Zahlen vor. Ich bitte die Ungenauigkeit zu entschuldigen.

Im Berufsalltag hatten wir einige Kunden-Setups die genau das unbedingt machen wollten. Namen darf ich hier natürlich nicht nennen. Einige haben es hart abglehnt, andere nur in ein Spam-Scoring einfließen lassen.
Vor vielen Jahren (sicher 10-15 Jahre her), war da auch ein großer Hersteller von Antispam-Lösungen dabei. Ich kann nicht mehr mit Gewissheit sagen, ob es Cloudmark oder das damalige Produkt von Baracuda Networks war. Aktuelle Infos liegen mir dazu aber keine vor.

Wenn man sich die HELOs und PTRs der anderen großen Mailhoster anschaut, dann folgen die sehr oft ebenfalls dem Grundprinzip, dass HELO und PTR zusammenpassen. Ob die das nun aus dem gleichen Grund machen oder weil man als Admin sich das Leben einfacher macht, weil weniger unterschiedliche Namen zum gleichen Event im Log auftauchen, weiß ich nicht.

Die RFC erzwingt es nicht. Am Ende muss es der Admin entscheiden ob er der "Tradition" folgt. Ich für meinen Teil mache es. Das dürfte in den wenigsten Fällen ein Mehraufwand bedeuten.

 

[Joe User]

Wenn man sich die HELOs und PTRs der anderen großen Mailhoster anschaut, dann folgen die sehr oft ebenfalls dem Grundprinzip, dass HELO und PTR zusammenpassen.

Ja, das liegt aber daran, dass dort die Hosts ausschliesslich als MX fungieren und es somit sinnvoll (im Sinne der Datensparsamkeit) ist, für PTR, Hostname und HELO den gleichen FQDN zu verwenden.
Soetwas macht grundsätzlich nur bei Single-Purpose-Systemen Sinn, aber niemals bei Multi-Purpose-Systemen...

Vor vielen Jahren (sicher 10-15 Jahre her), war da auch ein großer Hersteller von Antispam-Lösungen dabei. Ich kann nicht mehr mit Gewissheit sagen, ob es Cloudmark oder das damalige Produkt von Baracuda Networks war.

Nichtmal das, es war mxtoolbox https://www.rootforum.org/forum/viewtopic.php?t=54479

 

[greystone]

Die Erfahrungen zeigen allerdings, dass die meisten Mailserver das Zertifikat überhaupt nicht validieren.

Kannst Du da irgend etwas quantitatives zu sagen? D. h. wie viele Mailserver da Zertifikate nicht validieren? Ich selbst habe da nur einzelne Erfahrungen, wenn sich halt Kunden beschweren, das mal Mails wegen einer alten SSL Version abgelehnt wurden. Selbst wenn die Hälfte aller Mailserver das SSL nicht ordentlich prüfen, würde das für mich nix bedeuten.

Ansonsten ist da Version 2 natürlich nicht zu beanstanden, wenn man sich den Käse mit dem Multidomain-Zertifikat geben will. Gleichzeitig schätze ich Plesk so ein, dass es das nicht korrekt automatisch so konfiguriert.

 

[Firewire2002]

Ich habe da nie eine statistische Erfassung gemacht. Sehe es im Alltag nur immer wieder in den Konfigurationen oder halt am Namen der Zertifikate, dass das sehr oft nie passen kann, aber es trotzdem keine Probleme gibt. Bis vor 2 Jahren hatte ich auch an meinem eigenen privaten Mailserver bewusst nur ein Snake Oil Cert drin. Alle anderen haben trotzdem brav mit STARTTLS eingeliefert.
Ich bezieh mich hier aber wirklich nur auf die Namen im Zertifikat (SAN+CN) und die ausgebende Stelle.

SSL/TLS Versionen und Cipher machen deutlich mehr Probleme, insbesondere in Kombination modernes System mit uraltem Kommunikationspartner. Man kann es sich leider nicht immer aussuchen, wer einem Mails schicken muss.

Edit:
Brauch man ja eigentlich nur mal wieder einen MTA mit Snake Oil Cert ins Netz stellen und von unterschiedlichen Quellen mal paar Mails hinschicken. Ich würd drauf wetten, das meiste (auch von den großen Mailhostern) kommt nach wie vor an.
Klassische Mailclients sind da übrigens empfindlicher. Die prüfen das Cert schon. Nur in der MTA zu MTA Kommunikation ist das oft Nebensache.