mx.ip_literal
MX-Eintrag zeigt auf IP-Adresse
Was wir prüfen
Wir untersuchen jedes MX-Ziel darauf, ob es ein Hostname oder ein IP-Adressliteral ist (z. B. [192.0.2.1]). RFC 5321 §5.1 verlangt, dass MX-Ziele Domainnamen sind, keine IP-Adressen.
Was dieses Ergebnis bedeutet
Mindestens ein MX-Eintrag zeigt auf ein IP-Adressliteral statt auf einen Hostnamen. Manche sendende Server versuchen trotzdem die Zustellung an die Literal-Adresse, aber das verstößt gegen die MX-Spezifikation und bricht Funktionen, die auf Hostnamen-Verifikation angewiesen sind: TLS-Zertifikatsabgleich, MTA-STS-Durchsetzung und DANE/TLSA-Abfragen erfordern alle einen Hostnamen.
Warum das wichtig ist
- RFC-Verstoß. MX-RDATA muss ein Hostname sein (RFC 5321 §5.1). Ein IP-Literal ist technisch ungültig und wird von strikten Implementierungen möglicherweise abgelehnt.
- Keine TLS-Verifikation möglich. TLS-Zertifikate werden auf Hostnamen ausgestellt; ein IP-Literal kann im Standard-SMTP-STARTTLS-Ablauf nicht gegen Subject oder SAN-Feld eines Zertifikats geprüft werden.
- Kein DANE oder MTA-STS. Beide Mechanismen basieren auf Hostnamen — sie können Verbindungen zu IP-Literalen nicht schützen.
- Kein PTR/FCrDNS-Kontext. Reverse-DNS-Prüfungen gegen MX-Ziele sind sinnlos, wenn das Ziel bereits eine nackte IP ist.
So behebst du das
Ersetze das IP-Literal durch einen Hostnamen, der zur selben Adresse auflöst:
; Vorher (falsch) example.com. IN MX 10 [192.0.2.1] ; Nachher (richtig) example.com. IN MX 10 mail.example.com.Stelle sicher, dass der Hostname A/AAAA-Einträge hat, die auf den Mailserver zeigen:
dig +short A mail.example.com # Erwartet: 192.0.2.1
So fließt es in die Bewertung ein
Ein MX-Ziel als IP-Literal kostet 20 Punkte in der MX-Kategorie. Das vollständige Scoring-Modell steht in der Bewertungsmethodik.
Evidenzbeispiel
$ dig +short MX example.com
10 [192.0.2.1]
MX-Ziel ist ein IP-Adressliteral, kein Hostname