Die Reise einer E-Mail

Modul 1: Wie E-Mail funktioniert · Lesezeit: 9 Minuten

Lernziel: Nach dieser Lektion können Sie Schritt für Schritt beschreiben, wie eine E-Mail vom Absender beim Empfänger ankommt, und bei jedem Schritt benennen, welches Programm oder welcher Server die Arbeit übernimmt.

Kernbegriffe: E-Mail-Programm (MUA), Versandserver (MSA, Submission), Mailserver (MTA), MX-Record, Warteschlange, Zustellung (MDA), Postfach, Abholen (IMAP/POP3), Envelope, Header

E-Mail ist Post, keine Chatnachricht

Wenn Sie eine Chatnachricht senden, läuft das über ein einziges Unternehmen: Die App des Absenders und die App des Empfängers sprechen mit denselben Servern. E-Mail funktioniert anders. Absender und Empfänger können jeweils bei einem anderen Anbieter sein: der eine bei einem Hostingunternehmen, der andere bei Gmail, ein Dritter bei Microsoft 365 oder auf dem eigenen Firmenserver. Trotzdem kommt die Mail an. Das gelingt, weil alle Mailserver weltweit dieselben Regeln befolgen.

Man kann E-Mail gut mit der Post vergleichen. Sie schreiben einen Brief (die Nachricht), stecken ihn in einen Umschlag mit einer Adresse (den Envelope), bringen ihn zum Briefkasten (den Versandserver), das Postunternehmen ermittelt, wohin die Adresse gehört (die MX-Abfrage), transportiert den Brief zum richtigen Verteilzentrum (den empfangenden Mailserver), und dieser legt ihn in den Briefkasten des Empfängers (das Postfach). Der Empfänger holt ihn dort ab, wenn es ihm passt.

Die Stationen im Überblick

Angenommen, Anna schickt eine Mail von anna@example.com an jan@example.net. Dann geschieht Folgendes:

Bei kleinen Anbietern sind MSA, MTA und MDA oft ein und dasselbe Programm auf einem Server. Bei grossen Anbietern sind es getrennte Cluster. Für Sie macht das wenig Unterschied: Es handelt sich um Rollen, nicht um einzelne Geräte.

Achten Sie auf den Unterschied zwischen Schritt 1 und Schritt 4. Beide nutzen SMTP, das Simple Mail Transfer Protocol (RFC 5321). Bei Schritt 1 melden Sie sich jedoch an und verwenden Port 587 oder 465; das nennt man Submission (RFC 6409). Bei Schritt 4 sprechen zwei Server miteinander auf Port 25, ohne Anmeldung: Der empfangende Server nimmt Mail für seine eigenen Domains von jedem beliebigen Absender an. In Lektion 1.4 sehen Sie, warum diese Trennung besteht.

Schritt 3 im Detail: die MX-Abfrage

Der versendende Server weiss nicht von sich aus, wo example.net seine Mail empfängt. Er fragt beim DNS nach:

example.net.   3600  IN  MX  10 mx1.mailprovider.example.
example.net.   3600  IN  MX  20 mx2.mailprovider.example.

Die niedrigste Zahl hat Vorrang. Der Server versucht zuerst mx1, und falls dieser nicht antwortet, mx2. Danach fragt er die IP-Adresse dieses Namens ab (A- oder AAAA-Record) und baut die Verbindung auf.

Zwei Sonderfälle, denen Sie in der Praxis begegnen:

• Kein MX-Record. Dann versucht der Absender das A- oder AAAA-Record der Domain selbst (der "implizite MX" aus RFC 5321, Abschnitt 5.1). Das ist ein Überbleibsel aus früheren Zeiten und funktioniert nicht zuverlässig; jede Domain, die Mail empfängt, sollte einen MX-Record haben.
• Ein Null-MX: 0 . Das bedeutet: "Diese Domain empfängt niemals Mail" (RFC 7505). Die Domain example.com hat einen solchen Eintrag. Ein Absender gibt sofort auf und sendet eine Fehlermeldung zurück, statt tagelang weiter zu versuchen.

Wie MX-Records und Prioritäten genau funktionieren, lesen Sie in Lektion 4.1 des DNS-Kurses.

Die Warteschlange: E-Mail darf etwas dauern

Eine Mail kommt nicht immer innerhalb einer Sekunde an. Antwortet der empfangende Server nicht, oder sagt er "versuchen Sie es später noch einmal" (ein Code, der mit einer 4 beginnt), bleibt die Mail in der Warteschlange des Versandservers stehen. Dieser versucht es später erneut, jeweils mit etwas mehr Zeit dazwischen. RFC 5321 (Abschnitt 4.5.4.1) empfiehlt mindestens 30 Minuten zwischen den Versuchen und erst nach 4 bis 5 Tagen aufzugeben. Viele Server senden nach einigen Stunden bereits eine Warnung ("delayed", noch nicht zugestellt) und nach einigen Tagen die endgültige Fehlermeldung.

Das ist ein starker Vorteil von E-Mail: Fällt ein Mailserver für eine Stunde aus, geht keine Mail verloren. Das ist auch der Grund, warum eine Mail manchmal erst Stunden später ankommt. In Modul 6 sehen Sie, wie Sie eine solche Verzögerung erkennen.

Envelope und Header: zwei Adressen

Genau wie bei der Post hat eine Mail zwei Arten von Adressen:

• Der Envelope. Das sind die Adressen, die die Server untereinander im SMTP-Gespräch verwenden: MAIL FROM (der Absender für Fehlermeldungen, später sichtbar als Return-Path) und RCPT TO (der Empfänger). Die Server stellen anhand des Envelope zu.
• Die Header. Das ist, was im Brief selbst steht: From:, To:, Cc:, Subject:, Date:. Ihr E-Mail-Programm zeigt diese an.

Meistens stimmen sie überein, aber nicht immer. Ein BCC-Empfänger steht zwar im Envelope, aber nicht in den Headern; deshalb sehen andere ihn nicht. Ein Newsletter-Dienst setzt seine eigene Adresse als Envelope-Absender, damit Fehlermeldungen beim Dienst landen, während in From: Ihre Adresse steht. Und ein Betrüger kann in From: eintragen, was er möchte.

Warum das wichtig ist: SPF prüft den Envelope-Absender, der Nutzer sieht das From:-Feld. Deshalb gibt es DMARC, das diese beiden miteinander verknüpft (Modul 4).

Wo es schiefgehen kann

Mit diesem Bild können Sie bei jedem Problem fragen: An welcher Station geht es schief?

• Senden gelingt nicht (Fehlermeldung sofort in Ihrem Programm): Schritt 1 oder 2. Fast immer Einstellungen: Port, Anmeldung, Passwort (Modul 2).
• Sie erhalten eine Bounce zurück: Schritt 4 oder 5. Der empfangende Server hat die Mail abgelehnt, oder die Adresse existiert nicht (Modul 6).
• Die Mail kommt an, aber im Spam-Ordner: Schritt 5. Der Empfänger vertraut der Mail nicht (Module 4 und 5).
• Der Empfänger sieht nichts, und Sie erhalten keine Fehlermeldung: Die Mail steht vielleicht noch in einer Warteschlange oder wurde beim Empfänger still herausgefiltert. Hier helfen die Protokolle des Versandservers (Modul 6).
• Mail kommt überhaupt nicht für Ihre Domain an: Schritt 3. Die MX-Records stimmen nicht, zum Beispiel nach einem Umzug (Modul 8).

In der Praxis: So sieht es bei einem Hostingpaket aus

Bei einem Hostingpaket von WebOké übernimmt ein einziger Server pro Paket alle Rollen: Ihr E-Mail-Programm liefert die Mail bei diesem Server ab (Schritt 1 und 2), der Server versendet sie nach aussen (Schritt 3 und 4) und empfängt Mail für Ihre Domain (Schritt 5). In DirectAdmin können Sie mit E-Mail-Verfolgung pro Nachricht sehen, ob sie zugestellt wurde. Bei anderen Anbietern funktioniert es ähnlich; dort heisst eine solche Funktion zum Beispiel "Nachrichtenverfolgung" oder "Mail-Log".

Zusammenfassung

• Eine Mail geht von Ihrem E-Mail-Programm (MUA) über den Versandserver (MSA/MTA) zum empfangenden Server (MTA/MDA) und von dort zum E-Mail-Programm des Empfängers.
• Senden aus Ihrem Programm heraus ist SMTP-Submission mit Anmeldung (587/465); Server sprechen untereinander SMTP auf Port 25; Abholen erfolgt mit IMAP oder POP3.
• Der versendende Server fragt die MX-Records der Domain hinter dem @ ab. Ein Null-MX (0 .) bedeutet: Diese Domain empfängt keine Mail.
• Eine Mail, die nicht sofort zugestellt werden kann, bleibt in der Warteschlange und wird tagelang erneut versucht.
• Envelope (Return-Path) und Header (From) sind zwei unterschiedliche Absender. SPF betrachtet den ersten, der Nutzer den zweiten.

Quiz

Aufgabe

Aufgabe Z1.1: Den ersten Mailserver finden. Suchen Sie die MX-Records von gmail.com (oder Ihrer eigenen Domain). Geben Sie an, welcher Server als Erster versucht wird, mit seiner Prioritätszahl, und eine IP-Adresse (IPv4 oder IPv6) dieses Servers. Das Programm fragt dieselben Daten live ab und überprüft sie.

Weiterführende Informationen

Die Schritte in diesen Artikeln gelten für die Panels von WebOké; bei anderen Anbietern funktioniert es ähnlich.

• So funktioniert der Versand von E-Mails (SMTP)
• DirectAdmin Anleitung 8.7: IMAP oder POP3: Was ist der Unterschied?
• Kostenloser DNS-Kurs 4.1: MX-Einträge und Priorität
• RFC 5321 (SMTP), Abschnitt 5.1 (MX und impliziter MX) und 4.5.4.1 (Wiederholungsversuche); RFC 7505 (Null-MX)