Wie E-Mail funktioniert

Jeden Tag werden weltweit über 300 Milliarden E-Mails versendet. Dennoch haben die meisten Menschen — darunter viele Entwickler — keine Vorstellung davon, was zwischen dem Klick auf „Senden“ und dem Erscheinen einer Nachricht im Posteingang tatsächlich passiert. E-Mail ist eines der ältesten und widerstandsfähigsten Protokolle des Internets, erstmals Anfang der 1980er-Jahre standardisiert und bis heute quicklebendig.

Diese Anleitung führt durch das vollständige technische Bild: wie Nachrichten durch das Internet reisen, wie Server Absender authentifizieren, warum manche E-Mails im Spam landen und was den Versand einer Marketingkampagne grundlegend vom Versand einer Nachricht an eine Freundin unterscheidet.

Die Reise einer E-Mail

Eine E-Mail durchläuft auf dem Weg von Absender zu Empfänger mehrere Systeme. Jedes System hat eine bestimmte Rolle, und diese Rollen zu verstehen ist der Schlüssel zum Verständnis von E-Mail insgesamt.

Diese Begriffe werden Ihnen begegnen:

Verfassen und Einliefern

Wenn Sie in Ihrem E-Mail-Client (dem MUA) auf „Senden“ klicken, wird die Nachricht per SMTP über Port 587 an einen Mail Submission Agent eingeliefert. Der MSA verlangt eine Authentifizierung — Sie müssen nachweisen, dass Sie von dieser Adresse senden dürfen. Deshalb geben Sie Ihr E-Mail-Passwort ein oder verwenden ein anwendungsspezifisches Token.

Der MSA validiert die Nachricht, ergänzt einige Header (etwa Date und Message-ID, falls sie fehlen) und übergibt sie an den ausgehenden Mail Transfer Agent.

Routing

Der MTA des Absenders muss herausfinden, wohin die Nachricht zugestellt werden soll. Dazu fragt er im DNS die MX-Einträge (Mail eXchange) der Empfängerdomain ab. MX-Einträge verweisen auf die Hostnamen der Server, die Mail für diese Domain annehmen.

$ dig +short MX gmail.com
5  gmail-smtp-in.l.google.com.
10 alt1.gmail-smtp-in.l.google.com.
20 alt2.gmail-smtp-in.l.google.com.

Die Zahlen sind Prioritäten — niedriger wird bevorzugt. Der MTA versucht die Server der Reihe nach, bis einer die Nachricht annimmt.

Zustellung

Der empfangende MTA nimmt die Nachricht an (oder weist sie ab), basierend auf Authentifizierungsprüfungen (SPF, DKIM, DMARC — weiter unten behandelt), Spam-Filterung und Richtlinien auf Serverebene. Wird sie angenommen, geht die Nachricht an den Mail Delivery Agent, der sie in das richtige Postfach einsortiert, benutzerdefinierte Filter anwendet und sie speichert.

Abruf

Der E-Mail-Client des Empfängers ruft Nachrichten über IMAP (Internet Message Access Protocol) oder POP3 (Post Office Protocol) ab. IMAP belässt Nachrichten auf dem Server und synchronisiert den Zustand über Geräte hinweg. POP3 lädt Nachrichten herunter und entfernt sie typischerweise vom Server. Webmail-Clients wie Gmail überspringen diesen Schritt vollständig — sie lesen direkt aus dem Speicher des Servers.

Das SMTP-Protokoll

SMTP (Simple Mail Transfer Protocol) ist das Standardprotokoll zum Versenden von E-Mail. Es ist ein Push-Protokoll — es kümmert sich nur um das Senden, nicht um das Empfangen. Es wurde 1982 entworfen (RFC 821) und seither vielfach erweitert, doch der Kerndialog sieht noch bemerkenswert ähnlich aus.

So sieht eine rohe SMTP-Sitzung aus:

Portnummern

Port 25 wird zwischen Mailservern verwendet und ist für Consumer-Anschlüsse von Providern typischerweise blockiert, um Spam zu verhindern. Port 587 ist der Port, den Ihr E-Mail-Client nutzt — er erfordert Authentifizierung und Verschlüsselung via STARTTLS.

Anatomie einer E-Mail — Envelope vs. Header vs. Body

Einer der verwirrendsten Aspekte von E-Mail ist, dass es zwei Sätze von Absender-/Empfängerangaben gibt, die voneinander abweichen können.

Stellen Sie es sich wie Briefpost vor: Der Umschlag trägt eine Absender- und eine Zieladresse, die die Post zum Routen verwendet. Im Umschlag hat der Brief oben ein eigenes „Von“ und „An“ — das sieht der Empfänger, die Post ignoriert es jedoch.

Der Envelope

Der SMTP-Envelope besteht aus zwei Kommandos:

• MAIL FROM: — die Rücksendeadresse (auch Return-Path oder Bounce-Adresse genannt). Kann die Nachricht nicht zugestellt werden, geht die Bounce-Benachrichtigung hierhin.
• RCPT TO: — die tatsächliche(n) Zieladresse(n). Dorthin wird die Nachricht physisch zugestellt.

Die Header

Innerhalb des DATA-Teils des SMTP-Dialogs hat die Nachricht Header, die der Empfänger sieht:

Warum Envelope und Header abweichen können

Für Abweichungen gibt es legitime Gründe:

• BCC: Der BCC-Empfänger erscheint in RCPT TO, aber nicht in den To- oder Cc-Headern
• Mailinglisten: Der Listenserver empfängt die Nachricht und sendet sie erneut an alle Abonnenten. From bleibt der ursprüngliche Autor, aber der Envelope-Absender wechselt zur Bounce-Adresse der Liste
• Weiterleitung: Der From-Header bleibt gleich, der Envelope-Absender wechselt aber zum Weiterleitenden
• Marketing-E-Mail: MAIL FROM ist häufig eine Adresse zur Bounce-Verarbeitung (etwa bounces+id@esp.example.com), während From die Adresse der Marke zeigt

MIME und Multipart-Nachrichten

Moderne E-Mails enthalten selten nur reinen Text. MIME (Multipurpose Internet Mail Extensions) erlaubt es E-Mails, mehrere Inhaltstypen in einer einzigen Nachricht zu transportieren:

• multipart/alternative — derselbe Inhalt in verschiedenen Formaten (Plain Text + HTML). Der E-Mail-Client wählt aus, was angezeigt wird.
• multipart/mixed — der Nachrichtenrumpf plus Anhänge
• multipart/related — HTML-Body mit eingebetteten Bildern (referenziert über Content-ID)

Content-Type: multipart/alternative; boundary="boundary123"

--boundary123
Content-Type: text/plain; charset="utf-8"

Hello, this is the plain text version.

--boundary123
Content-Type: text/html; charset="utf-8"

<html><body><h1>Hello</h1><p>This is the HTML version.</p></body></html>

--boundary123--

E-Mail-Authentifizierung

In den Anfangstagen der E-Mail gab es keine Möglichkeit zu überprüfen, ob eine Nachricht tatsächlich von der Domain stammte, von der sie zu kommen behauptete. Jeder konnte eine E-Mail senden und sich dabei als jemand anderes ausgeben. Zur Lösung wurden drei einander ergänzende Protokolle entwickelt: SPF, DKIM und DMARC.

SPF — Sender Policy Framework

Mit SPF kann eine Domain erklären, welche Server in ihrem Namen E-Mail versenden dürfen. Die Domain veröffentlicht einen DNS-TXT-Eintrag, der autorisierte IP-Adressen und Dienste auflistet.

Wenn ein empfangender Server eine Nachricht erhält, prüft er die Return-Path-Domain (Envelope-Absender), schlägt den SPF-Eintrag dieser Domain nach und verifiziert, dass die IP des verbindenden Servers in der Liste der autorisierten Adressen steht.

example.com.  IN TXT  "v=spf1 include:amazonses.com include:_spf.google.com -all"

Dieser Eintrag besagt: „Nur Amazon SES und Google Workspace dürfen E-Mail für example.com versenden. Alles andere ablehnen (-all).“

Einschränkung: SPF prüft den Envelope-Absender, nicht den From-Header. Eine Phishing-Mail kann SPF bestehen, wenn der Phisher seine eigene Domain im Return-Path verwendet und dabei den From-Header fälscht.

DKIM — DomainKeys Identified Mail

DKIM fügt ausgehenden E-Mails eine kryptografische Signatur hinzu. Der sendende Server signiert bestimmte Header und den Nachrichtenrumpf mit einem privaten Schlüssel. Die Signatur wird als DKIM-Signature-Header eingefügt.

Der empfangende Server entnimmt der Signatur die signierende Domain (d=) und den Selektor (s=), schlägt den zugehörigen öffentlichen Schlüssel per DNS nach und verifiziert die Signatur. Wurde die Nachricht unterwegs verändert, schlägt die Signaturprüfung fehl.

DKIM-Signature: v=1; a=rsa-sha256; d=example.com; s=s1;
  h=from:to:subject:date:message-id;
  bh=2jUSOH9Nhtj...;
  b=dzdVyOfAKCdL...

Der öffentliche Schlüssel wird als DNS-TXT-Eintrag veröffentlicht:

s1._domainkey.example.com.  IN TXT  "v=DKIM1; k=rsa; p=MIGfMA0GCS..."

Einschränkung: DKIM belegt, dass die Nachricht nicht manipuliert wurde und von einer bestimmten Domain signiert wurde, aber nicht, dass d=example.com zum From-Header passt. Ein Phisher könnte mit seiner eigenen Domain signieren und dabei From fälschen.

DMARC — Domain-based Message Authentication, Reporting & Conformance

DMARC verknüpft SPF und DKIM, indem es Alignment ergänzt — die Anforderung, dass die Domain im From-Header zu der von SPF oder DKIM (oder von beiden) verifizierten Domain passt.

_dmarc.example.com.  IN TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@example.com"

DMARC führt drei Richtlinienstufen ein:

• p=none — nur beobachten; bei Fehlschlägen nicht eingreifen (nützlich in der Einrichtungsphase)
• p=quarantine — Fehlschläge in den Spam-Ordner zustellen
• p=reject — Nachrichten, die das Alignment nicht bestehen, rundheraus ablehnen

DMARC führt außerdem Aggregatberichte (rua) ein: Empfangende Server senden tägliche XML-Berichte, die dem Domaininhaber mitteilen, wie viele E-Mails die Authentifizierung bestanden oder nicht bestanden haben. Das ist für Monitoring und Fehlersuche von unschätzbarem Wert.

Wie sie zusammenspielen

Eine vollständig authentifizierte E-Mail-Einrichtung sieht so aus:

1. SPF bestätigt, dass die IP des sendenden Servers für die Return-Path-Domain autorisiert ist
2. DKIM bestätigt, dass Nachrichtenrumpf und Header nicht manipuliert wurden, signiert von der d=-Domain
3. DMARC bestätigt, dass die Domain des From-Headers entweder zur SPF-Domain oder zur DKIM-d=-Domain aligned ist
4. Der empfangende Server wendet die DMARC-Richtlinie an, wenn das Alignment scheitert

Bestehen alle drei, haben empfangende Server hohes Vertrauen darauf, dass die E-Mail legitim ist.

Absenderreputation

Authentifizierung belegt, wer Sie sind. Die Reputation entscheidet, ob man Ihnen vertraut. Selbst eine perfekt authentifizierte E-Mail — SPF bestanden, DKIM verifiziert, DMARC aligned — kann im Spam landen, wenn der Absender eine schlechte Reputation hat. Mailbox-Anbieter verfolgen die Reputation entlang zweier Achsen: der IP-Adresse, von der die Nachricht gesendet wurde, und der Domain, die dem Absender zugeordnet ist.

IP-Reputation

Jede IP-Adresse, die E-Mail versendet, sammelt bei jedem Mailbox-Anbieter, an den sie zustellt, einen Reputationswert an. Dieser Wert beruht auf messbarem Sendeverhalten: Bounce-Raten, Spam-Beschwerderaten, Treffer in Spamtraps und Volumenmuster. In den 2000er- und frühen 2010er-Jahren war die IP-Reputation das dominierende Vertrauenssignal — Authentifizierung auf Domainebene (DKIM, DMARC) war noch nicht weit verbreitet, sodass die IP der verlässlichste Weg war, einen Absender zu identifizieren.

IP-Reputation gibt es in zwei Ausprägungen. Geteilte IPs werden von E-Mail-Dienstleistern wie SendGrid oder Mailgun genutzt, bei denen Tausende Kunden aus demselben Adresspool senden. Ihre Reputation vermischt sich mit der aller anderen — gut für Absender mit geringem Volumen, die vom etablierten Vertrauen des Pools profitieren, riskant, wenn ein Nachbar Spam versendet. Dedizierte IPs geben Ihnen eine Reputation, die ganz Ihnen gehört, starten aber kalt — Sie müssen sie über Wochen schrittweise aufwärmen, indem Sie zuerst an Ihre engagiertesten Empfänger senden.

Domain-Reputation

Die Domain-Reputation ist das moderne Primärsignal. Mailbox-Anbieter verfolgen die Reputation anhand mehrerer Domain-Identifikatoren:

• DKIM-Signaturdomain (der d=-Wert im DKIM-Signature-Header) — das stärkste Signal, weil es kryptografisch an den Absender gebunden ist
• Envelope-Absenderdomain (die Return-Path- / MAIL-FROM-Domain)
• Domain des From-Headers — die Domain, die Empfänger in ihrem Posteingang sehen

Google hat seine Dashboards für Domain- und IP-Reputation Ende 2025 aus den Postmaster Tools entfernt und ist zu compliance-orientierten Kennzahlen übergegangen (Spam-Rate, Authentifizierungsfehler, Zustellprobleme) — ein Zeichen dafür, dass Gmails Filterung sich von einfachen Reputationswerten hin zu ganzheitlichen Engagement- und Compliance-Signalen bewegt hat. Microsofts SNDS liefert weiterhin Daten auf IP-Ebene, doch seit Mai 2025 erzwingt Microsoft zusätzlich Authentifizierung auf Domainebene (SPF, DKIM, DMARC-Alignment) für Massenversender, wobei die Ablehnung von Nachrichten nicht konformer Domains ab 2026 ausgerollt wird. Der entscheidende Vorteil der Domain-Reputation: Sie bleibt bestehen, wenn Sie die Infrastruktur wechseln. ESP wechseln, IPs rotieren, Anbieter migrieren — Ihre Domain-Reputation zieht mit Ihnen um.

Die Verschiebung von IP zu Domain

Die Verschiebung geschah aus praktischen Gründen. Cloud-basierte ESPs machten geteilte IPs zur Norm — wenn Tausende Absender dieselben IP-Adressen teilen, wird IP-Reputation zu einem groben Werkzeug. Googles Anforderungen für Massenversender von 2024 machten diese Verschiebung explizit, indem sie die Durchsetzung an Authentifizierung auf Domainebene knüpften (DKIM-Alignment und DMARC-Richtlinien). Yahoo folgte mit identischen Anforderungen, und Microsoft schloss sich im Mai 2025 mit denselben SPF-/DKIM-/DMARC-Anforderungen für Absender mit mehr als 5.000 Nachrichten pro Tag an.

Domain-Reputation lässt sich außerdem schwerer austricksen. In der IP-zentrierten Ära brannten Spammer IP-Adressen ab — sie versendeten Spam, bis die IP auf einer Blockliste stand, und wechselten dann zur nächsten. Domains sind teurer, sichtbarer und an DNS-Einträge gebunden, deren Etablierung Zeit braucht.

Wie Anbieter Reputation heute gewichten

Keine zwei Mailbox-Anbieter gewichten Reputation identisch, doch der Trend ist eindeutig — Domain-Reputation wird zunehmend dominant:

Die meisten kleineren Provider und Firmen-Mailserver stützen sich weiterhin stark auf IP-Reputation und Blocklisten Dritter (Spamhaus, Barracuda). Eine umfassende Zustellbarkeitsstrategie adressiert beide Signale, doch bei den großen Anbietern wiegen Domain-Reputation und Authentifizierungs-Compliance inzwischen schwerer als die IP-Reputation.

Marketing-E-Mail vs. private E-Mail

Eine Marketingkampagne an 50.000 Abonnenten zu senden ist eine grundlegend andere Operation als eine Nachricht an eine Kollegin zu schicken. Das SMTP-Protokoll ist dasselbe, aber fast alles drumherum ändert sich.

Infrastruktur

Wenn Sie eine persönliche E-Mail über Gmail senden, läuft Ihre Nachricht über Googles gemeinsam genutzte Mail-Infrastruktur — dieselben Server, die Millionen anderer Gmail-Nutzer verwenden. Googles IP-Adressen genießen bereits das Vertrauen jedes Providers der Welt.

Marketing-E-Mail erfordert dedizierte Infrastruktur: E-Mail-Dienstleister (ESPs) wie Amazon SES, SendGrid oder Mailgun — oder einen eigenen Mail Transfer Agent. Diese Systeme bewältigen die Komplexität des Versands im großen Maßstab: Connection Pooling, Retry-Logik, Bounce-Verarbeitung und Compliance.

IP-Warming

Wie oben unter Absenderreputation beschrieben, hat eine brandneue IP-Adresse keine Reputation. IP-Warming ist der Prozess, das Sendevolumen über Wochen schrittweise zu steigern und so bei jedem Provider Vertrauen aufzubauen. Zuerst an die engagiertesten Empfänger zu senden erzeugt positive Signale, mit denen Sie schneller hochskalieren können.

Compliance

Marketing-E-Mail unterliegt Gesetzen wie CAN-SPAM (USA), DSGVO (EU) und CASL (Kanada). Zu den Anforderungen gehören:

• Ein sichtbarer, funktionierender Abmeldemechanismus in jeder E-Mail
• Der List-Unsubscribe-Header für die Ein-Klick-Abmeldung (von Gmail und Yahoo seit 2024 vorausgesetzt)
• Abmeldewünsche innerhalb von 10 Tagen umsetzen (CAN-SPAM) oder sofort (Best Practice)
• Nicht an Kontakte senden, die keine Einwilligung gegeben haben (DSGVO)
• Eine ladungsfähige Postanschrift angeben (CAN-SPAM)

Private E-Mails zwischen Einzelpersonen unterliegen keiner dieser Anforderungen.

Bounce-Verarbeitung und Feedback Loops

Wenn eine Marketing-E-Mail bounct (die Empfängeradresse existiert nicht oder das Postfach ist voll), muss der ESP diesen Bounce verarbeiten und die Adresse für künftige Sendungen unterdrücken. Fortgesetztes Senden an ungültige Adressen schädigt Ihre IP-Reputation.

Feedback Loops (FBLs) sind Vereinbarungen mit Providern, bei denen der Provider Sie benachrichtigt, wenn ein Empfänger Ihre E-Mail als Spam markiert. FBL-Beschwerden zu verarbeiten und diese Empfänger zu entfernen ist entscheidend für den Erhalt der Zustellbarkeit.

Private E-Mail-Clients behandeln Bounces, indem sie Ihnen schlicht einen Fehler anzeigen — es braucht kein automatisiertes Unterdrückungssystem, wenn Sie jeweils einer Person schreiben.

Warum E-Mails im Spam landen

Spam-Filter haben sich von einfachem Schlüsselwortabgleich zu ausgefeilten Systemen entwickelt, die Dutzende Signale berücksichtigen. Das zählt am meisten:

Reputation

Wie oben unter Absenderreputation ausgeführt, trägt jede sendende IP und Domain einen Reputationswert. Eine schlechte Reputation bedeutet, dass Ihre E-Mails im Spam landen — selbst wenn der Inhalt vollkommen legitim ist.

Engagement-Signale

Moderne Spam-Filter (insbesondere die von Gmail) gewichten Empfängerverhalten stark:

• Öffnen Empfänger Ihre E-Mails?
• Klicken sie auf Links?
• Antworten sie?
• Verschieben sie Ihre E-Mails aus dem Spam heraus?
• Markieren sie Ihre E-Mails als Spam?

Geringes Engagement sagt Providern, dass Empfänger Ihre E-Mail nicht wollen — und sie beginnen, sie proaktiv in den Spam zu routen.

Inhaltliche und technische Signale

• Authentifizierungsfehler — fehlendes oder fehlschlagendes SPF, DKIM oder DMARC ist ein großes Warnsignal
• HTML-Qualität — kaputtes HTML, übermäßig viele Bilder ohne Text oder versteckter Text können Filter auslösen
• URL-Reputation — Links zu bekannt schädlichen Domains oder URL-Kürzern können Probleme verursachen
• Sendemuster — plötzliche Volumenspitzen von einer Domain, die normalerweise wenig E-Mail versendet

Listenhygiene

An alte, ungültige oder gekaufte Listen zu senden ist einer der schnellsten Wege, die Zustellbarkeit zu zerstören. Spamtraps — E-Mail-Adressen, die eigens angelegt wurden, um Absender mit schlechten Listenpraktiken zu erwischen — sind über das gesamte Internet verteilt. Eine Spamtrap zu treffen ist ein starkes negatives Signal an Provider.

Blocklisten

Organisationen wie Spamhaus, Barracuda und SpamCop pflegen Blocklisten von IP-Adressen und Domains, die als Spamversender bekannt sind. Viele Provider prüfen diese Blocklisten in Echtzeit. Gelistet zu werden — und wieder von der Liste zu kommen — kann Tage bis Wochen dauern.

Wie sich Owlat einfügt

Owlat setzt alle oben beschriebenen Konzepte als vollständige E-Mail-Plattform um:

• Eigener MTA — Owlats Mail Transfer Agent übernimmt die direkte SMTP-Zustellung mit DKIM-Signierung, adaptivem Throttling pro Provider, IP-Warming, Bounce-Verarbeitung und Feedback-Loop-Anbindung
• Authentifizierung — Wenn Sie in Owlat eine Domain verifizieren, erzeugt Owlat die SPF-, DKIM- und DMARC-DNS-Einträge für Sie und überwacht deren Status
• Intelligence-Pipeline — Jede ausgehende E-Mail durchläuft mehr als 10 Prüfungen vor dem Versand, darunter Circuit Breaker, Unterdrückungslisten, Domain-Throttling und engagementbasierte Priorisierung
• E-Mail-Rendering — Der E-Mail-Renderer wandelt Blöcke des visuellen Editors in clientübergreifend kompatibles HTML um, mit CSS-Inlining, VML-Fallbacks für Outlook und Dark-Mode-Unterstützung
• Anbieterabstraktion — Das E-Mail-System unterstützt mehrere Anbieter (eigener MTA, Amazon SES, Resend) hinter einer einheitlichen Schnittstelle mit automatischem Retry und Rate Limiting

Produktspezifische Einrichtungsanleitungen finden Sie unter Erste Schritte und Zustellbarkeit.