MX-Lookup:
antwortet Ihr Mailserver?

Geben Sie oben Ihre Domain ein. Wir fragen ihre MX-Einträge ab, sortieren sie nach Priorität, lösen jeden Hostnamen nach IPv4 und IPv6 auf, gehen für jede Adresse den FCrDNS-Rundweg, erkennen den Mail-Provider am Muster und verbinden uns dann aus unserem Messnetz mit jedem Server auf Port 25 — wir lesen das SMTP-Banner und testen STARTTLS. Kostenlos, ohne Anmeldung, in wenigen Sekunden von Anfang bis Ende.

Kleinere Zahl = zuerst versucht. Absender rücken erst dann zum nächsten Host in der Liste weiter, wenn die Hosts mit der besseren Priorität nicht antworten. Gleiche Prioritäten sind kein Fehler — sie sind Lastverteilung per Round-Robin, und große Provider nutzen sie genau so (Googles klassischer Satz hat zwei Hosts auf 5 und zwei auf 10). Das Problem mehrstufiger Aufbauten sind nicht die Zahlen — die Backup-Stufe läuft mit älterer Software und lockereren Filtern, und genau darauf zielen Spammer.

Forward-confirmed Reverse DNS: Die IP-Adresse Ihres Mailservers braucht einen PTR-Eintrag, und der Name aus diesem PTR muss zurück auf dieselbe IP auflösen. Das ist ein billiger Beleg dafür, dass, wer die IP kontrolliert, auch den Namen kontrolliert — Spam-Schleudern auf gekaperten Adressbereichen schaffen das meist nicht. Googles Absenderrichtlinien machen einen gültigen, passenden PTR zur harten Voraussetzung für die Zustellung an Gmail, und die meisten Filter werten ihn. Und bevor Sie das unter »nur ausgehend« ablegen: Ihr MX-Host sendet ebenfalls — jede Unzustellbarkeit, jede Abwesenheitsnotiz, jede Weiterleitung. Ein gebrochener Rundweg auf dem eingehenden Server belastet das alles im Stillen.

Ein einzelner MX mit Präferenz 0 und der DNS-Wurzel als Host — 0 . — festgelegt in RFC 7505. Das ist der Standardweg, um zu erklären: »diese Domain nimmt keine Mail an«. Absender sehen ihn und geben binnen Sekunden eine dauerhafte Unzustellbarkeit zurück, statt auf die implizite MX-Regel zurückzufallen und Ihren Webserver tagelang mit Wiederholungen zu belasten. Für geparkte und reine Web-Domains ist er der richtige Eintrag — zusammen mit v=spf1 -all und einer DMARC-Richtlinie auf reject, damit auch niemand als die Domain senden kann.

Erstaunlicherweise ja. Die implizite MX-Regel aus RFC 5321 besagt: Fehlt der MX, behandeln Absender den A/AAAA-Eintrag der Domain wie einen MX mit Präferenz 0 — Mail geht also an das, was auf der IP-Adresse Ihres Webservers antwortet. Läuft dort zufällig ein MTA, fließt Mail; manche betreiben ihre Produktions-E-Mail jahrelang auf diesem Zufall. Das ist fragil — Website umziehen heißt Mail verlieren — und selten Absicht. Veröffentlichen Sie explizite MX-Einträge für echte Mail, oder 0 . für keine.

Nein — und das wird oft verwechselt. Der MX beantwortet, wohin Mail an diese Domain geht; Ihr Ruf beim Senden hängt an der sendenden IP, an SPF, DKIM und DMARC, die unsere Schwestertools einzeln bewerten. Zwei Ausnahmen: Im Eigenbetrieb ist der MX-Server zugleich der sendende Server, seine FCrDNS- und TLS-Hygiene zählt also doppelt; und manche Empfänger prüfen zur Plausibilität, ob eine sendende Domain auch empfangen kann — ein kaputter MX-Satz fällt dabei still durch.

Der Messpunkt öffnet zu jedem MX-Host eine TCP-Verbindung auf Port 25, liest das Begrüßungsbanner, sendet EHLO und prüft, ob STARTTLS angeboten wird — verhandelt es dann und hält TLS-Version und Zertifikat fest. Es wird keine Mail verschickt: Das Gespräch endet vor MAIL FROM. Von einem Privatanschluss aus geht das nicht, weil Internetanbieter Port 25 dort ausgehend sperren, um Botnetz-Spam einzudämmen. Ein Vorbehalt lohnt die Erwähnung: STARTTLS auf Port 25 ist opportunistisch — ein Angreifer auf dem Übertragungsweg kann das Angebot entfernen. MTA-STS ist das Schloss; unser TLS-Versions-Checker geht jede Protokollversion durch, die Ihr Server spricht.