E-Mail-SicherheitMXDNSMail-Routing

MX-Record-Prüfung

Fragt MX-Records über DNS-over-HTTPS ab, sortiert Prioritäten, löst erste Hosts auf und zeigt Null-MX- oder CNAME-Probleme.

Gut für Mailrouting-Sanity-Checks, bevor DNS, Mailgateway oder Provider-Konfiguration geändert werden.

Eingaben

MX-Record-Prüfung ist eine von 24 direkt ausführbaren, schreibgeschützten WebMCP-Diagnosen auf der Root-Seite. Das Tool gibt ein strukturiertes Ergebnis zurück und nutzt dieselbe kanonische Beschreibung in document.modelContext, Toolseiten, tools.json, Well-Known-Manifesten, OpenAPI und JSON-LD.

Beispiel

example.com -> MX-Preference, Exchanger-Host, erste A- und AAAA-Antworten sowie Null-MX- oder CNAME-Warnungen.

Was MX-Records entscheiden — und was nicht

MX-Records sind die Routing-Tabelle der E-Mail: Sie benennen die Hosts, die Mail für eine Domain annehmen, und die Reihenfolge, in der Sender sie versuchen sollen. Fast jedes Zustellrätsel beginnt hier, weil MX der Punkt ist, an dem DNS-Absicht und Mail-Realität sich zum ersten Mal berühren — eine Domain kann perfektes SPF und DMARC haben und trotzdem Mail an einen veralteten Exchanger verlieren, an ein CNAME-Ziel, das den Standard verletzt, oder an ein vergessenes Null MX, das der Welt höflich mitteilt, dass die Domain nichts annimmt.

Dieser Check liest das veröffentlichte MX-Set, sortiert nach Präferenz, löst die ersten Exchanger zu A- und AAAA-Adressen auf und markiert die Routing-Muster, die echte Vorfälle verursachen: fehlende Records, Null MX, CNAME-Ziele und tote Hostnamen. Es ist bewusst eine reine DNS-Sicht — keine SMTP-Verbindung wird geöffnet — was den Check schnell, sicher und ehrlich darüber macht, welche Schicht er untersucht.

Vom Lookup zur Routing-Diagnose

Gib die Domain ein und lies die Interpretation vor den Rohdaten: Reihenfolge, Präferenzwerte und Warnungen beantworten die eigentliche Frage oft direkt. Niedrigere Präferenz gewinnt; gleiche Präferenzen verteilen auf mehrere Hosts. Prüfe dann, ob die ersten Exchanger auflösen — IPv4 und IPv6 —, denn ein Hostname ohne Adressen oder einer, der nur in einer Adressfamilie existiert, erzeugt genau die Art intermittierender Zustellfehler, die von außen elend zu debuggen ist.

Bei Zustellvorfällen kombiniere das Resultat mit Evidenz aus der Gegenrichtung: Die Received-Kette einer echten Nachricht zeigt, welcher Exchanger die Mail tatsächlich angenommen hat, und SPF, DKIM und DMARC der Domain entscheiden, ob ihr nach Ankunft vertraut wurde. Routing und Authentifizierung scheitern unterschiedlich — MX-Probleme verlieren oder verzögern Mail im Ganzen, Authentifizierungsprobleme sortieren sie in Spam — und zu wissen, in welcher Familie man sich befindet, halbiert den Suchraum.

Auflösungswege ohne SMTP-Kontakt

Die Domain wird erst nach dem Start des Lookups gesendet; der Browser versucht zuerst Cloudflare DNS-over-HTTPS und fällt bei Bedarf auf den Same-Origin-DNS-Helper zurück. Das Tool öffnet keine SMTP-Sessions, testet kein STARTTLS und kann keine Zustellung von einem bestimmten Sender beweisen — es zeigt, was DNS Sendern aktuell vorschreibt: eine notwendige Wahrheit, aber nicht die ganze. Die Seite speichert keine Lookup-Historie; Resolver und Hosting-Infrastruktur führen wie jeder Netzdienst eigene Betriebslogs.

Häufige Fragen

Was bedeutet eine niedrigere MX-Präferenz?

Niedrigere Werte werden zuerst versucht; auf höhere weichen Sender nur aus, wenn die bevorzugten Hosts scheitern. Gleiche Werte lassen den Sender frei wählen — so funktioniert einfache Lastverteilung über mehrere Exchanger.

Was ist Null MX, und wann ist es richtig?

Ein einzelner MX-Record mit Präferenz 0 und einem Punkt als Ziel erklärt, dass die Domain gar keine Mail annimmt. Für wirklich mailfreie Domains ist das das korrekte, explizite Signal — deutlich besser, als Sender gegen nicht existierende Server laufen zu lassen.

Warum wird ein CNAME als MX-Ziel markiert?

Weil die Standards für MX-Ziele Hostnamen mit Adressrecords verlangen, keine Aliase. Viele Empfänger tolerieren CNAME-Ketten, aber tolerant heißt nicht zuverlässig — manche Sendeimplementierungen behandeln sie falsch, mit Fehlern, die nur bestimmte Gegenstellen je sehen.

Warum zeigt das Tool A- und AAAA-Records?

Um zu bestätigen, dass die veröffentlichten Exchanger als Adressen existieren — und in welchen Adressfamilien. Ein Host, der nur über IPv4 auflöst, während ein Sender IPv6 bevorzugt, ist eine klassische Quelle asymmetrischen Zustellverhaltens.

Ein Backup-MX wirkt tot — ist das dringend?

Eher ja. In ruhigen Zeiten merkt es niemand, aber Sender weichen genau dann auf höhere Präferenzen aus, wenn der primäre Host Probleme hat — der Moment, in dem ein totes Backup aus einem Teilausfall verlorene Mail macht.

Speichert diese App abgefragte Domains?

Die Seite speichert keine Lookup-Historie. DNS-Provider und normale Hosting-Infrastruktur können wie jeder Netzdienst eigene Betriebslogs führen.