Wie E-Mail funktioniert
Vom Klick auf Senden bis zur Ankunft im Posteingang: eine Reise durch SMTP, DNS, Authentifizierung, Bounces und die Eigenheiten der E-Mail-Clients.
Reise startenDie E-Mail wird verfasst
Von der freundlichen Oberfläche zum rohen Nachrichtenformat nach RFC 5322
From: [email protected]
To: [email protected]
Subject: Morgen Mittagessen?
Date: Tue, 18 Aug 2026 19:36:07 +0000
Message-ID: <[email protected]>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="b_9f3a1c7e"
--b_9f3a1c7e
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Hallo Bob,
wollen wir morgen um 12 Uhr essen gehen?
Alice
--b_9f3a1c7e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: 7bit
<html><body><p>Hallo Bob,<br><br>wollen wir morgen um 12 Uhr essen gehen?<br><br>Alice</p></body></html>
--b_9f3a1c7e--Jede E-Mail folgt RFC 5322: ein reines Textformat mit Headern, einer Leerzeile und dem Inhalt. Auch Anhänge und HTML sind nur Text, kodiert mit MIME und getrennt durch Boundary-Zeichenketten.
Anatomie einer E-Mail
Umschlag, Header und Inhalt: drei Schichten, die kaum jemand zu sehen bekommt
Envelope-Absender und sichtbarer From-Header können sich unterscheiden. So funktioniert legitimes Weiterleiten, aber auch Phishing versucht genau hier zu täuschen. SPF, DKIM und DMARC sorgen dafür, dass beide ehrlich bleiben.
Transport: zwei Wege zu versenden
Direktes SMTP gibt Ihnen volle Kontrolle. Amazon SES übernimmt die schwierigen Teile.
- Client → Ihr MTA EHLO mail.example.com Server begrüßen, TLS und Authentifizierung aushandeln
- Ihr MTA → DNS MX acme.io ? Den zuständigen Mailserver der Empfängerdomain nachschlagen
- DNS → Ihr MTA → mx1.acme.io (priority 10) DNS antwortet mit den MX-Records
- Ihr MTA → Empfänger-MTA MAIL FROM: <[email protected]> Den Envelope-Absender setzen
- Ihr MTA → Empfänger-MTA RCPT TO: <[email protected]> Den Envelope-Empfänger setzen
- Ihr MTA → Empfänger-MTA DATA … <message> . Die Nachricht übertragen, abgeschlossen mit einem einzelnen Punkt auf eigener Zeile
- Empfänger-MTA → Ihr MTA 250 OK queued as A1B2C3 In die Warteschlange des Empfängers aufgenommen
- Client → SES API POST /v2/email/outbound-emails HTTPS-API-Aufruf mit signierten AWS-Zugangsdaten
- SES DKIM sign + configuration set SES signiert mit DKIM und wendet Ihr Configuration Set an
- SES-MTA-Pool → DNS MX acme.io ? SES übernimmt den MX-Lookup für Sie
- SES-MTA-Pool → Empfänger-MTA EHLO + STARTTLS + MAIL FROM / RCPT TO / DATA Derselbe SMTP-Dialog, aber aus einem aufgewärmten IP-Pool
- Empfänger-MTA → SES-MTA-Pool 250 OK Angenommen
- SES → SNS-Events Publish 'Delivery' event Sie werden per SNS oder Event-Destination benachrichtigt
Mit direktem SMTP betreiben Sie Ihren eigenen MTA wie Postfix, Exim oder Haraka. Sie verantworten IP-Reputation, Warm-up, Wiederholversuche, Bounce-Handling, DKIM-Schlüssel und TLS. Maximale Kontrolle, maximaler Aufwand.
Mit Amazon SES genügt ein einzelner HTTPS-API-Aufruf. SES übernimmt DKIM-Signierung, IP-Rotation über einen warmen Pool und Wiederholversuche mit exponentiellem Back-off und meldet Bounce-, Beschwerde- und Zustell-Events an SNS, damit Ihre Anwendung reagieren kann.
Authentifizierung
Drei DNS-basierte Prüfungen, die belegen, dass eine E-Mail wirklich vom angegebenen Absender stammt
SPF: Sender Policy Framework
Der empfangende Server fragt: Darf diese IP für diese Domain versenden? SPF listet die autorisierten IPs und Dienste im DNS. Pass bedeutet, die IP ist autorisiert.
DKIM: DomainKeys Identified Mail
Der Absender signiert die Nachricht mit einem privaten Schlüssel. Der Empfänger holt den öffentlichen Schlüssel aus dem DNS und prüft die Signatur. Das belegt, dass die Nachricht unterwegs nicht verändert wurde.
DMARC: Policy und Alignment
DMARC verknüpft SPF und DKIM mit der sichtbaren From-Domain (Alignment) und sagt dem Empfänger, was bei fehlgeschlagenen Prüfungen passieren soll: nichts, Quarantäne oder Ablehnung. Zusätzlich gehen Sammelberichte an den Domain-Inhaber zurück.
Prüfung durch den empfangenden Server
- Verbindung von einer autorisierten IP ok
- Signatur passt zum öffentlichen Schlüssel ok
- From-Domain stimmt mit der authentifizierten Domain überein ok
- DMARC-Policy: bestanden ok
Zusammen sind SPF, DKIM und DMARC das moderne Minimum, um im Posteingang zu landen. Gmail, Yahoo und Apple verlangen sie inzwischen von Massenversendern. Wer sie weglässt, produziert Bounces oder landet im Spam.
Wenn die Zustellung scheitert: Bounces
Der Empfänger konnte die Nachricht nicht annehmen. Hier steht, warum, und was zu tun ist.
Anatomie eines Bounce
Häufige SMTP-Antworten
Häufige SMTP-Antworten
Häufige SMTP-Antworten
Warum Bounces wehtun
- Eine hohe Bounce-Rate ruiniert Ihre Absender-Reputation bei den Mailbox-Providern.
- Amazon SES stellt Konten ab etwa 5% Bounce-Rate unter Beobachtung und pausiert den Versand um die 10%.
- Bounces zählen als Spam-Signal, sodass selbst Ihre guten E-Mails im Junk-Ordner landen.
- Wiederholte Bounces an dieselben Adressen können Ihre Versanddomain auf Blocklisten bringen.
Was dagegen hilft
- Suppression-Liste: An hart gebouncte Adressen nie wieder senden. SES führt automatisch eine Liste pro Konto.
- Double-Opt-in: Neue Adressen vor der Aufnahme per Klick bestätigen lassen. Das eliminiert Tippfehler und Spam-Traps.
- Listenhygiene: Adressen ohne Reaktion nach 6 bis 12 Monaten entfernen und mit einem Verifizierungsdienst erneut prüfen.
- Warm-up: Das Volumen über Wochen langsam steigern, damit Empfänger Ihrer IP und Domain vertrauen lernen.
- Authentifizieren: SPF, DKIM und DMARC, sauber aligned. Sie wegzulassen ist die häufigste Ursache für Reputations-Blocks.
- Events auswerten: Bei SES die Bounce- und Beschwerde-Topics abonnieren und in Echtzeit verarbeiten.
Bounces sind keine Fehler, sie sind Feedback. Ein gesundes Versandprogramm behandelt jeden Bounce als Signal: Liste bereinigen, Authentifizierung reparieren, Volumen drosseln. Im Posteingang landen die Absender, die zuhören.
Andere Clients, andere Welten
Dieselbe E-Mail wird völlig unterschiedlich interpretiert, je nachdem, wer sie öffnet
Wie er mit Bildern umgeht
Bilder laden über den Google-Bildproxy (googleusercontent.com).
Was das für Tracking bedeutet
Tracking-Pixel feuern, sobald die E-Mail geöffnet wird, aber die Anfrage kommt von einer Google-IP, nicht vom Leser. Bilder werden gecacht, das Pixel feuert also nur einmal.
Privatsphäre
Mittel: Die IP bleibt verborgen, das Öffnen selbst ist aber weiterhin erkennbar.
Eigenheiten, die jeder Absender kennen sollte
- Unterstützt eingebettetes CSS nur teilweise; komplexe Styles besser inline schreiben
- Kürzt Nachrichten über 102 KB hinter einem Link "Gesamte Nachricht ansehen"
- Verlinkt URLs automatisch und ergänzt bei Massenversendern einen eigenen Abmeldelink
Wie er mit Bildern umgeht
Standardmäßig blockiert. Der Leser muss auf "Bilder herunterladen" klicken, dann laden die Bilder direkt vom Ursprungsserver und geben die IP des Lesers preis.
Was das für Tracking bedeutet
Tracking-Pixel feuern nur, wenn der Leser Bilder ausdrücklich nachlädt. Öffnungen aus Outlook werden daher massiv untererfasst.
Privatsphäre
Hoch: Standardmäßig wird nichts Externes geladen.
Eigenheiten, die jeder Absender kennen sollte
- Rendert HTML mit Word, Flexbox, Grid und modernes CSS werden großteils ignoriert
- Oft der Grund, warum Marketing-Mails mit zerschossenem Layout ankommen
- Braucht VML für Hintergrundbilder und robuste Buttons
Wie er mit Bildern umgeht
Mit Mail Privacy Protection, Standard seit iOS 15, lädt Apple alle Bilder beim Eintreffen über einen Proxy vor, selbst wenn der Leser die Mail nie öffnet.
Was das für Tracking bedeutet
MPP macht Öffnungsraten nahezu bedeutungslos: Jede E-Mail wirkt geöffnet, von wechselnden Apple-IPs, und auch die Geolokalisierung wird verschleiert.
Privatsphäre
Sehr hoch: Apple bricht Tracking absichtlich und systematisch.
Eigenheiten, die jeder Absender kennen sollte
- Beste CSS-Unterstützung aller großen Clients: Flexbox, Grid und Dark-Mode-Media-Queries funktionieren
- MPP betrifft rund die Hälfte aller E-Mail-Öffnungen weltweit
- Zwingt Absender, Klicks statt Öffnungen zu messen
Das Tracking-Pixel, dreimal anders
- Leser öffnet die E-Mail
- Google lädt das Bild einmal
- Cache im Google-CDN
- Pixel feuert von einer Google-IP
- Leser öffnet die E-Mail
- Bilder bleiben blockiert
- Leser klickt "Bilder herunterladen"
- Pixel feuert von der Leser-IP
- E-Mail trifft auf dem Gerät ein
- Apple lädt per Proxy vor
- Auch wenn nie geöffnet wird
- Pixel feuert von einer Apple-IP
Dasselbe Tracking-Pixel verhält sich je nach Client völlig unterschiedlich. Deshalb ist die Öffnungsrate eine zunehmend unzuverlässige Kennzahl, und klickbasiertes Engagement übernimmt.
Kalender-Einladungen: iMIP
Wenn sich Outlook, Google Calendar und Apple Kalender auf einen Termin einigen, sprechen sie E-Mail
Terminplanung über Anbietergrenzen hinweg braucht keinen zentralen Server: Einladungen, Zusagen und Absagen reisen als ganz normale E-Mails. Drei Standards teilen sich die Arbeit, und iMIP (RFC 6047) ist die unterste Schicht davon: Er verpackt die Scheduling-Nachricht als MIME-Teil mit Content-Type: text/calendar; method=… in eine Mail.
Das Datenformat: VEVENT, DTSTART, ATTENDEE, ein Termin als strukturierter Text.
Die Choreografie: wer darf was, REQUEST, REPLY, COUNTER, CANCEL und die SEQUENCE-Regeln.
Der Transport: die iTIP-Nachricht reist als text/calendar-MIME-Teil in einer normalen E-Mail.
SEQUENCE:0 STATUS:CANCELLED
Du bist Alice und planst ein Kickoff. Lade Bob, Carol und Dave ein: eine E-Mail mit METHOD:REQUEST an alle drei.
Nachrichten unterwegs …
Dave schlägt per COUNTER 16:00 vor. Nur du als Organizer darfst den Termin ändern: Update mit erhöhter SEQUENCE senden oder absagen.
Alle haben zugesagt. Gleiche UID, SEQUENCE:1: Die Kalender aller Teilnehmer zeigen jetzt automatisch 16:00.
Abgesagt. Das CANCEL trägt dieselbe UID, damit jeder Client weiß, welcher Termin aus dem Kalender verschwindet.
NEEDS-ACTION
NEEDS-ACTION
NEEDS-ACTION
- alice → bob, carol, dave METHOD:REQUEST · SEQUENCE:0 Die Einladung: ein VEVENT mit ORGANIZER, drei ATTENDEE-Zeilen und RSVP=TRUE.
- bob → alice METHOD:REPLY · PARTSTAT=ACCEPTED Bob sagt zu. Sein Client ändert nur seinen eigenen PARTSTAT, mehr darf ein Attendee nicht.
- carol → alice METHOD:REPLY · PARTSTAT=TENTATIVE Carol ist unsicher und antwortet mit TENTATIVE.
- dave → alice METHOD:COUNTER · DTSTART 16:00 Dave schlägt mit COUNTER einen neuen Zeitpunkt vor, die Entscheidung bleibt bei Alice.
- alice → bob, carol, dave METHOD:REQUEST · SEQUENCE:1 · 16:00 Das Update: dieselbe UID mit SEQUENCE:1 und neuem Zeitpunkt überschreibt den Termin bei allen.
- bob, carol, dave → alice METHOD:REPLY · PARTSTAT=ACCEPTED Alle drei bestätigen den neuen Zeitpunkt.
- alice → bob, carol, dave METHOD:CANCEL · STATUS:CANCELLED Die Absage: STATUS:CANCELLED mit erhöhter SEQUENCE entfernt den Termin aus allen Kalendern.
Sende eine Einladung, dann erscheint hier der rohe text/calendar-Teil der jeweils letzten Nachricht.
Content-Type: text/calendar; method=REQUEST;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:0
DTSTART:20260811T130000Z
DTEND:20260811T134500Z
SUMMARY:Kickoff
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE;CN=Bob;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Carol;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Dave;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=REPLY;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:REPLY
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:0
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE;PARTSTAT=ACCEPTED:mailto:[email protected]
REQUEST-STATUS:2.0;Success
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=COUNTER;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:COUNTER
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:0
DTSTART:20260811T140000Z
DTEND:20260811T144500Z
SUMMARY:Kickoff
COMMENT:16:00 works better for me
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE:mailto:[email protected]
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=REQUEST;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:REQUEST
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:1
DTSTART:20260811T140000Z
DTEND:20260811T144500Z
SUMMARY:Kickoff
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE;CN=Bob;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Carol;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
ATTENDEE;CN=Dave;ROLE=REQ-PARTICIPANT;
PARTSTAT=NEEDS-ACTION;RSVP=TRUE
:mailto:[email protected]
END:VEVENT
END:VCALENDARContent-Type: text/calendar; method=CANCEL;
charset=UTF-8
BEGIN:VCALENDAR
VERSION:2.0
METHOD:CANCEL
BEGIN:VEVENT
UID:[email protected]
SEQUENCE:1
STATUS:CANCELLED
ORGANIZER;CN=Alice:mailto:[email protected]
ATTENDEE:mailto:[email protected]
ATTENDEE:mailto:[email protected]
ATTENDEE:mailto:[email protected]
END:VEVENT
END:VCALENDARWeil iMIP nur E-Mail ist, kann im Prinzip jeder jedem Termine in den Kalender legen, genau das nutzt Kalender-Spam aus. RFC 6047 empfiehlt deshalb signierte Nachrichten (S/MIME), und moderne Clients tragen Termine unbekannter Absender erst nach Rückfrage ein.
Die ganze Reise auf einen Blick
Vom Verfassen bis zum Posteingang in Sekunden, meistens jedenfalls
- Verfassen
- MTA
- DNS / MX
- SPF/DKIM/DMARC
- Bounce?
- Postfach
- Client rendert
Das Transportprotokoll: EHLO, MAIL FROM, RCPT TO, DATA und die Antwortcodes.
Header, Inhalt und Kodierungsregeln: die Gestalt einer E-Mail.
Wie kryptografische Signaturen über Mail-Stationen hinweg gesetzt und geprüft werden.
Kalender-Einladungen per E-Mail: REQUEST, REPLY, COUNTER und CANCEL als text/calendar.
E-Mail ist älter als das Web und trotzdem bis heute das zuverlässigste Kommunikationsprotokoll des Internets.
Erstellt von Renick Digital Solutions. Wir entwickeln Software und kennen uns mit E-Mail-Infrastruktur aus. Was wir sonst so bauen