Zum Hauptinhalt springen
Download

MX-Abfrage: wohin die Mail einer Domain wirklich geht

Alle MX-Einträge einer Domain, sortiert wie ein sendender Mailserver sie liest, mit IPs, Reverse-DNS und Blacklist-Status auf dem Mac.

Von Lucas Russo, Entwickler von SSHive · Aktualisiert am

SSHive kostenlos ladenAlle Netzwerk-Tools
Auch auf iPhone und iPad

Die App für iPhone und iPad gibt es auf Englisch, Französisch und Spanisch, nicht auf Deutsch; die Sprache stellen Sie in den Einstellungen der App ein. Die Mac-App ist auf Deutsch.

Mail kommt nicht mehr an, oder sie kommt auf dem falschen Server an. Als Erstes ist nicht zu klären, ob Ihre Firewall offen oder Ihr Postfach voll ist, sondern wohin das Internet Ihre Mail derzeit zugestellt sehen will. Diese Antwort steht an einer Stelle: in den MX-Records der Domain. Jeder sendende Mailserver der Welt fragt sie ab, bevor er auch nur eine SMTP-Verbindung öffnet, und wenn sie etwas sagen, das Sie nicht erwartet haben, ist alles dahinter egal. Die MX-Abfrage ist auch der Schritt, den man nach einer Migration überspringt. Sie ziehen eine Domain zu einem neuen Anbieter um, im Kundenportal sieht die Änderung richtig aus, und die Mail landet noch einen Tag lang im alten Postfach, weil die Records nie aktualisiert wurden oder weil eine veraltete Kopie weiterhin ausgeliefert wird. Eine Abfrage von dreißig Sekunden hätte es gezeigt. SSHive führt diese Abfrage selbst aus, auf Mac, iPhone und iPad. Es fragt die DNS-Resolver ab, die Ihr Gerät ohnehin verwendet: keine Web-API dazwischen, kein Konto, keine Werbung. Auf dem Mac hört es nicht bei der Record-Liste auf: Jeder Mailserver wird in seine IPv4-Adressen aufgelöst, jede Adresse rückwärts zu ihrem PTR-Namen, und die erste Adresse jedes Mailservers wird gegen acht DNSBL-Zonen geprüft. Sie bekommen den gesamten Mail-Rand einer Domain in einer Tabelle: wer empfängt, in welcher Reihenfolge, auf welchen Hosts, und ob diese Hosts ein Reputationsproblem mitbringen. Auf iPhone und iPad bekommen Sie die Record-Liste selbst, Priorität und Hostname des Mailservers, über den System-Resolver mit einer echten DNS-Abfrage vom Typ 15 geholt, was mehr ist, als die Standard-APIs von iOS hergeben. Es ist auf Mac, iPhone und iPad kostenlos, die Mac-App-Store-Version in der Sandbox eingeschlossen: Kein Netzwerkwerkzeug in SSHive liegt hinter der Pro-Sperre. Eine Grenze klar benannt: Das ist ein MX- und Reputationswerkzeug, keine vollständige Prüfung der Mail-Authentifizierung. SSHive untersucht weder SPF, DKIM, DMARC, MTA-STS noch TLS-RPT, holt keine SMTP-Banner und testet auf keiner Plattform Port 25.

Was SSHive dabei leistet

Prioritäten, in der Reihenfolge, in der SMTP sie liest

SSHive fragt die MX-Records der Domain ab und sortiert sie aufsteigend nach Präferenz, genau die Reihenfolge, in der ein sendender MTA sie durchgeht. Die kleinste Zahl wird zuerst versucht. Unter macOS ist das Ergebnis eine fünfspaltige Tabelle; auf iPhone und iPad trägt jede Zeile eine farbcodierte Prioritätskapsel: grün bis 10, orange bis 20, rot darüber.

Jeder Mailserver in seine Adressen aufgelöst

Unter macOS wird jeder MX-Hostname in seine IPv4-Adressen aufgelöst und kommagetrennt in der Spalte IP angezeigt. Ein Geviertstrich heißt, dass kein A-Record zurückkam: Entweder ist der Host reines IPv6, da SSHive hier IPv4 auflöst, oder der MX zeigt auf einen Namen, den es nicht mehr gibt. Beidem sollte man nachgehen.

Reverse DNS für jede Mailserver-IP

Die Spalte rDNS zeigt den PTR-Namen jeder aufgelösten Adresse. Sie verrät, wer den Host hinter einem hübschen MX-Hostnamen tatsächlich betreibt, und legt die generischen Provider-PTR-Namen offen, die empfangende Server bei ausgehender Mail gern abstrafen. Die Rückwärtsauflösung hat im Desktop-Panel keine eigene Karte: Sie erscheint in der MX-Tabelle.

Blacklist-Status direkt in der Zeile, acht Zonen

Unter macOS wird die erste IPv4 jedes Mailservers parallel gegen zen.spamhaus.org, b.barracudacentral.org, bl.spamcop.net, dnsbl.sorbs.net, bl.mailspike.net, dnsbl-1.uceprotect.net, psbl.surriel.com und all.s5h.net geprüft. Die Spalte zeigt eine grüne Plakette „Nicht gelistet“ oder eine rote Plakette „Auf Blacklist“, deren Tooltip genau die Zonen nennt, die die Adresse gemeldet haben.

Echte MX-Abfragen auf iPhone und iPad

iOS stellt nur die Auflösung von Namen zu Adressen bereit, getaddrinfo kann also nie einen MX-Record liefern. SSHive setzt über den BSD-Resolver eine echte Abfrage vom Typ 15 ab, parst den Answer-Abschnitt selbst und liest die 16-Bit-Präferenz direkt vom Draht. Sie bekommen Priorität und Hostname des Mailservers, bis zu 32 Records, mit einer Kopiertaste in jeder Zeile.

Auf jeder Plattform kostenlos, ohne Werbung

Die MX-Abfrage ist keine Pro-Funktion. Keines von SSHives Netzwerkwerkzeugen ist auf irgendeiner Plattform gesperrt: keine Kaufaufforderung im Werkzeug-Panel, keine Werbeeinblendung vor einer Abfrage, kein anzulegendes Konto. Pro, ein Einmalkauf als Universal Purchase für Mac, iPhone und iPad, brauchen Sie für mehr als 2 gleichzeitige SSH-Sitzungen oder 5 gespeicherte Profile, für Remote-Tunnel und für RDP und VNC.

So gehen Sie vor, Schritt für Schritt

  1. 1

    Das Netzwerkwerkzeug-Panel auf dem Mac öffnen

    Klicken Sie in der Mac-App auf das Netzwerksymbol in der Seitenleiste oder auf die Schaltfläche Netzwerkwerkzeuge im Willkommensbildschirm. Beides öffnet einen Tab Netzwerkwerkzeuge. Eine SSH-Sitzung oder eine bestehende Verbindung ist dafür nicht nötig.

  2. 2

    Die Domain in die Karte MX-Abfrage eingeben

    Auf dem Mac ist MX-Abfrage die dritte Karte des Abschnitts Auflösung und Reputation, nach DNS-Lookup und DNSBL-Prüfung. Tippen Sie die Apex-Domain ein, keinen Hostnamen (example.com, nicht mail.example.com), und klicken Sie auf „MX-Einträge abfragen“. Der Platzhaltertext des Feldes zeigt das erwartete Format.

  3. 3

    Die fünf Spalten lesen

    Die Ergebnisse kommen als Priorität, MX-Server, IP, rDNS und DNSBL zurück, aufsteigend nach Priorität sortiert. Fahren Sie über eine rote Plakette „Auf Blacklist“, um genau zu sehen, welche Zonen die Adresse gemeldet haben; eine grüne Plakette „Nicht gelistet“ heißt, dass keine der acht Zonen eine 127.x-Antwort geliefert hat.

  4. 4

    Auf iPhone oder iPad: Tools, dann Email & IP

    Tippen Sie auf dem iPhone unten in der Tableiste auf Tools oder auf dem iPad in der Seitenleiste auf Network tools, dann auf MX Lookup, die erste Zeile im Abschnitt Email & IP. Geben Sie die Domain ein und führen Sie die Abfrage aus. Jede Zeile zeigt eine farbcodierte Prioritätskapsel und den Hostnamen des Mailservers in dicktengleicher Schrift. Die Bezeichnungen sind die der englischen Oberfläche der App.

  5. 5

    Mobil in Blacklist Check weiterreichen

    Für das Ergebnis Zone für Zone auf iPhone oder iPad tippen Sie auf die Kopiertaste einer Mailserver-Zeile, öffnen im selben Abschnitt Email & IP den Blacklist Check und fügen den Hostnamen ein: Er löst den Namen selbst in seine erste IPv4 auf und prüft dann zehn DNSBL-Zonen.

Wie man eine MX-Tabelle wirklich liest

Die Prioritätszahl ist eine Präferenz, keine Qualitätsnote, und ihr absoluter Wert bedeutet nichts. 5/10/20 und 1/2/3 beschreiben exakt dasselbe Routing. Nur die Reihenfolge zählt: Ein sendender MTA sortiert aufsteigend und versucht die kleinste zuerst, und geht erst zur nächsten über, wenn die Verbindung scheitert. Zwischen zwei Records mit derselben Zahl wird zufällig gewählt: So funktioniert Lastverteilung auf MX-Ebene. Damit ist der Record mit der höchsten Zahl der, den man am genauesten ansehen sollte. Ein Backup-MX ist eine klassische Schwachstelle: Er ist oft älter, weniger gefiltert und weniger überwacht als der primäre, und Spam-Versender zielen genau deshalb bewusst darauf. Wenn Ihre Tabelle ein Backup bei einem anderen Anbieter als dem primären zeigt, prüfen Sie, ob es dort noch stehen soll. Ein leeres Ergebnis ist nicht zwangsläufig ein Fehler. Es gibt zwei legitime Fälle. Priorität 0 mit einem einzelnen Punkt als Mailserver ist ein Null-MX (RFC 7505): Die Domain erklärt, überhaupt keine Mail zu empfangen, was für eine reine Website-Domain richtig ist. Und eine Domain ohne MX-Records ist nicht unerreichbar: SMTP fällt nach der Regel des impliziten MX in RFC 5321 auf den A- oder AAAA-Record der Domain selbst zurück. Mail wird dann an Ihren Webserver versucht, was selten die Absicht ist, aber es ist kein Schweigen. Ein Geviertstrich in der Spalte IP heißt, dass der Mailserver keinen A-Record geliefert hat. SSHive löst hier IPv4 auf, ein reiner IPv6-Mailserver erscheint also leer; führen Sie DNS Lookup auf dem Hostnamen des Mailservers aus und prüfen Sie auf ein AAAA, bevor Sie es für kaputt erklären. Dieselbe Prüfung findet die andere klassische Fehlkonfiguration: einen MX, der auf einen CNAME zeigt, was RFC 2181 und RFC 5321 verbieten und was manche MTAs rundheraus ablehnen. Und schließlich: Ein DNSBL-Treffer auf einem eingehenden MX hindert Sie nicht am Empfang. Sein Wert liegt darin, dass in den meisten kleinen Installationen derselbe Host auch sendet, und ein Eintrag auf zen.spamhaus.org, von einem sehr großen Teil der Empfänger abgefragt, ist ein deutlich größeres Problem als einer auf dnsbl-1.uceprotect.net, das ganze Netzblöcke aggressiv listet und von weit weniger Servern abgefragt wird. Lesen Sie die Zone, nicht die Anzahl.

Häufige Fragen

Was bedeutet die MX-Prioritätszahl eigentlich?+
Es ist ein Präferenzwert, und nur die Reihenfolge zählt. Ein sendender Mailserver sortiert die Records aufsteigend und versucht die kleinste Zahl zuerst, und geht erst zur nächsten über, wenn die Verbindung scheitert. 5/10/20 und 1/2/3 beschreiben identisches Routing. Records mit derselben Zahl werden zufällig ausgewählt, so funktioniert Lastverteilung auf MX-Ebene. Die Zahl ist keine Qualitätsbewertung und trägt keine Einheit.
Meine Domain liefert keine MX-Records. Ist die Mail kaputt?+
Nicht zwangsläufig. Hat eine Domain überhaupt keinen MX-Record, fällt SMTP nach der Regel des impliziten MX in RFC 5321 auf den eigenen A- oder AAAA-Record der Domain zurück. Mail wird dann an das versucht, was Ihr Webserver ist, was meist eine Fehlkonfiguration, aber kein Schweigen ist. Der andere legitime Fall ist ein Null-MX: ein einzelner Record mit Priorität 0 und einem einsamen Punkt als Mailserver, der nach RFC 7505 erklärt, dass die Domain keine Mail empfängt, und Absender sofort zurückweisen lässt.
Funktioniert MX Lookup auf iPhone und iPad?+
Ja, auf beiden, und kostenlos. Die mobile Version ist allerdings schmaler als die des Mac: Sie liefert Priorität und Hostname des Mailservers, ohne IP-Spalte und ohne Reverse DNS, die es nur auf dem Mac gibt. Der mobile Parser hört außerdem bei 32 Records auf. Für die Reputation eines mobilen Ergebnisses Zone für Zone kopieren Sie den Hostnamen in das separate Werkzeug Blacklist Check.
Ist MX Lookup in der Mac-App-Store-Version verfügbar?+
Ja, mit allen Spalten und allen DNSBL-Zonen. MX Lookup ist schlichtes DNS über den System-Resolver, es braucht also keine Raw-Sockets und die App Sandbox schränkt es nicht ein. Im Werkzeug-Panel ist dort nichts eingeschränkt: Ping und Traceroute senden auch aus der App-Store-Version echtes ICMP, über einen Datagramm-Socket, der keine Privilegien braucht.
Prüft SSHive SPF, DKIM oder DMARC?+
Nein. Es gibt auf keiner Plattform eine Prüfung von SPF, DKIM, DMARC, MTA-STS oder TLS-RPT, kein Abgreifen von SMTP-Bannern und keinen Verbindungstest auf Port 25. Was Sie tun können, ist die rohen Records zu lesen: SPF wird als TXT-Record am Domain-Apex veröffentlicht, und die Karte DNS-Lookup auf dem Mac liefert TXT neben A, AAAA, MX, CNAME und NS. SSHive zeigt Ihnen diese Zeichenkette; es parst und validiert sie nicht. DMARC-Richtlinien liegen unter dem separaten Namen _dmarc.
Warum ist die IP-Spalte bei einem meiner Mailserver leer?+
Das Desktop-MX-Lookup löst Mailserver nur nach IPv4 auf, ein reiner IPv6-Mailserver hat also nichts zu zeigen und erscheint in den Spalten IP und rDNS als Geviertstrich und wird nie auf Blacklists geprüft, da auch die DNSBL-Engine nur IPv4 kann. Die andere Erklärung ist schlimmer: Der MX zeigt auf einen Hostnamen ohne jeden Adress-Record. Führen Sie DNS Lookup auf diesem Mailserver aus, um die beiden auseinanderzuhalten. Kommt ein AAAA-Record zurück, ist es der erste Fall.
Kann ich einem Ergebnis „Nicht gelistet“ trauen?+
Größtenteils ja, mit einem Vorbehalt, den man kennen sollte. Mehrere DNSBL-Betreiber, Spamhaus insbesondere, weisen Abfragen ab, die von großen öffentlichen Resolvern kommen, und antworten mit einem Fehler oder einem pauschalen Rückgabecode. Der Mac zählt jede Antwort, die mit 127. beginnt, als gelistet, und alles andere, einen DNS-Fehler eingeschlossen, als nicht gelistet, auf einem öffentlichen Resolver können Sie dort also beide Richtungen in die Irre führen: Spamhaus weist diese Abfragen mit einem 127.255.255.x-Code ab, was sich als „Auf Blacklist“ liest, obwohl nichts gelistet ist, während eine Zone, die mit einem klaren Fehler antwortet, als sauber erscheint, auch wenn sie Sie sehr wohl listet. iPhone und iPad führen beide Fälle getrennt, als unbestimmt, statt sie in die eine oder andere Richtung zu zählen. Wenn ein Ergebnis zählt, bestätigen Sie es über den Resolver Ihres Providers oder einen eigenen Web-Checker, bevor Sie danach handeln.

MX auf dem Draht, und was es braucht, um es vom iPhone aus abzufragen

Ein MX-Record ist einer der einfachsten Resource Records im DNS und einer der folgenreichsten. Typ 15, Klasse IN, und ein RDATA-Abschnitt mit genau zwei Teilen: einer 16-Bit-Präferenz in Netzwerk-Byte-Reihenfolge, gefolgt von einem Domainnamen für den Mailserver. Dieser Name unterliegt der DNS-Namenskomprimierung, er wird also häufig als Zeiger auf eine frühere Stelle der Nachricht gespeichert statt als wörtliche Zeichenkette, weshalb man eine MX-Antwort nicht lesen kann, indem man das Paket als Text behandelt. RFC 5321 Abschnitt 5.1 definiert, was ein sendender MTA mit der Menge macht. Er fragt MX für die Empfängerdomain ab, sortiert die Ergebnisse aufsteigend nach Präferenz, löst jeden Mailserver in Adress-Records auf und versucht die Zustellung in dieser Reihenfolge, wobei er zwischen Records mit gleichem Präferenzwert zufällig wählt. Liefert die MX-Abfrage nichts, fällt der Absender auf die Adress-Records der Domain selbst zurück: die Regel des impliziten MX. Liefert sie einen einzelnen Record mit Präferenz 0 und einem einsamen Punkt als Mailserver, sagt RFC 7505, dass die Domain keine Mail annimmt und der Absender sofort zurückweisen muss, statt fünf Tage lang zu wiederholen. Der Mailserver muss ein Hostname mit Adress-Records sein; er darf kein CNAME und kein Adressliteral sein. Diese Antwort unter macOS zu bekommen, ist unkompliziert. SSHive nutzt den auf c-ares beruhenden Resolver von Node, der DNS direkt mit den Servern spricht, die Ihr Betriebssystem konfiguriert hat, statt über getaddrinfo zu gehen. resolveMx liefert die Menge, aufsteigend sortiert. Jeder Mailserver geht dann an resolve4, jede daraus entstandene Adresse an eine PTR-Abfrage, und die erste Adresse jedes Mailservers an die DNSBL-Engine, die alle acht Zonen parallel auffächert. Jeder Anreicherungsschritt hat eigene Fehlerbehandlung, ein Mailserver ohne PTR-Record oder ohne A-Record verschlechtert sich also zu einem Geviertstrich, statt die ganze Abfrage scheitern zu lassen. Nichts davon braucht einen Raw-Socket, weshalb sich MX Lookup in der Mac-App-Store-Version identisch verhält. iOS ist das schwierigere Problem. Apples High-Level-Netzwerk gibt Ihnen die Auflösung von Namen zu Adressen und sonst nichts: getaddrinfo und NWEndpoint liefern A- und AAAA-Records, und es gibt keine öffentliche Swift-API für einen beliebigen Record-Typ. Um MX zu lesen (und, da derselbe Helfer verallgemeinert wurde, jeden anderen Record-Typ, den der DNS-Lookup-Bildschirm inzwischen zeigt), steigt SSHive über einen kleinen C-Helfer zum BSD-Resolver in libresolv hinab: res_init, dann res_query mit Klasse C_IN und Typ T_MX für die Rohantwort, dann ns_initparse und ns_parserr über den Answer-Abschnitt, wobei die Präferenz big-endian aus den ersten beiden RDATA-Bytes gelesen und der komprimierte Mailserver-Name mit dn_expand entpackt wird. Swift sortiert das Ergebnis nach Präferenz und übergibt es der Ansicht. Keine Resolver-Bibliothek eines Dritten, keine Web-API auf dem Weg: Die Abfrage geht von Ihrem Gerät zu den Resolvern, die es ohnehin verwendet. Die Kosten sind ehrliche. Die Abfrage nutzt die Resolver-Konfiguration des Systems: Ein Captive Portal oder ein DNS64/NAT64-Netz, das Typ 15 falsch behandelt, lässt res_query scheitern, und die App meldet dann keine MX-Records statt eines Netzwerkfehlers. Der Parser hört bei 32 Records auf. Und auf allen Plattformen gibt es kein Feld für einen eigenen Nameserver, keine TTL-Anzeige und keine Prüfung von SPF, DKIM, DMARC, MTA-STS oder TLS-RPT.

Verwandte Tools

DNSBL-Prüfung

DNS-Abfrage

Whois

Ping

Traceroute