E-Mail: wie sie funktioniert, woher sie kommt, wohin sie geht

Über 50 Jahre alt und noch immer das wichtigste Werkzeug der Geschäftswelt: wie eine E-Mail ihren Weg findet, warum Fälschungen so leicht waren und was sich gerade ändert.

Architektur und Rollen

MUA → MSA (Submission 587/465) → MTA → MX-Auflösung im DNS → MTA des Empfängers (25, STARTTLS) → MDA → IMAP 993 zum MUA — MUA, MSA, MTA, MDA: die Rollen im Mailsystem.

Rolle	Aufgabe	Protokoll / Port
MUA (Mail User Agent)	Mailprogramm, Webmail, App	Submission 587 (STARTTLS) bzw. 465 (Implicit TLS, RFC 8314)
MSA / MTA	Annahme mit Authentifizierung, Weiterleitung zwischen Servern	SMTP 25, opportunistisch STARTTLS (RFC 3207)
MDA	Ablage im Postfach, Filter (z. B. Sieve)	lokal, LMTP
Zugriff	Lesen und Synchronisieren	IMAP 993 (IMAP4rev2, RFC 9051), POP3 995, JMAP (RFC 8620/8621)

Zustellung: Der sendende MTA löst den MX-Eintrag der Empfängerdomain auf (Fallback auf A/AAAA, wenn kein MX existiert; «Null-MX» nach RFC 7505 erklärt eine Domain als nicht empfangend) und versucht die Server nach Priorität. Temporäre Fehler (4xx) führen zu Wiederholungen über Stunden bis Tage, permanente (5xx) zu einer Unzustellbarkeitsmeldung.

Umschlag und Kopf: zwei Absender

SMTP trennt den Umschlag (MAIL FROM, auch Return-Path oder RFC5321.MailFrom) vom Kopf der Nachricht (From:, RFC5322.From). Der Mensch sieht nur den Kopf. Genau diese Lücke nutzen Fälschungen, und genau hier setzt DMARC mit dem Alignment an.

S: 220 mx.example.ch ESMTP
C: EHLO mail.eam.ch
S: 250-STARTTLS
C: STARTTLS
   … TLS-Handshake …
C: MAIL FROM:<bounce@eam.ch>
C: RCPT TO:<kunde@example.ch>
C: DATA
   From: eam.ch <noreply@eam.ch>
   Subject: …

Geschichte und Standards

1971 Ray Tomlinson, BBN: Mail zwischen Rechnern im ARPANET, Trennzeichen @.
1982 RFC 821 (SMTP) und RFC 822 (Nachrichtenformat).
1984/1988 POP (RFC 918), IMAP (Mark Crispin, 1986; IMAP2 RFC 1064, 1988).
1992/1996 MIME (RFC 1341, heute RFC 2045–2049): Anhänge, Zeichensätze, mehrteilige Nachrichten.
1995 ESMTP (RFC 1869): Erweiterungen wie SIZE, 8BITMIME, später AUTH.
1999/2002 STARTTLS für SMTP (RFC 2487, heute RFC 3207).
2008 RFC 5321/5322 lösen RFC 2821/2822 ab (aktueller SMTP-Standard).
2006–2015 SPF (RFC 4408 → 7208, 2014), DKIM (RFC 4871 → 6376, 2011), DMARC (RFC 7489, 2015, informational).
2012 Internationalisierte Adressen (SMTPUTF8, RFC 6531).
2015–2019 DANE für SMTP (RFC 7672), MTA-STS (RFC 8461) und TLS-RPT (RFC 8460, beide 2018), ARC (RFC 8617, experimentell).
2018 RFC 8314: Implicit TLS für Submission und Zugriff wird empfohlen (465, 993, 995).
2021 IMAP4rev2 (RFC 9051).
2024/2025 Google und Yahoo (ab Februar 2024) bzw. Microsoft für Outlook.com, Hotmail und Live (ab 5. Mai 2025, über 5000 E-Mails pro Tag): SPF, DKIM und DMARC sind Pflicht, sonst Abweisung.
2026 DMARCbis als Standards-Track: RFC 9989 (Protokoll), 9990 (Aggregatberichte), 9991 (Fehlerberichte); RFC 7489 abgelöst.

Authentifizierung im Detail

SPF prüft die IP gegen den Umschlag-Absender, DKIM die Signatur mit Domain d= und Selektor s=, DMARC verlangt Alignment mit dem From-Kopf — SPF und DKIM liefern das Ergebnis, DMARC verknüpft es mit dem sichtbaren Absender.

SPF (RFC 7208)

TXT-Eintrag an der Umschlag-Domain, z. B. v=spf1 mx include:spf.protection.outlook.com -all. Grenzen: höchstens 10 DNS-Abfragen (include, a, mx, redirect …), bei Weiterleitungen bricht SPF, und SPF prüft nicht den sichtbaren Absender.

DKIM (RFC 6376)

Signatur über ausgewählte Kopfzeilen und den Text; der öffentliche Schlüssel liegt unter <selektor>._domainkey.<domain>. Empfohlen: RSA 2048 Bit (oder Ed25519, RFC 8463, zusätzlich), regelmässige Schlüsselwechsel, From mehrfach signieren (oversigning).

DMARC (RFC 7489 bzw. RFC 9989)

_dmarc.example.ch. TXT "v=DMARC1; p=reject; rua=mailto:dmarc@example.ch; adkim=s; aspf=s"

DMARC besteht, wenn SPF oder DKIM besteht und zur Domain im From: passt (Alignment, relaxed oder strict).
Policy p=none (nur Berichte), quarantine, reject; sp= für Subdomains.
DMARCbis (RFC 9989): pct, rf und ri sind historisch; neu t=y (Testmodus, eine Stufe tiefer), np= für nicht existierende Subdomains, psd= für Public-Suffix-Domains; die Organisationsdomain wird per DNS-«Tree Walk» (höchstens acht Abfragen) statt über die Public Suffix List ermittelt.
Aggregatberichte (rua) zeigen, wer im Namen der Domain sendet – Grundlage für den Weg zu p=reject.

ARC und Weiterleitungen

Mailinglisten und Weiterleitungen verändern Nachrichten oder den Umschlag. ARC (RFC 8617) hält die Prüfergebnisse unterwegs fest, damit vertrauenswürdige Zwischenstationen DMARC-Fehler erklären können.

Transportverschlüsselung

Verfahren	Wirkung	Voraussetzung
STARTTLS (opportunistisch)	verschlüsselt, wenn beide können; ein Angreifer im Netz kann es unterdrücken (Downgrade)	Zertifikat am MX
MTA-STS (RFC 8461)	Sender verlangen gültiges Zertifikat und TLS, Richtlinie per HTTPS unter `mta-sts.<domain>`	TXT `_mta-sts`, Policy-Datei, gültige Zertifikate
DANE (RFC 7672)	Zertifikat per TLSA-Eintrag im DNS festgenagelt	DNSSEC für Domain und MX
TLS-RPT (RFC 8460)	tägliche Berichte über fehlgeschlagene verschlüsselte Zustellungen	TXT `_smtp._tls`

Stand heute (2026)

Die grossen Postfachanbieter erzwingen SPF, DKIM, DMARC (mindestens p=none, Alignment), gültige PTR-Einträge, TLS und – für Massenversand – Abmeldung mit einem Klick (RFC 8058) sowie tiefe Spam-Beschwerderaten.
Der Anteil der Domains mit p=reject wächst, ist aber vor allem bei KMU und Verwaltungen noch gering.
Submission über Port 465 (Implicit TLS) setzt sich durch; Port 25 ist für Endgeräte bei vielen Providern gesperrt.
Ende-zu-Ende-Verschlüsselung (S/MIME, OpenPGP) bleibt eine Nische; vertrauliche Inhalte laufen oft über Portale.
Business E-Mail Compromise (BEC) und Phishing bleiben bei vielen Lageberichten unter den häufigsten Angriffswegen; gefälschte Absender und ähnliche Domains (Typosquatting) spielen dabei eine zentrale Rolle.

Entwicklungen

DMARCbis in der Praxis: Tree Walk, np=, t=; Auswertungen und Werkzeuge müssen nachziehen.
Post-Quanten-Kryptografie: hybride Schlüsselvereinbarungen (z. B. X25519MLKEM768) sind in TLS-Bibliotheken angekommen und werden auch zwischen Mailservern Einzug halten; für DKIM werden quantensichere Signaturen diskutiert.
Durchgesetzte Transportverschlüsselung mit MTA-STS bzw. DANE statt opportunistischem STARTTLS.
BIMI (Markenlogo bei geprüften Absendern, mit Zertifikat VMC/CMC) als Anreiz für p=quarantine/reject.
JMAP als modernes, JSON-basiertes Zugriffsprotokoll neben IMAP.
KI auf beiden Seiten: bessere Filter, aber auch täuschend echte Phishing-Mails ohne Sprachfehler – technische Authentifizierung wird zur Pflicht, nicht zur Kür.

Was eam.ch prüft

SPF (vorhanden, zu offen, Fehler), DMARC (vorhanden, Policy, Berichtsadresse), DKIM (gängige Selektoren).
MX: STARTTLS und Zertifikat; MTA-STS und TLS-RPT; Domains ohne Mail ohne Schutz vor Fälschung.
Ähnliche Domains, die E-Mails versenden können (Fälschungsdomains), und Mailserver auf Sperrlisten (Reputation).

Quellen: RFC 821, 822, 1341, 2045, 3207, 5321, 5322, 6376, 6531, 7208, 7489, 7505, 7672, 8058, 8314, 8460, 8461, 8463, 8617, 8620, 8621, 9051, 9989–9991 (rfc-editor.org); Microsoft Tech Community, «Strengthening Email Security: Outlook’s New Requirements for High-Volume Senders» (2025); Google, «Email sender guidelines» (2024).

Kurz zusammengefasst

E-Mail läuft in drei Etappen: Abschicken (SMTP), Weiterreichen zwischen Servern (SMTP über den MX-Eintrag) und Abholen (IMAP).
Absender lassen sich fälschen, weil SMTP sie nicht prüft.
SPF, DKIM und DMARC machen E-Mails überprüfbar; erst p=reject schützt wirksam.
Seit 2024/2025 verlangen Google, Yahoo und Microsoft diese Einträge; 2026 erscheint DMARCbis als neuer Standard.
MTA-STS und DANE erzwingen verschlüsselte Zustellung.