Zusammenfassung

  • Der Domainteil einer Mailadresse wurde zur stabilen Identität statt zur Anweisung, den gleichnamigen Host zu kontaktieren. MX konnte andere und mehrere Empfänger veröffentlichen.
  • Der sendende MTA führte die dünne Regel lokal aus: kleinste Preference zuerst, gleiche Werte als Gleichrangige, Rückweg über den eigenen Host abschneiden. MX-Einträge eines Ziel-MX vererbten keine Verantwortung.
  • DNS-Kontrolle kann Mail umleiten, Caches verzögern Wechsel und mehrere Namen können eine Störung teilen. MX ist deshalb ein Kontrollpunkt, aber kein Eigentums-, Authentizitäts- oder Vertraulichkeitsnachweis.

Als Adresse und Maschine noch zusammenfielen

RFC 974 beschrieb die frühere Erwartung: Mail für eine mailbox bei LOKI.BBN.COM ließ sich meist per SMTP an LOKI.BBN.COM übergeben. Der Name bezeichnete Publikum und Maschine zugleich.

Ausnahmen gab es. Nicht direkt angebundene UUCP- und CSNET-Hosts wurden durch lokale Konfiguration erreicht; CSNET-Mail ging etwa an CSNET-RELAY.ARPA. SMTP in RFC 821 kannte Relay, Gateway und Source Route. MX erfand nicht die Zwischenstation.

Schwierig war die Verteilung der Sonderregeln. Der Empfänger konnte fremde Mailer-Konfigurationen nicht ändern. Mit einer dauerhaften Domain musste der aktuelle Empfangsort als eigener öffentlicher Zustand erscheinen.

Aus zwei Typen wird eine geordnete Menge

RFC 882 und RFC 883 bauten DNS aus typisierten Resource Records. MD stand für Mail Destination, MF für Mail Forwarder. Die zwei Rollen ließen sich schlecht zu mehreren Alternativen erweitern.

RFC 973 ersetzte beide durch MX: eine vorzeichenlose 16-Bit-Preference und den Hostnamen des Exchangers. Kleinere Werte werden zuerst versucht; gleiche Werte sind gleichrangig.

Damit wurden Rollen zu geordneten Möglichkeiten. Direkter Host, Relay und Backup passten in dieselbe Grammatik. RFC 1035 bewahrte das kompakte Format. Der gemeinsame Layer enthielt keinen vollständigen Weg und keinen Gesundheitswert, sondern nur handlungsfähige Daten.

Der Name bleibt, der Dienst zieht um

RFC 974 stellte klar: Eine Domain ist häufig ein Host, aber nicht immer. Der Mailer musste DNS fragen; die Antwort konnte auf eine völlig andere Maschine oder mehrere zeigen.

Eine Organisation konnte Hardware, Standort, Filter oder Provider wechseln, ohne Adressen umzubenennen. Der Sender brauchte nicht die interne Migration zu kennen, sondern den aktuellen MX.

Wer die autoritative Zone kontrolliert, kann allerdings künftige Mail umleiten. MX beglaubigt kein Eigentum. Es trennt lediglich zwei notwendigerweise verschiedene Lebenszeiten: den bekannten Namen und seine heutige technische Umsetzung.

Einmal publiziert, überall lokal ausgeführt

RFC 974 empfahl die MX-Abfrage bei jedem Zustellversuch. Nach einem Ausfall konnte der Zieladministrator DNS ändern; bereits wartende Nachrichten lernten beim nächsten Versuch die neue Route, sobald der jeweilige Cache es zuließ.

Der Sender probierte die kleinste Preference und danach weitere Ziele. Gleichrangige niedrigste Ziele sollten vor einem endgültigen Fehler alle versucht werden. RFC 5321 verlangt die Fähigkeit, relevante Adressen zu versuchen und erneut zu versuchen. Unter gleichrangigen Zielen ohne anderen Grund wird randomisiert, um Last zu verteilen.

Preference ist keine Latenz, Entfernung, Auslastung oder institutionelle Rangfolge. Zehn kommt vor zwanzig, weil die Domain diese Reihenfolge erklärt hat. Ein näherer Backup bleibt später.

Es gibt keine zentrale Mail-Leitstelle. DNS veröffentlicht wenig; unabhängige MTAs lösen auf, reihen ein, wiederholen und erzeugen Bounces nach lokaler Politik.

Die eigene Position verhindert den Kreis

Alternativen können Loops bilden. Steht der lokale Host in der MX-Liste, entfernt er laut RFC 974 sich selbst und alle Einträge mit gleichem oder größerem Zahlenwert. Er darf nur zu einem kleineren Wert weitergeben.

Backup 20 kann Primary 10 erneut versuchen, nicht aber 20 oder 30 und damit eine Rückkehr ermöglichen. Preference richtet somit die Übernahme von Verantwortung aus.

Auch die MX-Abfrage eines gefundenen Exchangers wird nicht als weitere Relaiskette interpretiert. Wer MX für ein Relay ist, übernimmt nicht automatisch dessen sämtliche Domains. Annahmeverantwortung muss für das ursprüngliche Ziel ausdrücklich veröffentlicht sein; sie ist nicht transitiv.

Cache: Skalierung mit bekannter Verzögerung

DNS skaliert durch Caches. Nach einem Wechsel sehen einige Sender alte, andere neue Daten. RFC 974 akzeptierte, dass während der Ablaufzeit Loops oder falsche Unzustellbarkeit entstehen können.

Jede Abfrage unmittelbar an autoritative Server zu zwingen, wäre zu teuer gewesen. Der RFC verlangte stattdessen Koordination vor der Aufnahme eines Exchangers, vollständige Antworten und Wiederholung einer abgeschnittenen UDP-Antwort über eine zuverlässige Verbindung.

Cache ist nicht bloß ein Fehler. Er tauscht Gleichzeitigkeit gegen Tragfähigkeit. Sichere Migration senkt TTL, überlappt Dienste und behält Rollback; sie behauptet keinen globalen Sofortschalter.

Kein MX bedeutete weiterhin „versuchen“

RFC 974 behandelte eine leere Liste als impliziten MX mit Preference null auf die Domain selbst. RFC 5321 behält dies und löst A oder AAAA auf.

Das half alten Domains, machte Schweigen aber mehrdeutig. Es konnte funktionierende Altlast, Versäumnis oder bewussten Verzicht auf Mail bedeuten. Sender probierten trotzdem SMTP an einer Webadresse und wiederholten tageweise.

Explizite MX-Daten dürfen nicht ignoriert werden. Ist kein veröffentlichter MX nutzbar, ist das ein Fehler und kein Anlass für A/AAAA-Fallback. Das MX-Ziel muss unmittelbar Adressen liefern; CNAME-Ziele liegen außerhalb des modernen SMTP-Standards.

Ein Punkt sagt ausdrücklich „kein Maildienst“

RFC 7505 führte 2015 Null MX ein. Eine Domain ohne Mailannahme veröffentlicht genau einen MX mit Preference null und dem DNS-Root . als Exchange; andere MX sind verboten.

Der Punkt ist kein defekter Server. Er erklärt, dass kein Exchanger existiert. Der MTA scheitert sofort statt A/AAAA zu nutzen und typischerweise etwa eine Woche zu wiederholen.

Null MX ist eine spätere Korrektur, keine Eigenschaft von 1986. Die Kompatibilität hatte „nicht konfiguriert“ und „kein Dienst“ vermischt. Der explizite Zustand trennt sie. Er ist auch nicht der SMTP Null Reverse-Path.

Macht in einer kleinen Zuordnung

Portabilität gegenüber einem Server bedeutet Abhängigkeit von der Zuordnung. Zone Capture kann Mail umleiten. Mehrere Hostnamen können Provider, Standort, Netz und Konto teilen. Backup erhöht Kontinuität und zugleich die Zahl der Stellen, die Inhalt und Metadaten sehen.

DNSSEC schützt Datenintegrität, nicht juristische Identität oder internes Verhalten. SMTP-Annahme belegt Verantwortungsübernahme an einer Grenze, nicht Speicherung, Lesen oder Vertraulichkeit.

MX ist in engem Umfang legitim: Es publiziert, wo eine Domain Mail übernimmt, in welcher Reihenfolge oder dass sie keinen Dienst bietet. Es macht den DNS-Betreiber nicht zum Souverän der Identität.

Die kleinste nützliche Zustellkarte

Adresse, Infrastruktur und Cachewissen erhielten verschiedene Rhythmen. Der Name bleibt, der Server wechselt, Wissen konvergiert nach TTL. Korrespondenten müssen nicht an Migrationen teilnehmen, weil die Zuordnung öffentlich und ersetzbar ist.

Gemeinsam sind Domain, Exchanger, Preference, TTL sowie Loop- und Fallback-Regeln. Queue, Sicherheit, Mailbox und Vertrag bleiben lokal.

Die Adresse überlebte den Server, weil ihr Zuhause kein ewiger Ort, sondern ein aktualisierbarer Zustand wurde. Der Record beschreibt gerade genug Wirklichkeit für lokales Handeln.

Quellen und Beweisgrenzen

SMTP- und Domainkontext liefern RFC 821, RFC 882 und RFC 883. Der Wechsel von MD/MF steht in RFC 973. Algorithmus, Cache, Loop und nicht transitive Verantwortung stammen aus RFC 974.

Das Format beschreibt RFC 1035, Hostanforderungen RFC 1123. Reifes Lookup und implizites MX stehen in RFC 5321, No-Service in RFC 7505.

Die Dokumente gehören zu verschiedenen Zeiten; spätere Regeln werden nicht auf 1986 zurückprojiziert. Weitere Betriebsfolgen bleiben begrenzte Schlussfolgerungen.