E-Mail-Dienste sicher betreiben: SMTP, IMAP, SPF, DKIM, DMARC und Verschlüsselung

E-Mail-Dienste sicher betreiben: SMTP, IMAP, SPF, DKIM, DMARC und Verschlüsselung

https://bildung.social/@oerinformatik/

https://oer-informatik.de/e-mail-dienste

E-Mail, Mailserver, SMTP, IMAP, POP3, STARTTLS, SPF, DKIM, DMARC, Phishing, S/MIME, Ende-zu-Ende-Verschlüsselung

tl/dr; (ca. 23 min Lesezeit): E-Mail ist alt, offen und gerade deshalb ein beliebtes Einfallstor für Angriffe. Du lernst, welche Stationen eine E-Mail vom Absender bis ins Postfach durchläuft und welche Aufgaben SMTP, IMAP und POP3 dabei übernehmen. Danach geht es um die richtige Einrichtung von Mailprogrammen (Ports, STARTTLS, Anmeldeverfahren), um die Absenderprüfung mit SPF, DKIM und DMARC, um Spam- und Phishingschutz am Mailserver und um den Unterschied zwischen Transport- und Ende-zu-Ende-Verschlüsselung mit S/MIME und OpenPGP. Eine Tabelle typischer Fehlerbilder hilft Dir, Zustellprobleme systematisch einzugrenzen [AI-Assisted]. (Zuletzt geändert am 28.10.2026)

Dieser Artikel ist Teil einer Artikelreihe zu Netzwerkdiensten und IT-Sicherheit: DHCP, DNS und ARP / Kryptografie / Angriffe und Schadsoftware / E-Mail-Dienste / Übungsaufgaben zu E-Mail-Diensten

Schon fit in diesem Thema? Nutze die Kann-Liste und die Leitfragen unter dem Artikel als Checkliste, ob Du die relevanten Kompetenzen bereits hast. Hier klicken, um Kann-Liste ein- oder auszublenden

Dieser Artikel baut auf der Kann-Liste des Artikels Kryptografie auf.

Als Grundlagen zum Betrieb von E-Mail-Diensten kann ich nach Durchlesen des Artikels…

• … den Weg einer E-Mail über Mailprogramm, Mailserver des Absenders, DNS und Mailserver des Empfängers beschreiben und die Rolle des MX-Eintrags erläutern.

• … die Aufgaben von SMTP, IMAP und POP3 erläutern, Vorteile von IMAP gegenüber POP3 begründen und die üblichen Ports mit und ohne Verschlüsselung zuordnen.

• … ein Mailprogramm passend zum Server einrichten: Protokoll, Port, Verbindungssicherheit (keine, STARTTLS, SSL/TLS) und Authentifizierungsmethode aus einer Server-Antwort bestimmen.

• … SMTP-Statuscodes (2xx, 4xx, 5xx) deuten und Ursachen für Meldungen wie „Authentifizierung erforderlich“ oder „Absender blockiert“ benennen.

• … Spam und Phishing unterscheiden und technische sowie organisatorische Schutzmaßnahmen am Mailserver beschreiben.

• … Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung unterscheiden und S/MIME und OpenPGP als Verfahren nennen.

Darüber hinaus kann ich als Expertenwissen…

• … erläutern, wie SPF, DKIM und DMARC die Absenderdomain absichern, wo die Einträge stehen und welche Angaben sie enthalten.

• … einen SPF-Eintrag lesen und so ergänzen, dass weitere berechtigte Systeme (z. B. ein Newsletter-Dienst oder ein Shop-Server) Mails für die Domain versenden dürfen.

• … Gründe für fehlgeschlagene DKIM- oder SPF-Prüfungen nennen und eine DMARC-Richtlinie schrittweise einführen.

• … S/MIME und OpenPGP anhand von Vertrauensmodell, Schlüsselverwaltung und Verbreitung vergleichen und begründet auswählen.

• … Zustellprobleme anhand von DNS-Einträgen, Logzeilen und Fehlermeldungen systematisch eingrenzen.

Eine Bestellbestätigung landet bei einer Kundin im Spamordner, die Werkstatt bekommt keine Mails von Lieferanten mehr, und im Postfach der Buchhaltung liegt eine täuschend echte Rechnung mit Schadsoftware im Anhang. Hinter allen drei Fällen steckt dieselbe Frage: Wie betreibst Du E-Mail so, dass Mails zuverlässig ankommen, nicht mitgelesen werden und gefälschte Absender auffallen?

Die Mindmap gibt einen Überblick über die Themen dieses Artikels: vom Weg einer E-Mail über Protokolle und die Einrichtung von Mailprogrammen bis zur Absenderprüfung, Verschlüsselung und Fehlersuche.

Der Weg einer E-Mail

Eine E-Mail wird nicht direkt vom Gerät der Absenderin auf das Gerät des Empfängers übertragen, sondern von Server zu Server weitergereicht. Die beteiligten Rollen haben eigene Namen:

Der Mailserver der Absenderin erfährt aus dem MX-Eintrag (Mail Exchanger) im DNS, welcher Server Mails für die Empfängerdomain annimmt. Gibt es mehrere MX-Einträge, wird der mit dem kleinsten Prioritätswert (Preference) zuerst versucht. Der Zielname des MX-Eintrags muss selbst einen A- oder AAAA-Eintrag haben; er darf weder eine IP-Adresse noch ein CNAME sein. Fehlt der A-Eintrag des Mailservers oder zeigt er auf eine falsche Adresse, kann die Domain keine Mails von außen empfangen, obwohl der MX-Eintrag vorhanden ist. Mehr zu DNS-Einträgen findest Du im Artikel DHCP, DNS und ARP.

Wichtig für das Verständnis der Absenderprüfung: Eine E-Mail hat zwei Absenderangaben.

• Der Umschlag-Absender (Envelope From, SMTP-Befehl MAIL FROM) gilt nur für den Transport. An diese Adresse gehen Unzustellbarkeitsmeldungen.

• Der Kopf-Absender (From: im Mail-Header) ist das, was das Mailprogramm anzeigt.

SMTP prüft keine der beiden Angaben. Jeder Server kann also behaupten, im Auftrag einer beliebigen Domain zu senden – genau das nutzen Spam und Phishing aus.

SMTP, IMAP und POP3

Protokolle und Ports von E-Mail-Diensten

Protokoll	Aufgabe	Port ohne TLS bzw. mit STARTTLS	Port mit TLS ab Verbindungsbeginn
SMTP (Server zu Server)	Mails zwischen Mailservern weiterleiten	25	– (zwischen Servern nur STARTTLS)
SMTP-Submission	Mails vom Mailprogramm an den eigenen Server übergeben, mit Anmeldung	587	465 („SMTPS“)
IMAP	Mails auf dem Server lesen, in Ordnern verwalten, zwischen Geräten synchronisieren	143	993 („IMAPS“)
POP3	Mails vom Server abholen, meist mit anschließendem Löschen auf dem Server	110	995 („POP3S“)

SMTP (Simple Mail Transfer Protocol) ist nur für das Senden und Weiterleiten zuständig. Abgeholt bzw. gelesen werden Mails mit IMAP (Internet Message Access Protocol, aktuell IMAP4rev2) oder POP3 (Post Office Protocol).

Vorteile von IMAP gegenüber POP3:

• Die Mails bleiben auf dem Server und werden mit allen Geräten synchronisiert: Was am Laptop gelesen, verschoben oder gelöscht wird, ist auch am Smartphone so.

• Ordner, Markierungen und Suche werden auf dem Server verwaltet; das Postfach wird zentral gesichert.

• Beim Abruf müssen nicht alle Mails vollständig heruntergeladen werden, zunächst reichen die Kopfzeilen.

POP3 ist einfacher und braucht weniger Speicher auf dem Server, eignet sich aber nur, wenn ein Postfach an genau einem Gerät genutzt wird.

Ein Mailserver, der von beliebigen Absender*innen Mails an beliebige Empfänger*innen weiterleitet, heißt offenes Relay; er wird schnell von Spammern missbraucht und landet auf Sperrlisten. Deshalb nimmt ein Mailserver Mails an fremde Domains nur von angemeldeten Nutzenden an (SMTP-AUTH auf dem Submission-Port). Wer im Mailprogramm die Anmeldung für den Postausgangsserver vergisst, erhält eine Meldung wie 530 5.7.0 Authentication required.

SMTP-Statuscodes lesen

SMTP-Server antworten mit dreistelligen Codes, oft ergänzt um einen erweiterten Code (z. B. 5.7.1):

Klassen von SMTP-Statuscodes

Code	Bedeutung	Beispiele
2xx	erfolgreich	250 OK, 220 Begrüßung
3xx	weitere Eingaben erwartet	354 Mailinhalt senden
4xx	vorübergehender Fehler, der Absender-Server versucht es später erneut	421 Dienst nicht verfügbar, 450 Postfach vorübergehend nicht verfügbar, Greylisting
5xx	dauerhafter Fehler, die Mail wird abgelehnt und eine Unzustellbarkeitsmeldung erzeugt	530 Anmeldung erforderlich, 550 Postfach unbekannt oder Richtlinie verletzt, 554 5.7.1 Absender oder Inhalt blockiert

Der erweiterte Code 5.7.x steht immer für ein Sicherheits- oder Richtlinienproblem: fehlende Anmeldung, Sperrliste, fehlgeschlagene SPF-, DKIM- oder DMARC-Prüfung. Der Text hinter dem Code nennt meist den Grund.

Mailprogramme richtig einrichten

Für den Posteingangs- und den Postausgangsserver brauchst Du jeweils Protokoll, Servername, Port, Verbindungssicherheit und Authentifizierungsmethode:

• Keine Verbindungssicherheit: Alles, auch das Passwort, geht im Klartext übers Netz. Nur für Tests im Labor.

• STARTTLS: Die Verbindung beginnt unverschlüsselt auf dem normalen Port (143, 110, 587). Mit dem Befehl STARTTLS wird sie auf TLS umgestellt, bevor angemeldet wird.

• SSL/TLS (implizites TLS): Die Verbindung ist ab dem ersten Byte verschlüsselt (Ports 993, 995, 465). RFC 8314 empfiehlt diese Variante für Mailprogramme, weil ein Angreifer im Netz den STARTTLS-Befehl unterdrücken könnte (Downgrade).

Welche Verfahren ein Server anbietet, verrät seine Begrüßung bzw. die Liste seiner Fähigkeiten (Capabilities). Eine Testverbindung, z. B. mit telnet oder besser mit openssl s_client, liefert bei einem IMAP-Server etwa:

$ telnet imap.beispiel.example 143
* OK [CAPABILITY IMAP4rev1 IMAP4rev2 STARTTLS LOGINDISABLED] Mailserver bereit
a1 STARTTLS
a1 OK Begin TLS negotiation now
(nach dem TLS-Aufbau)
a2 CAPABILITY
* CAPABILITY IMAP4rev1 IMAP4rev2 AUTH=PLAIN AUTH=LOGIN AUTH=XOAUTH2

So liest Du die Ausgabe:

• Antwort mit * OK auf Port 143 → IMAP.

• STARTTLS wird angeboten, LOGINDISABLED verbietet die Anmeldung, solange die Verbindung unverschlüsselt ist → Verbindungssicherheit STARTTLS (Port 143) oder, falls der Server Port 993 anbietet, SSL/TLS.

• AUTH=PLAIN und AUTH=LOGIN übertragen Benutzername und Passwort zwar nur Base64-codiert, durch den TLS-Tunnel aber geschützt. Im Mailprogramm heißt das meist „Passwort, normal“. Bietet der Server AUTH=CRAM-MD5 an, passt „verschlüsseltes Passwort“ (heute veraltet; über TLS ist „Passwort, normal“ vorzuziehen); AUTH=GSSAPI steht für Kerberos (Anmeldung in einer Domäne), AUTH=XOAUTH2 für OAuth2 (Anmeldung über einen Identitätsanbieter, z. B. bei großen Cloud-Postfächern).

Stellst Du im Mailprogramm eine Methode ein, die der Server nicht anbietet, scheitert die Anmeldung trotz richtigem Passwort.

Absender absichern: SPF, DKIM und DMARC

Weil SMTP Absenderangaben nicht prüft, veröffentlicht der Inhaber einer Domain im DNS, woran Empfänger echte Mails seiner Domain erkennen. Die drei Verfahren ergänzen sich:

SPF: Welche Server dürfen senden?

Ein SPF-Eintrag zählt die berechtigten Absender-Server auf und endet mit einer Regel für alle anderen:

beispiel.example.  TXT  "v=spf1 mx a:shop.beispiel.example ip4:198.51.100.20 include:_spf.newsletter.example -all"

Bestandteile eines SPF-Eintrags

Bestandteil	Bedeutung
v=spf1	Version, Pflicht am Anfang
mx	die Server aus den MX-Einträgen der Domain dürfen senden
a:shop.beispiel.example	der Server mit diesem Namen (A/AAAA-Eintrag) darf senden
ip4:198.51.100.20 bzw. ip6:…	diese Adresse oder dieses Netz darf senden
include:_spf.newsletter.example	alle Server, die der SPF-Eintrag des Dienstleisters erlaubt, dürfen senden
-all	alle anderen Server sind nicht berechtigt (fail); ~all = verdächtig (softfail), ?all = keine Aussage

Der empfangende Server prüft die IP-Adresse des einliefernden Servers gegen diese Liste. Typische Fehler:

• Ein neuer Dienst, der im Namen der Domain sendet (Newsletter-Dienstleister, Shop-Server, Ticketsystem, Drucker mit Scan-to-Mail), fehlt im Eintrag. Seine Mails werden bei -all abgelehnt.

• Es gibt mehr als einen SPF-Eintrag für die Domain – dann ist SPF ungültig (permerror). Es darf nur einen geben.

• Zu viele verschachtelte include: und a/mx-Mechanismen: Mehr als 10 DNS-Abfragen machen den Eintrag ungültig.

• Bei einer Weiterleitung sendet ein fremder Server weiter und besteht die SPF-Prüfung nicht mehr. Hier hilft DKIM, denn die Signatur reist mit der Mail.

DKIM: Die Signatur der Domain

Der Mailserver der Absenderin bildet einen Hashwert über ausgewählte Header-Felder und den Inhalt, signiert ihn mit dem privaten Schlüssel der Domain und fügt das Ergebnis als Header-Feld DKIM-Signature ein. Dort stehen u. a. die signierende Domain (d=), der Selektor (s=), das Verfahren (a=rsa-sha256 oder ed25519-sha256), der Hash des Inhalts (bh=) und die Signatur (b=):

DKIM-Signature: v=1; a=rsa-sha256; d=beispiel.example; s=mail2026;
  h=from:to:subject:date; bh=Gr3b...; b=Kx9f...

Der Empfänger holt den öffentlichen Schlüssel per DNS unter mail2026._domainkey.beispiel.example und prüft die Signatur. Über den Selektor kann eine Domain mehrere Schlüssel gleichzeitig veröffentlichen, z. B. für einen Schlüsselwechsel oder für einen externen Dienstleister.

Gründe für DKIM verification failed bzw. dkim=fail:

• Die Mail wurde nach dem Signieren verändert, z. B. durch einen Signatur- oder Haftungshinweis, den ein Gateway anhängt, durch eine Mailingliste, die den Betreff ergänzt, oder durch einen Virenscanner (body hash did not verify).

• Der öffentliche Schlüssel fehlt im DNS, ist falsch kopiert (abgeschnittener TXT-Eintrag) oder wurde beim Schlüsselwechsel zu früh gelöscht.

• Kein dkim=fail, aber für DMARC ebenso wertlos: Die Signatur fehlt ganz (dkim=none) oder die signierende Domain (d=) passt nicht zur Absenderdomain im From:.

DMARC: Richtlinie und Berichte

SPF und DKIM prüfen jeweils „irgendeine“ Domain – SPF die des Umschlags, DKIM die aus d=. Ein Angreifer könnte also mit eigener, korrekt eingerichteter Domain senden und im sichtbaren From: eine fremde Domain eintragen. DMARC schließt diese Lücke: Eine Mail besteht die Prüfung nur, wenn SPF oder DKIM erfolgreich ist und die geprüfte Domain zur Domain im From: passt (Alignment).

_dmarc.beispiel.example.  TXT  "v=DMARC1; p=none; rua=mailto:dmarc-berichte@beispiel.example"

• p=none: nur beobachten, Mails werden normal zugestellt, Berichte kommen an rua.
• p=quarantine: Mails, die die Prüfung nicht bestehen, in den Spamordner.
• p=reject: solche Mails ablehnen.

Das Aktivitätsdiagramm zeigt, wie der empfangende Server SPF, DKIM und die DMARC-Richtlinie zusammen auswertet:

Eingeführt wird DMARC schrittweise: Erst mit p=none und Berichten herausfinden, welche Systeme im Namen der Domain senden, diese in SPF aufnehmen bzw. mit DKIM signieren lassen, dann auf quarantine und schließlich reject umstellen. Große Mailanbieter verlangen seit 2024 von Massenversendern SPF, DKIM und einen DMARC-Eintrag. Seit der Neufassung in RFC 9989 (2026) wird die frühere Angabe pct= (nur einen Prozentsatz der Mails prüfen) von Empfängern ignoriert; für Tests gibt es t=y (die Richtlinie wird dann eine Stufe milder angewendet, z. B. reject wie quarantine).

Spam und Phishing abwehren

Spam sind unerwünschte Massenmails, meist Werbung. Sie kosten Zeit und Speicher, sind aber nicht zwingend gefährlich. Phishing ist dagegen Betrug: Eine Mail gibt sich als vertrauenswürdige Stelle aus (Bank, Paketdienst, eigene IT-Abteilung, Geschäftsführung), um Zugangsdaten oder Zahlungen zu erschleichen oder Schadsoftware einzuschleusen. Gezieltes Phishing an einzelne Personen heißt Spear-Phishing. Woran Du Phishing erkennst, erklärt der Artikel Angriffe und Schadsoftware.

Schutzmaßnahmen am Mailserver und im Unternehmen:

Schutzmaßnahmen gegen Spam und Phishing

Maßnahme	Wirkung
SPF-, DKIM- und DMARC-Prüfung eingehender Mails	gefälschte Absender bekannter Domains werden erkannt
Sperrlisten (DNS-based Blocklists, eigene Listen von Domains oder Adressen)	Mails von bekannten Spam-Quellen werden abgelehnt (554 5.7.1 … blocked)
Greylisting	unbekannte Absender werden zunächst mit 4xx vertröstet; echte Server versuchen es erneut, viele Spam-Programme nicht
Inhalts- und Virenfilter, Sandbox für Anhänge	Schadsoftware wird erkannt, bevor sie das Postfach erreicht
gefährliche Anhänge sperren (z. B. .exe, .js, Office-Dateien mit Makros, verschlüsselte Archive)	häufigster Infektionsweg wird geschlossen
Mails als Text statt HTML anzeigen, Links umschreiben und beim Anklicken prüfen	versteckte Linkziele werden sichtbar bzw. gefiltert
Kennzeichnung externer Mails im Betreff („[EXTERN]“)	gefälschte „interne“ Mails fallen auf
regelmäßige Schulungen, Meldeknopf für verdächtige Mails	Beschäftigte erkennen Phishing und melden es

Steht ein Absender zu Unrecht auf einer Sperrliste, erhält er eine Unzustellbarkeitsmeldung mit dem Namen der Liste. Abhilfe: Ursache beim Absender beseitigen (z. B. ein gekapertes Konto, ein offenes Relay) und die Löschung bei der Liste beantragen, bzw. – wenn die Sperre im eigenen Filter liegt – den Absender dort freigeben.

Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung

Bei der Transportverschlüsselung (TLS bzw. STARTTLS) wird jede Teilstrecke einzeln verschlüsselt: Mailprogramm → eigener Server, Server → Server, Server → Mailprogramm. Auf den Servern selbst liegt die Mail im Klartext. Wer einen beteiligten Server kontrolliert oder einen Man-in-the-Middle-Angriff auf eine ungesicherte Teilstrecke schafft, kann sie lesen oder verändern. Zwischen Mailservern ist STARTTLS zudem meist nur opportunistisch: Bietet die Gegenseite kein TLS an, wird unverschlüsselt übertragen. Mit MTA-STS (RFC 8461) oder DANE (TLSA-Einträge im DNS, abgesichert mit DNSSEC) kann eine Domain verlangen, dass Mails an sie nur verschlüsselt und an den richtigen Server zugestellt werden.

Bei der Ende-zu-Ende-Verschlüsselung wird die Mail selbst im Mailprogramm der Absenderin verschlüsselt und erst im Mailprogramm des Empfängers entschlüsselt. Kein Server unterwegs kann den Inhalt lesen. Signiert die Absenderin zusätzlich, sind Integrität und Authentizität gesichert. Die Kopfzeilen (Absender, Empfänger, meist auch der Betreff) bleiben aber lesbar, weil die Server sie für den Transport brauchen.

Beide Verfahren arbeiten hybrid: Der Inhalt wird mit einem zufälligen symmetrischen Schlüssel verschlüsselt, dieser mit dem öffentlichen Schlüssel des Empfängers. Signiert wird mit dem eigenen privaten Schlüssel. Welcher Schlüssel wann gebraucht wird, zeigt der Artikel Kryptografie.

S/MIME und OpenPGP im Vergleich

	S/MIME	OpenPGP
Schlüssel	X.509-Zertifikat mit öffentlichem Schlüssel, ausgestellt von einer Zertifizierungsstelle (CA)	Schlüsselpaar, selbst erzeugt
Vertrauensmodell	hierarchisch: Wer der CA vertraut, vertraut dem Zertifikat	Netz des Vertrauens (Web of Trust) oder Vergleich des Fingerabdrucks; Schlüsselserver
Unterstützung	in Outlook, Apple Mail, vielen Mobil-Apps eingebaut	in Thunderbird eingebaut, sonst Zusatzprogramme
Kosten und Aufwand	Zertifikate meist kostenpflichtig, laufen ab (höchstens 825 Tage, meist 1–2 Jahre), zentral verwaltbar	kostenlos, Schlüsselverwaltung liegt bei den Nutzenden
typischer Einsatz	Unternehmen, Behörden, Verbindung mit einer Firmen-PKI	Privatpersonen, Entwicklerteams, Open-Source-Projekte

Praktische Stolpersteine der Ende-zu-Ende-Verschlüsselung: Der private Schlüssel muss auf jedem Gerät vorhanden sein, auf dem gelesen werden soll; ist er verloren, sind alle damit verschlüsselten Mails unlesbar (Schlüssel sichern bzw. hinterlegen). Abgelaufene oder gesperrte Zertifikate führen zu Warnungen. Und Virenfilter am Server können verschlüsselte Anhänge nicht prüfen.

Typische Fehlerbilder und ihre Ursachen

Typische Fehlerbilder bei E-Mail-Diensten

Fehlerbild	wahrscheinliche Ursache	Prüfen bzw. beheben
Die Domain empfängt keine Mails von außen	MX-Eintrag fehlt, zeigt auf einen Namen ohne A-Eintrag oder auf einen nicht erreichbaren Server; Port 25 in der Firewall gesperrt	DNS-Einträge (MX, A) abfragen, Portfreigabe prüfen
Mails eines Dienstleisters im Namen der Domain werden abgelehnt oder landen im Spam	Server des Dienstleisters fehlt im SPF-Eintrag, keine DKIM-Signatur für die Domain	SPF um include:/ip4: ergänzen, DKIM beim Dienstleister einrichten
dkim=fail, Mail im Spamordner	Mail nach dem Signieren verändert, öffentlicher Schlüssel fehlt oder ist falsch	Header-Feld Authentication-Results lesen, DNS-Eintrag zum Selektor prüfen
530 5.7.0 Authentication required beim Senden	SMTP-AUTH im Mailprogramm nicht aktiviert	Anmeldung für den Postausgangsserver einschalten
554 5.7.1 … blocked	Absender, Domain oder IP-Adresse steht auf einer Sperrliste	Ursache beseitigen, Löschung beantragen bzw. eigenen Filter anpassen
Mailprogramm meldet Zertifikatsfehler oder Verbindung scheitert	falscher Port zur gewählten Verbindungssicherheit, Zertifikat abgelaufen oder für anderen Namen ausgestellt	Port und Verbindungssicherheit abgleichen, Zertifikat erneuern
Adresse mit Umlauten kommt nicht an	Domain mit Umlauten muss als Punycode (xn--…) übertragen werden; Umlaute im lokalen Teil (vor dem @) setzen SMTPUTF8 voraus, das nicht alle Server und Programme können; ausländische Tastaturen	Adressen ohne Umlaute vergeben (ue statt ü), Umlaut-Domain höchstens zusätzlich

Bei der Fehlersuche hilft der Quelltext der Mail: Das Header-Feld Authentication-Results zeigt, wie der empfangende Server SPF, DKIM und DMARC bewertet hat (spf=pass, dkim=fail, dmarc=fail), und die Received:-Zeilen zeigen von unten nach oben den Weg der Mail.

Leitfragen

1. Welche Stationen durchläuft eine E-Mail, und wozu dient dabei der MX-Eintrag? Antwort

Das Mailprogramm übergibt die Mail per SMTP-Submission an den eigenen Mailserver. Dieser fragt im DNS den MX-Eintrag der Empfängerdomain ab, um den zuständigen Mailserver zu finden, und liefert per SMTP an ihn. Der Server des Empfängers legt die Mail im Postfach ab, aus dem sie per IMAP oder POP3 gelesen wird; siehe Abschnitt „Der Weg einer E-Mail“.

2. Warum ist IMAP für die meisten Postfächer besser geeignet als POP3? Antwort

Bei IMAP bleiben Mails und Ordner auf dem Server und werden mit allen Geräten synchronisiert; das Postfach wird zentral gesichert. POP3 holt Mails meist auf ein einzelnes Gerät und löscht sie auf dem Server; siehe Abschnitt „SMTP, IMAP und POP3“.

3. Worin unterscheiden sich STARTTLS und SSL/TLS bei der Einrichtung eines Mailprogramms? Antwort

Bei STARTTLS beginnt die Verbindung unverschlüsselt auf dem Standardport (143, 110, 587) und wird per Befehl auf TLS umgestellt; bei SSL/TLS ist sie ab Beginn verschlüsselt (993, 995, 465). Implizites TLS ist sicherer gegen Downgrade-Angriffe; siehe Abschnitt „Mailprogramme richtig einrichten“.

4. Was prüfen SPF, DKIM und DMARC jeweils, und wo stehen die Einträge? Antwort

SPF prüft, ob der einliefernde Server für die Domain des Umschlag-Absenders senden darf (TXT-Eintrag der Domain). DKIM prüft eine Signatur der Domain über Header und Inhalt; der öffentliche Schlüssel steht unter <selektor>._domainkey.<domain>, die Signatur im Header-Feld DKIM-Signature. DMARC verlangt, dass SPF oder DKIM zur Domain im From: passt, und legt fest, was bei einem Fehlschlag passiert (_dmarc.<domain>); siehe Abschnitt „Absender absichern: SPF, DKIM und DMARC“.

5. Ein externer Newsletter-Dienst versendet Mails mit Deiner Domain als Absender, die bei vielen Empfängern abgelehnt werden. Woran liegt das vermutlich? Antwort

Der Server des Dienstleisters ist im SPF-Eintrag nicht als berechtigter Absender aufgeführt; bei -all lehnen Empfänger seine Mails ab. Der Eintrag muss z. B. um include: des Dienstleisters ergänzt werden, außerdem sollte der Dienst mit DKIM für die Domain signieren; siehe Abschnitt „SPF: Welche Server dürfen senden?“.

6. Wie unterscheiden sich Spam und Phishing, und welche Maßnahmen schützen dagegen? Antwort

Spam sind unerwünschte Massenmails, Phishing ist Betrug, bei dem sich eine Mail als vertrauenswürdige Stelle ausgibt, um Daten, Zahlungen oder eine Infektion zu erreichen. Dagegen helfen Absenderprüfung, Sperrlisten, Greylisting, Virenfilter und Sandbox, gesperrte Anhänge, Textanzeige statt HTML und geschulte Beschäftigte; siehe Abschnitt „Spam und Phishing abwehren“.

7. Warum reicht Transportverschlüsselung für vertrauliche Inhalte nicht immer aus? Antwort

TLS schützt nur die einzelnen Teilstrecken. Auf den Mailservern liegt die Mail im Klartext, und zwischen Servern wird oft nur opportunistisch verschlüsselt. Ende-zu-Ende-Verschlüsselung mit S/MIME oder OpenPGP schützt den Inhalt dagegen vom Mailprogramm der Absenderin bis zum Mailprogramm des Empfängers; siehe Abschnitt „Transportverschlüsselung und Ende-zu-Ende-Verschlüsselung“.

8. Wie gehst Du vor, wenn eine Mail nicht ankommt? Antwort

Fehlermeldung und Statuscode lesen (4xx vorübergehend, 5xx dauerhaft, 5.7.x Sicherheit/Richtlinie), DNS-Einträge (MX, A, SPF, DKIM, DMARC) prüfen, im Header Authentication-Results und Received: auswerten und Logs der Mailserver ansehen; siehe Abschnitt „Typische Fehlerbilder und ihre Ursachen“.

Links und weitere Informationen

• Übungen: Übungsaufgaben zu E-Mail-Diensten

• Voraussetzung: Kryptografie, DHCP, DNS und ARP

• weiterführend: Angriffe und Schadsoftware, Firewall und DMZ, Systemhärtung

• als Nachschlagewerk: BSI TR-03108 „Sicherer E-Mail-Transport“ (Technische Richtlinien auf bsi.bund.de), RFC 5321 – SMTP, RFC 8314 – Cleartext Considered Obsolete, RFC 7208 – SPF, RFC 6376 – DKIM, RFC 9989 – DMARC, RFC 8461 – MTA-STS

---

Hinweis zur Nachnutzung als Open Educational Resource (OER)

Dieser Artikel und seine Texte, Bilder, Grafiken, Code und sonstiger Inhalt sind - sofern nicht anders angegeben - lizenziert unter CC BY 4.0. Nennung gemäß TULLU-Regel bitte wie folgt: “E-Mail-Dienste sicher betreiben: SMTP, IMAP, SPF, DKIM, DMARC und Verschlüsselung” von oer-informatik.de (H. Stein), Lizenz: CC BY 4.0. Der Artikel wurde unter https://oer-informatik.de/e-mail-dienste veröffentlicht, die Quelltexte sind in weiterverarbeitbarer Form verfügbar im Repository unter https://gitlab.com/oer-informatik/it-sicherheit/schutzmassnahmen. Erstellt mit KI-Assistenz; von mir umfassend redaktionell überarbeitet, geprüft und freigegeben. Stand: 28.10.2026.

[Kommentare zum Artikel lesen, schreiben] / [Artikel teilen] / [gitlab-Issue zum Artikel schreiben]