Wie E-Mail funktioniert: Ein vollständiger technischer Leitfaden zu Protokollen, Schritten und Architektur

E-Mail bleibt das Rückgrat der digitalen Kommunikation für Unternehmen und Privatpersonen, obwohl die zugrunde liegenden Mechanismen von den meisten Nutzern kaum verstanden werden. Im Kern ist die E-Mail-Zustellung ein mehrstufiger Weiterleitungsprozess, der durch eine präzise Protokollkette gesteuert wird — SMTP für die Übertragung, DNS MX-Records für das Routing und IMAP oder POP3 für den Abruf — wobei jede Komponente nacheinander ausgeführt wird, um eine Nachricht in Sekunden vom Client des Absenders in den Posteingang des Empfängers zu befördern.

Das Verständnis dieser Architektur ist nicht nur akademischer Natur. Systemadministratoren, Entwickler und alle, die eine Mail-Umgebung verwalten, müssen verstehen, wie diese Komponenten zusammenwirken, um Zustellungsfehler zu diagnostizieren, die Sicherheit zu stärken, Server korrekt zu konfigurieren und den Spam-Ordner zu vermeiden. Dieser Leitfaden behandelt das vollständige technische Bild, einschließlich der Sonderfälle und Fehlermodi, die in einführenden Artikeln regelmäßig ausgelassen werden.

Schlüsselkomponenten der E-Mail-Infrastruktur

Bevor der Lebenszyklus einer einzelnen E-Mail nachverfolgt wird, ist es wichtig, die beteiligten diskreten Systeme zu identifizieren. Jedes spielt eine unverzichtbare Rolle, und eine Fehlkonfiguration in einem von ihnen kann die Zustellung stillschweigend unterbrechen.

E-Mail-Client (MUA — Mail User Agent)

Der Mail User Agent (MUA) ist die Schnittstelle, über die ein Benutzer E-Mails verfasst, sendet und liest. Beispiele sind Microsoft Outlook, Apple Mail, Mozilla Thunderbird und browserbasierte Clients wie die Web-Oberfläche von Gmail. Der MUA stellt E-Mails nicht direkt an den Empfänger zu. Seine Aufgabe ist es, die Nachricht an einen Mail Submission Agent (MSA) weiterzuleiten, der typischerweise auf Port 587 mit Authentifizierung läuft und sie dann an den ausgehenden SMTP-Server weitergibt.

Ein häufiges architektonisches Missverständnis besteht darin, den MUA und den SMTP-Server als eine Einheit zu betrachten. Das sind sie nicht. Der MUA ist ein Client; die SMTP-Infrastruktur ist die Transportschicht.

Mail-Server (MTA — Mail Transfer Agent)

Der Mail Transfer Agent (MTA) ist die Server-Software, die für die Weiterleitung von E-Mails zwischen Systemen verantwortlich ist. Postfix, Exim, Sendmail und Microsoft Exchange sind die am weitesten verbreiteten MTAs. Ein MTA kann je nach Richtung der Transaktion sowohl als Sender als auch als Empfänger fungieren. Es ist der MTA, der DNS-Abfragen durchführt, SMTP-Verbindungen zu entfernten Servern herstellt und Nachrichten zur Wiederholung in die Warteschlange stellt, wenn die Zustellung fehlschlägt.

Mail Delivery Agent (MDA)

In vereinfachten Erklärungen oft übersehen, ist der Mail Delivery Agent (MDA) die Komponente, die eine vom empfangenden MTA akzeptierte Nachricht entgegennimmt und sie in das korrekte Postfach des Benutzers auf dem Datenträger ablegt. Dovecot und Courier sind gängige MDAs. Der MDA setzt Postfachkontingente durch, wendet serverseitige Filterregeln (Sieve-Skripte) an und schreibt die Nachricht in das entsprechende Speicherformat (Maildir oder mbox).

DNS und MX-Records

Das Domain Name System ist das Routing-Rückgrat der E-Mail. Ohne einen gültigen MX (Mail Exchange) Record kann kein externer Server ermitteln, wohin E-Mails für eine bestimmte Domain zugestellt werden sollen. MX-Records tragen einen Prioritätswert — niedrigere Zahlen bedeuten höhere Priorität — was Administratoren ermöglicht, primäre und Fallback-Mailserver zu konfigurieren. Der sendende MTA fragt MX-Records ab, löst dann den resultierenden Hostnamen über einen A- oder AAAA-Record in eine IP-Adresse auf, bevor er eine Verbindung herstellt.

Der E-Mail-Zustellungsprozess: Schritt für Schritt

Schritt 1: Nachrichtenverfassung und -übermittlung

Der Benutzer schreibt eine Nachricht in seinem MUA und gibt die Empfängeradresse, die Betreffzeile, den Nachrichtentext und eventuelle Anhänge an. Anhänge und HTML-Inhalte werden mit MIME (Multipurpose Internet Mail Extensions) kodiert, das Binärdaten in ein base64-kodiertes Format einbettet, das für die Übertragung über textbasiertes SMTP geeignet ist. Eine Nachricht mit einem PDF-Anhang wird beispielsweise in mehrere MIME-Teile aufgeteilt: einen für den Textkörper und einen für die kodierte Binärdatei.

Wenn der Benutzer auf „Senden” klickt, öffnet der MUA eine authentifizierte, verschlüsselte Verbindung zum ausgehenden Mailserver — typischerweise auf Port 587 (STARTTLS) oder Port 465 (SMTPS). Die Authentifizierung über SASL (Simple Authentication and Security Layer) verhindert unbefugten Relay-Missbrauch.

Schritt 2: SMTP-Handshake und Nachrichtenübertragung

Der sendende MTA initiiert eine SMTP-Sitzung mit einem formellen Handshake:

1. Der Client sendet `EHLO` (Extended HELO) und identifiziert sich durch seinen Hostnamen.
2. Der Server antwortet mit seinen Fähigkeiten (z. B. STARTTLS, AUTH, SIZE-Limits).
3. Der Client gibt `MAIL FROM:<sender@domain.com>` aus, um den Envelope-Absender zu deklarieren.
4. Der Client gibt `RCPT TO:<recipient@domain.com>` aus, um den Empfänger zu deklarieren.
5. Der Client sendet `DATA`, gefolgt von den vollständigen Nachrichten-Headern und dem Nachrichtentext.
6. Die Sitzung wird mit `QUIT` beendet.

Dieser SMTP-Dialog ist derselbe, unabhängig davon, ob die Verbindung zwischen einem Client und seinem Submission-Server oder zwischen zwei MTAs besteht, die E-Mails über das Internet weiterleiten.

Schritt 3: DNS-Auflösung und MX-Abfrage

Bevor der sendende MTA eine Verbindung zum Server des Empfängers herstellen kann, muss er das Ziel auflösen. Der Prozess folgt einer strikten Reihenfolge:

1. DNS nach MX-Records der Domain des Empfängers abfragen (z. B. `example.com`).
2. Einen oder mehrere MX-Records mit einem Hostnamen und einem Prioritätswert empfangen.
3. Den MX-Hostnamen über einen A-Record (IPv4) oder AAAA-Record (IPv6) in eine IP-Adresse auflösen.
4. Verbindung zum MX-Host mit der höchsten Priorität (niedrigste Zahl) zuerst versuchen.

Kritischer Sonderfall: Wenn kein MX-Record für eine Domain existiert, legt RFC 5321 fest, dass der sendende MTA auf den A-Record der Domain zurückgreifen und die Zustellung direkt versuchen sollte. Dieses Verhalten wird häufig bei falsch konfigurierten Domains ausgenutzt und kann zu unerwarteten Zustellungspfaden führen. Wenn der MX-Record auf einen CNAME zeigt, verstößt dies außerdem gegen RFC 2181 und kann bei strikten MTAs zu Zustellungsfehlern führen.

Schritt 4: Server-zu-Server SMTP-Relay

Sobald die IP-Adresse aufgelöst ist, stellt der sendende MTA eine TCP-Verbindung auf Port 25 zum MTA des Empfängers her. Port 25 ist für die Server-zu-Server-Kommunikation reserviert und wird von ISPs für Privatanschlüsse typischerweise gesperrt, um Spam aus Consumer-IP-Bereichen zu verhindern.

In Unternehmens- und Cloud-Umgebungen kann eine E-Mail mehrere Relay-Hops durchlaufen, bevor sie ihr Ziel erreicht. Jedes Relay fügt der Nachricht einen `Received:`-Header hinzu und erstellt so einen nachvollziehbaren Prüfpfad. Die Untersuchung dieser Header ist die primäre Methode zur Diagnose von Zustellungsverzögerungen und zur Identifizierung, wo eine Nachricht gehalten oder abgelehnt wurde.

Opportunistische STARTTLS-Verschlüsselung wird in dieser Phase ausgehandelt, wenn beide Server sie unterstützen. Wenn der empfangende Server STARTTLS nicht ankündigt, fallen die meisten MTAs auf unverschlüsselte Übertragung zurück, anstatt die Zustellung zu verweigern — eine bekannte Sicherheitsschwäche, die MTA-STS (Mail Transfer Agent Strict Transport Security) durch die Erzwingung verschlüsselter Verbindungen beheben soll.

Schritt 5: Annahme, Filterung und Spam-Bewertung

Wenn der empfangende MTA die Nachricht akzeptiert, wird sie nicht sofort in den Posteingang des Benutzers gelegt. Eine Reihe von Prüfungen findet statt:

• SPF (Sender Policy Framework): Der empfangende Server fragt den DNS der Absender-Domain nach einem TXT-Record ab, der autorisierte sendende IP-Adressen auflistet. Wenn die sendende IP nicht aufgeführt ist, schlägt die SPF-Prüfung fehl.
• DKIM (DomainKeys Identified Mail): Der sendende Server signiert die Nachrichten-Header und den Nachrichtentext kryptografisch mit einem privaten Schlüssel. Der empfangende Server ruft den entsprechenden öffentlichen Schlüssel aus dem DNS ab und verifiziert die Signatur. Eine gültige DKIM-Signatur beweist, dass die Nachricht während der Übertragung nicht verändert wurde.
• DMARC (Domain-based Message Authentication, Reporting, and Conformance): Verknüpft SPF und DKIM miteinander. Der Domain-Inhaber veröffentlicht eine DMARC-Richtlinie, die festlegt, was mit Nachrichten geschehen soll, die die Authentifizierung nicht bestehen — `none` (nur überwachen), `quarantine` (als Spam markieren) oder `reject` (Nachricht verwerfen). DMARC ermöglicht auch aggregierte und forensische Berichte.

Nach den Authentifizierungsprüfungen durchläuft die Nachricht Inhaltsfilter- und Spam-Bewertungs-Engines (SpamAssassin, Rspamd oder proprietäre Systeme). Punkte werden basierend auf Header-Anomalien, Blacklist-Abfragen (RBLs/DNSBLs), Inhaltsmustern und Absender-Reputation vergeben. Nachrichten, die den Schwellenwert überschreiten, werden in den Junk-Ordner weitergeleitet oder direkt abgelehnt.

Schritt 6: Postfachspeicherung und -abruf

Nachrichten, die alle Filter passieren, werden an den MDA übergeben, der sie in das Postfach des Benutzers schreibt. Die zwei dominanten Speicherformate sind:

• Maildir: Jede Nachricht wird als einzelne Datei in einer Verzeichnisstruktur gespeichert. Bevorzugt wegen seiner Ausfallsicherheit — eine beschädigte Nachricht beeinträchtigt keine anderen.
• mbox: Alle Nachrichten in einem Ordner werden in einer einzigen Datei zusammengefasst. Einfacher, aber anfällig für Beschädigungen und Sperr-Probleme bei gleichzeitigem Zugriff.

Der E-Mail-Client des Empfängers ruft die Nachricht dann entweder über IMAP oder POP3 ab.

Schritt 7: Client-Abruf über IMAP oder POP3

Der letzte Abschnitt der Zustellung ist das Abrufen der Nachricht vom Postfachserver durch den Client. Die Wahl des Protokolls hat erhebliche betriebliche Auswirkungen.

IMAP vs. POP3 vs. SMTP: Protokollvergleich

IMAP ist die richtige Wahl für nahezu alle modernen Deployments. Es hält Nachrichten auf dem Server, synchronisiert den Gelesen/Ungelesen-Status, die Ordnerstruktur und Flags über alle verbundenen Geräte in Echtzeit. Das Löschen einer Nachricht auf einem Smartphone wird sofort im Desktop-Client widergespiegelt.

POP3 lädt Nachrichten auf das lokale Gerät herunter und entfernt sie standardmäßig vom Server. Dies war sinnvoll in der Ära des Einzelgerätezugriffs und begrenztem Serverspeicher, verursacht jedoch ernsthafte Probleme in Multi-Gerät-Umgebungen und eliminiert serverseitige Sicherungen. POP3 sollte für neue Deployments als Legacy-Protokoll betrachtet werden.

E-Mail-Sicherheitsarchitektur: SPF, DKIM und DMARC im Detail

Diese drei Mechanismen bilden einen mehrschichtigen Authentifizierungs-Stack. Die Bereitstellung von nur einem oder zwei von ihnen hinterlässt ausnutzbare Lücken.

SPF — Autorisierung auf Envelope-Ebene

SPF validiert den Envelope-Absender (die `MAIL FROM`-Adresse, die im SMTP-Dialog verwendet wird, nicht den für Benutzer sichtbaren `From:`-Header). Ein typischer SPF-Record sieht so aus:

“`

v=spf1 ip4:203.0.113.0/24 include:_spf.google.com ~all

“`

Der `~all` Softfail erlaubt es, Nachrichten von nicht aufgeführten IPs zu akzeptieren, aber zu markieren. Der `-all` Hardfail weist empfangende Server an, sie direkt abzulehnen. SPF allein schützt nicht den sichtbaren `From:`-Header, den Benutzer tatsächlich sehen — deshalb ist DMARC erforderlich.

DKIM — Kryptografische Nachrichtenintegrität

DKIM signiert einen definierten Satz von Headern (typischerweise `From`, `To`, `Subject`, `Date`) und einen Hash des Nachrichtentexts. Die Signatur wird in einem `DKIM-Signature:`-Header eingebettet. Der Selektor und die Domain in diesem Header verweisen auf einen DNS TXT-Record, der den öffentlichen Schlüssel enthält. Wenn die Nachricht nach der Signierung verändert wird — auch nur ein einzelnes Zeichen im Text — schlägt die Signaturverifizierung fehl.

Wichtiger Betriebshinweis: Mailinglisten-Software und einige Weiterleitungskonfigurationen ändern den Nachrichteninhalt (Anhängen von Fußzeilen, Umschreiben von Headern), was DKIM-Signaturen ungültig macht. Dies ist eine bekannte Interaktion zwischen DKIM und Mailinglisten-Managern, die eine sorgfältige Konfiguration erfordert.

DMARC — Richtliniendurchsetzung und Ausrichtung

DMARC führt das Konzept der Identifier-Ausrichtung ein: Die Domain im `From:`-Header muss entweder mit der SPF-authentifizierten Domain oder der DKIM-signierenden Domain übereinstimmen. Dies schließt die Lücke, die SPF allein offen lässt. Eine `reject`-Richtlinie ist die stärkste Konfiguration:

“`

v=DMARC1; p=reject; rua=mailto:dmarc-reports@example.com; ruf=mailto:forensic@example.com; adkim=s; aspf=s

“`

`adkim=s` und `aspf=s` erzwingen eine strikte Ausrichtung und erfordern eine exakte Domain-Übereinstimmung anstelle einer organisatorischen Domain-Übereinstimmung.

Fortgeschrittene Themen: MTA-STS, DANE und ARC

MTA-STS (Mail Transfer Agent Strict Transport Security)

MTA-STS ermöglicht es einer Domain, über HTTPS eine Richtlinie zu veröffentlichen, die erklärt, dass eingehende Verbindungen TLS verwenden müssen, und gibt an, welche Zertifikate akzeptabel sind. Im Gegensatz zu STARTTLS, das opportunistisch ist und von einem Man-in-the-Middle-Angreifer entfernt werden kann, erzwingt MTA-STS Verschlüsselung. Sendende MTAs, die MTA-STS unterstützen, speichern die Richtlinie im Cache und verweigern die Zustellung an einen Server, der sie nicht erfüllen kann.

DANE (DNS-Based Authentication of Named Entities)

DANE verwendet DNSSEC-signierte TLSA-Records, um ein spezifisches TLS-Zertifikat oder einen öffentlichen Schlüssel an einen Mailserver-Hostnamen zu binden. Dies eliminiert die Abhängigkeit vom kommerziellen Certificate Authority-Vertrauensmodell für die Serverauthentifizierung. Die DANE-Akzeptanz wächst in europäischen Regierungs- und Finanzsektoren, bleibt jedoch in Mainstream-Deployments aufgrund der Voraussetzung von DNSSEC sowohl auf der sendenden als auch auf der empfangenden Domain begrenzt.

ARC (Authenticated Received Chain)

ARC wurde entwickelt, um das Weiterleitungsproblem zu lösen, das DMARC unterbricht. Wenn eine Nachricht über einen Vermittler weitergeleitet wird (z. B. eine Mailingliste oder ein E-Mail-Alias), kann die ursprüngliche SPF- und DKIM-Ausrichtung unterbrochen werden. ARC bewahrt eine Kette authentifizierter `Received:`-Header, sodass der endgültige empfangende Server den Authentifizierungsstatus bei jedem Hop bewerten und eine fundiertere Zustellungsentscheidung treffen kann.

Häufige E-Mail-Zustellungsfehler und Diagnose

Das Verständnis der Architektur macht die Fehlerbehebung systematisch statt spekulativ.

Symptom: E-Mail wird mit „550 5.7.1 Message rejected” zurückgewiesen

• Ursache: SPF-Hardfail, DMARC-Ablehnung oder IP-Blacklisting.
• Diagnose: Überprüfen Sie die Bounce-Nachricht auf den spezifischen Ablehnungsgrund. Führen Sie `dig TXT yourdomain.com` aus, um SPF zu prüfen. Fragen Sie MX Toolbox oder ähnliche Dienste nach dem Blacklist-Status ab.

Symptom: E-Mail wird in den Spam-Ordner zugestellt

• Ursache: SPF-Softfail, fehlendes DKIM, niedrige Absender-Reputation oder Inhaltsauslöser.
• Diagnose: Untersuchen Sie den `X-Spam-Status`-Header in der empfangenen Nachricht. Überprüfen Sie, ob DKIM-Signierung aktiv ist. Stellen Sie sicher, dass der PTR (Reverse DNS)-Record für die sendende IP mit dem SMTP EHLO-Hostnamen übereinstimmt.

Symptom: E-Mail verzögert mit „451 Temporary failure”

• Ursache: Der empfangende Server ist vorübergehend nicht verfügbar oder begrenzt die Rate des Absenders.
• Diagnose: Der sendende MTA wird gemäß seinem Wiederholungsplan automatisch in die Warteschlange stellen und erneut versuchen. Überprüfen Sie die MTA-Protokolle auf die Wiederholungswarteschlange. Anhaltende 451-Fehler von großen Anbietern deuten oft auf IP-Reputationsprobleme hin.

Symptom: DKIM-Signatur schlägt trotz korrektem DNS-Record fehl

• Ursache: Nachricht während der Übertragung verändert (Mailinglisten-Fußzeile angehängt, Header durch Relay umgeschrieben).
• Diagnose: Verwenden Sie ein DKIM-Verifizierungstool auf dem rohen Nachrichtenquelltext. Überprüfen Sie, ob das `h=`-Tag im DKIM-Signature-Header Header enthält, die verändert wurden.

E-Mail-Architektur für gehostete Umgebungen

Für Unternehmen und Entwickler, die ihre eigene Mail-Infrastruktur betreiben, beeinflusst die Hosting-Umgebung direkt die Zustellbarkeit und Sicherheit. Eine VPS Hosting-Umgebung bietet vollständige Kontrolle über die MTA-Konfiguration, PTR-Records und IP-Reputation — Faktoren, die gemeinsam genutzte Umgebungen nicht bieten können. Das Betreiben von Postfix oder Exim auf einem VPS ermöglicht eine präzise Abstimmung von Ratenlimits, TLS-Richtlinien und Authentifizierungsmechanismen.

Organisationen, die hochvolumige transaktionale E-Mails oder vollständige Isolation von benachbarten Mandanten benötigen, profitieren von Dedicated Servers, bei denen die sendende IP exklusiv zugewiesen und nicht mit anderen Kunden geteilt wird. Die IP-Reputation auf einem Dedicated Server liegt vollständig in der Kontrolle des Betreibers.

Für kleinere Betriebe, die keinen selbstverwalteten MTA benötigen, bietet E-Mail-Hosting eine vollständig verwaltete Mail-Umgebung mit vorkonfiguriertem SPF, DKIM und DMARC, wodurch der betriebliche Aufwand für die Wartung von Mailserver-Software entfällt.

Die Absicherung von Webmail- und Mail-Client-Verbindungen erfordert gültige TLS-Zertifikate. Selbstsignierte Zertifikate erzeugen Client-Warnungen und können in strikten MUA-Konfigurationen zu Authentifizierungsfehlern führen. Die Bereitstellung vertrauenswürdiger SSL Certificates auf Mailserver-Hostnamen (z. B. `mail.yourdomain.com`) ist eine unverzichtbare Grundlage für jede produktive Mail-Umgebung.

Die Domain-Konfiguration ist gleichermaßen grundlegend. MX-Records, SPF TXT-Records, DKIM TXT-Records und DMARC TXT-Records befinden sich alle im DNS. Eine genaue und zuverlässige DNS-Verwaltung über einen Domain-Registrierungsanbieter mit einem robusten DNS-Editor ist unerlässlich, um korrekte Mail-Routing- und Authentifizierungsrecords aufrechtzuerhalten.

E-Mail-Header-Analyse: Den Prüfpfad lesen

Jede E-Mail enthält eine Reihe von Headern, die ihre vollständige Reise dokumentieren. Diese werden in umgekehrter chronologischer Reihenfolge vorangestellt — der oberste `Received:`-Header ist der aktuellste Hop. Eine typische Header-Kette sieht so aus:

“`

Received: from mail.example.com (mail.example.com [203.0.113.10])

by mx.google.com with ESMTPS id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:32 -0700

Received: from [192.168.1.5] (dynamic-pool.isp.net [98.76.54.32])

by mail.example.com with ESMTPSA id …

for <recipient@gmail.com>; Mon, 10 Jun 2024 09:15:29 -0700

“`

Wichtige Header für die Diagnose:

• `Return-Path:` — Die Envelope-Absenderadresse, die für Bounce-Benachrichtigungen verwendet wird. Muss mit SPF übereinstimmen.
• `Authentication-Results:` — Vom empfangenden Server hinzugefügt, dokumentiert das Ergebnis der SPF-, DKIM- und DMARC-Prüfungen.
• `X-Originating-IP:` — Wird oft von Webmail-Diensten hinzugefügt, um die IP-Adresse des Clients aufzuzeichnen.
• `Message-ID:` — Eine global eindeutige Kennung, die vom ursprünglichen MTA vergeben wird. Wird verwendet, um Protokolleinträge über Server hinweg zu korrelieren.
• `MIME-Version:` und `Content-Type:` — Definieren die MIME-Struktur des Nachrichtentexts.

Technische Entscheidungsmatrix und wichtige Erkenntnisse

Verwenden Sie diese Checkliste beim Konfigurieren oder Prüfen einer Mail-Umgebung:

DNS und Routing

• MX-Records sind mit korrekten Prioritätswerten veröffentlicht und zeigen auf gültige Hostnamen, keine CNAMEs
• A/AAAA-Records für MX-Hostnamen werden korrekt aufgelöst
• PTR (Reverse DNS)-Record für die sendende IP stimmt mit dem SMTP EHLO-Hostnamen überein

Authentifizierungs-Stack

• SPF TXT-Record mit `-all` oder `~all` veröffentlicht und deckt alle legitimen Sendequellen ab
• DKIM-Schlüssel sind mindestens 2048 Bit; Selektor ist im DNS veröffentlicht und Signierung ist auf dem MTA aktiv
• DMARC-Richtlinie ist mit mindestens `p=quarantine` veröffentlicht; aggregierte Berichterstattung (`rua`) ist konfiguriert
• DMARC-Ausrichtungsmodus ist für Hochsicherheits-Domains auf `s` (strikt) gesetzt

Transportsicherheit

• STARTTLS ist für alle eingehenden und ausgehenden SMTP-Verbindungen aktiviert
• MTA-STS-Richtlinie ist veröffentlicht, wenn strikte TLS-Durchsetzung erforderlich ist
• Gültiges, CA-signiertes TLS-Zertifikat ist auf dem Mailserver-Hostnamen installiert

Empfangskonfiguration

• IMAP wird gegenüber POP3 für alle Multi-Gerät-Deployments verwendet
• IMAP über SSL/TLS auf Port 993 wird erzwungen; Klartext-Port 143 ist deaktiviert oder eingeschränkt
• Serverseitiger Spam-Filter (Rspamd oder SpamAssassin) ist mit aktuellen Regelwerken konfiguriert

Betriebsüberwachung

• DMARC-Aggregatberichte werden regelmäßig überprüft, um nicht autorisierte Absender zu erkennen
• MTA-Warteschlange wird auf zurückgestellte Nachrichten überwacht, die auf Zustellungsprobleme hinweisen
• Sendende IP wird planmäßig gegen wichtige RBLs (Spamhaus ZEN, Barracuda, SORBS) geprüft

FAQ

Was ist der Unterschied zwischen SMTP-Port 25, 465 und 587?

Port 25 wird ausschließlich für Server-zu-Server MTA-Relay verwendet und wird von den meisten ISPs für Endbenutzer gesperrt. Port 587 ist der designierte Übermittlungsport für authentifizierte Client-zu-Server-Verbindungen und verwendet STARTTLS für die Verschlüsselungsaushandlung. Port 465 ist der Legacy-SMTPS-Port, der die gesamte SMTP-Sitzung von Anfang an in SSL/TLS einbettet; er wurde kurzzeitig als veraltet eingestuft, ist aber nun unter RFC 8314 formal für die authentifizierte Übermittlung mit implizitem TLS neu zugewiesen.

Warum besteht meine E-Mail SPF, schlägt aber trotzdem bei DMARC fehl?

DMARC erfordert eine Identifier-Ausrichtung zwischen der authentifizierten Domain und der `From:`-Header-Domain. SPF authentifiziert den Envelope-Absender (`MAIL FROM`), der sich vom sichtbaren `From:`-Header unterscheiden kann. Wenn diese Domains nicht übereinstimmen (unter dem konfigurierten Ausrichtungsmodus), schlägt DMARC fehl, auch wenn SPF besteht. Die Lösung besteht darin, sicherzustellen, dass die `From:`-Header-Domain mit der SPF-authentifizierten Domain übereinstimmt, oder DKIM-Signierung mit der `From:`-Domain zu konfigurieren, sodass die DKIM-Ausrichtung DMARC stattdessen erfüllt.

Was verursacht, dass eine gültige DKIM-Signatur beim empfangenden Server fehlschlägt?

Die häufigsten Ursachen sind: der Nachrichtentext oder signierte Header wurden während der Übertragung verändert (Mailinglisten-Fußzeilen, Header-Umschreibung durch Relays); der DNS TXT-Record für den DKIM-Selektor wurde nach der Signierung gelöscht oder geändert; oder der öffentliche Schlüssel im DNS stimmt nicht mit dem privaten Schlüssel überein, der zum Signieren der Nachricht verwendet wurde. Verifizieren Sie immer anhand des rohen Nachrichtenquelltexts, nicht einer weitergeleiteten Kopie.

Was ist der praktische Unterschied zwischen IMAP und POP3 für eine Unternehmensumgebung?

IMAP synchronisiert den vollständigen Postfachstatus — Gelesen/Ungelesen-Flags, Ordnerstruktur, gesendete Elemente, Entwürfe — über alle Geräte in Echtzeit, wobei Nachrichten auf dem Server verbleiben. POP3 lädt Nachrichten auf ein Gerät herunter und entfernt sie standardmäßig vom Server, sodass es unmöglich ist, auf diese Nachrichten von einem zweiten Gerät aus zuzugreifen. Für jedes Unternehmen, dessen Mitarbeiter E-Mails auf mehr als einem Gerät abrufen, erzeugt POP3 Datensilos und eliminiert die serverseitige Nachrichtenaufbewahrung. IMAP ist die einzig geeignete Wahl.

Wie diagnostiziere ich, warum eine legitime E-Mail in den Spam-Ordner zugestellt wurde?

Rufen Sie den rohen Nachrichtenquelltext aus dem Spam-Ordner ab und untersuchen Sie den `Authentication-Results:`-Header, um die SPF-, DKIM- und DMARC-Ergebnisse zu prüfen. Suchen Sie nach `X-Spam-Status:`- oder `X-Spam-Score:`-Headern, die vom Filter des empfangenden Servers hinzugefügt wurden, um zu identifizieren, welche Regeln ausgelöst wurden. Überprüfen Sie, ob die sendende IP einen passenden PTR-Record hat, auf keiner RBL aufgeführt ist und ob die sendende Domain einen vollständigen Authentifizierungs-Stack hat. Eine fehlende oder fehlgeschlagene DKIM-Signatur in Kombination mit einem neutralen SPF-Ergebnis ist die häufigste Ursache dafür, dass legitime E-Mails als Spam bewertet werden.