Multipart – Definition, technischer Aufbau und Bedeutung im E-Mail-Marketing

Multipart bezeichnet im E-Mail-Marketing E-Mails, die gleichzeitig in zwei Formaten versendet werden: als HTML-Version mit Gestaltung, Bildern und Links sowie als reine Textversion ohne Formatierung. Welche der beiden Versionen der Empfänger sieht, entscheidet nicht der Absender, sondern das E-Mail-Programm des Empfängers – es wählt automatisch jenes Format, das es darstellen kann oder das der Nutzer eingestellt hat. In der Fachsprache ist auch von Multipart/Alternative die Rede, was den zugrundeliegenden MIME-Typ beschreibt.

Wie Multipart technisch funktioniert

Der Mechanismus beruht auf dem MIME-Standard (Multipurpose Internet Mail Extensions), der definiert, wie E-Mails strukturiert und kodiert werden können. Eine Multipart-E-Mail ist im Grunde eine einzige Nachricht, die zwei oder mehr Inhaltsteile in sich trägt. Diese Teile sind im E-Mail-Quelltext durch sogenannte Boundaries voneinander getrennt – Trennzeichen, die dem empfangenden E-Mail-Client signalisieren, wo ein Inhaltsteile endet und der nächste beginnt.

Beim MIME-Typ multipart/alternative – dem für das E-Mail-Marketing relevantesten Subtyp – enthält die E-Mail eine Textversion (text/plain) und eine HTML-Version (text/html) desselben Inhalts. E-Mail-Clients, die HTML unterstützen und aktiviert haben, zeigen die HTML-Version an. Clients oder Einstellungen, die nur Plaintext erlauben, greifen auf die Textversion zurück. Der Empfänger bemerkt diesen Wechsel in der Regel nicht – er sieht schlicht das, was sein Programm als passend erachtet.

Daneben gibt es noch multipart/mixed, das verwendet wird, wenn einer E-Mail Dateianhänge beigefügt sind, sowie multipart/related, das zum Einsatz kommt, wenn Bilder direkt in den HTML-Body eingebettet werden anstatt als externe Ressourcen verlinkt zu sein.

Warum Multipart im E-Mail-Marketing Standard ist

Wer heute professionelles E-Mail-Marketing betreibt, verschickt Multipart-E-Mails – meistens ohne darüber nachzudenken, weil gute Versandplattformen das automatisch erledigen. Dahinter steckt aber ein handfester Grund: Nicht jeder Empfänger kann oder will HTML-E-Mails empfangen. Unternehmensumgebungen blockieren HTML-Inhalte aus Sicherheitsgründen manchmal serverseitig. Manche Nutzer haben in ihrem E-Mail-Programm explizit eingestellt, Mails nur als Text zu empfangen. Und E-Mail-Clients auf älteren Mobilgeräten oder in bestimmten Regionen der Welt handhaben HTML-Darstellung bisweilen fehlerhaft.

Ohne eine Plaintext-Fallback-Version landet die E-Mail in solchen Fällen entweder als unlesbares HTML-Chaos im Postfach oder gar nicht. Mit einer sauber gepflegten Textversion hingegen ist sichergestellt, dass die Kernbotschaft in jedem Kontext ankommt.

Auch für die Zustellbarkeit spielt Multipart eine Rolle. Spam-Filter bewerten E-Mails, die ausschließlich als HTML ohne Textversion verschickt werden, tendenziell kritischer – das Fehlen einer Plaintext-Alternative kann als Indiz für maschinell generierte Massensendungen gewertet werden. E-Mails, die beide Teile mitliefern, signalisieren hingegen einen sorgfältigen Versandprozess.

Die Textversion: unterschätzt, aber wichtig

In der Praxis wird die Textversion einer Multipart-E-Mail häufig stiefmütterlich behandelt. Viele Versandtools generieren sie automatisch aus dem HTML-Code – was zu Ergebnissen führt, die alles andere als lesefreundlich sind: HTML-Tags als roher Code, unleserliche Link-URLs, fehlende Absatzstruktur. Das ist zwar technisch valide, aber eine vertane Chance.

Eine sorgfältig gestaltete Textversion liest sich wie eine normale, klar strukturierte schriftliche Kommunikation. Sie enthält alle wichtigen Inhalte der HTML-Version – Kernbotschaft, wesentliche Links, Call-to-Action –, verzichtet aber konsequent auf alles, was nur visuell wirkt. Wer sich die Mühe macht, die Textversion manuell zu pflegen oder zumindest die automatisch generierte Version zu überprüfen und zu bereinigen, erzielt auch in reinen Textumgebungen ein professionelles Erscheinungsbild.

Multipart im Überblick: Verwandte Begriffe

E-Mail-Marketing: Der übergeordnete Marketingkanal, in dem Multipart als technischer Standard für den professionellen E-Mail-Versand eingesetzt wird.

MIME (Multipurpose Internet Mail Extensions): Das technische Protokoll, das die Struktur von E-Mails mit mehreren Inhaltsteilen definiert – Multipart ist ein MIME-Typ innerhalb dieses Standards.

HTML-E-Mail: Die gestaltete Version einer Multipart-E-Mail mit Formatierungen, Bildern, Farben und klickbaren Elementen – das Format, das die meisten Empfänger zu sehen bekommen.

Plaintext-E-Mail: Die reine Textversion ohne jede Formatierung, die als Fallback innerhalb einer Multipart-E-Mail mitgeliefert wird und in Umgebungen zum Einsatz kommt, die kein HTML unterstützen.

Zustellbarkeit (Deliverability): Die Fähigkeit einer E-Mail, tatsächlich im Posteingang des Empfängers zu landen – eine korrekte Multipart-Struktur trägt zur positiven Bewertung durch Spam-Filter bei.

E-Mailing: Eine einzelne Massen-E-Mail-Sendung im Rahmen des E-Mail-Marketings – für professionelle E-Mailings ist das Multipart-Format heute technischer Mindeststandard.

FAQs zu Multipart-E-Mails

Was ist eine Multipart-E-Mail – und wie funktioniert das technische Prinzip?

Eine Multipart-E-Mail (auch: Multipart/Alternative-E-Mail) ist eine E-Mail, die denselben Inhalt in zwei verschiedenen Formaten gleichzeitig enthält: als HTML-Version mit gestaltetem Layout, Farben, Bildern und Links, und als Plaintext-Version mit reinem, unformatiertem Text. Das empfangende E-Mail-Programm entscheidet anhand seiner Einstellungen und Fähigkeiten eigenständig, welche Version dem Empfänger angezeigt wird – der Absender sendet also einen einzigen Datensatz, der beide Varianten in sich trägt.

Das technische Fundament ist der MIME-Standard (Multipurpose Internet Mail Extensions, RFC 2045 ff.), der 1992 eingeführt wurde, um E-Mails über den ursprünglich nur für ASCII-Text ausgelegten SMTP-Standard hinaus um Anhänge, Zeichensätze und Multipart-Strukturen zu erweitern. Bei einer Multipart/Alternative-E-Mail werden die einzelnen Inhaltsteile durch einen sogenannten Boundary-String – eine eindeutige Zeichenkette im E-Mail-Header – voneinander getrennt. Der Header der E-Mail enthält den Content-Type multipart/alternative sowie die Boundary-Definition; jeder Inhaltsteil ist dann mit dem entsprechenden MIME-Type (text/plain bzw. text/html) gekennzeichnet.

Welche MIME-Typen gibt es bei Multipart-E-Mails – und was ist der Unterschied zwischen multipart/alternative und multipart/mixed?

Der Begriff „Multipart" bezeichnet im MIME-Standard eine ganze Familie von Inhaltstypen, die sich in ihrer Verwendung deutlich unterscheiden:

  • multipart/alternative: Der häufigste Typ im E-Mail-Marketing. Die enthaltenen Teile sind inhaltlich äquivalent – dieselbe Nachricht in verschiedenen Formaten (Plaintext und HTML). Das empfangende Mail-Programm zeigt nur die Version an, die es bevorzugt oder die es darstellen kann. Per RFC-Empfehlung steht die bevorzugte Version (HTML) zuletzt im MIME-Körper, da viele Clients das letzte passende Segment verwenden.
  • multipart/mixed: Wird verwendet, wenn eine E-Mail aus mehreren unabhängigen Teilen besteht, die alle angezeigt werden sollen – typischerweise der eigentliche Nachrichtentext kombiniert mit einem oder mehreren Dateianhängen (z. B. ein PDF oder ein Bild als Attachment). Die Teile sind hier nicht austauschbar, sondern ergänzen sich.
  • multipart/related: Gedacht für E-Mails, bei denen HTML-Inhalt direkt mit eingebetteten Ressourcen verknüpft ist – etwa inline-eingebettete Bilder, auf die der HTML-Teil per cid:-Referenz verweist. Wird für aufwändig gestaltete HTML-Mails mit eingebetteten (nicht verlinkten) Bildern verwendet.
  • multipart/report: Technischer Typ für Bounce-Nachrichten und Zustellberichte (Delivery Status Notifications), den E-Mail-Server automatisch generieren.

In der Praxis des E-Mail-Marketings ist multipart/alternative mit den Subtypes text/plain und text/html der Standard. Wenn die E-Mail zusätzlich Dateianhänge enthält, wird häufig eine verschachtelte Struktur verwendet: multipart/mixed als äußerer Container, der seinerseits einen multipart/alternative-Block für den Nachrichtentext und separate application/...-Teile für die Anhänge enthält.

Warum ist die Plaintext-Version in Multipart-E-Mails für Zustellbarkeit und Spam-Filter wichtig?

Die Plaintext-Version einer Multipart-E-Mail ist weit mehr als ein technisches Fallback für veraltete E-Mail-Clients – sie hat direkte Auswirkungen auf die Zustellbarkeit und die Spam-Bewertung einer E-Mail:

  • Spam-Filter-Bewertung: Viele Spam-Filter – darunter SpamAssassin, der weit verbreiteteste Open-Source-Filter – werten das Fehlen einer Plaintext-Version als negatives Signal. Eine reine HTML-E-Mail ohne Plaintext-Pendant erhöht den Spam-Score messbar, weil Spam-Mails historisch häufig nur als HTML versendet wurden, um Text vor Filtern zu verbergen. Wer ausschließlich HTML sendet, riskiert höhere Spam-Einstufungsraten.
  • Darstellung in speziellen Clients und Umgebungen: Bestimmte E-Mail-Clients, Corporate-Firewalls und E-Mail-Gateways blockieren HTML-Inhalte grundsätzlich oder zeigen nur Plaintext an – beispielsweise in stark regulierten Branchen (Recht, Behörden, Finanzwesen) oder bei sehr restriktiven IT-Richtlinien. Ohne Plaintext-Version erhalten diese Empfänger unlesbaren Quellcode.
  • Barrierefreiheit und Screenreader: Für Nutzer mit Sehbeeinträchtigungen, die Screenreader verwenden, ist eine sauber strukturierte Plaintext-Version oft besser lesbar als komplexes HTML-Layout.
  • Qualitätssignal für ISPs: Große Postfachanbieter wie Gmail, Microsoft 365 und Yahoo bewerten das Gesamtbild einer E-Mail. Eine sorgfältig gepflegte, inhaltlich zur HTML-Version äquivalente Plaintext-Version signalisiert technische Sorgfalt und korreliert positiv mit Reputationswerten des Absenders.

Die Plaintext-Version sollte inhaltlich der HTML-Version entsprechen – nicht leer sein, nicht nur aus einer URL bestehen und keine reinen Platzhaltertexte wie „Wenn Sie diese E-Mail nicht korrekt sehen können..." enthalten. Gute ESP-Systeme (E-Mail Service Provider) wie CleverReach, Mailchimp oder HubSpot generieren die Plaintext-Version auf Wunsch automatisch aus dem HTML-Quellcode.

Wann wird in einer Multipart-E-Mail die HTML- und wann die Plaintext-Version angezeigt?

Welche Version der Multipart-E-Mail der Empfänger tatsächlich sieht, entscheiden nicht der Absender, sondern das empfangende E-Mail-Programm und die Einstellungen des Nutzers. Die Entscheidungslogik im Überblick:

  • HTML wird angezeigt (Normalfall): Die große Mehrheit moderner E-Mail-Clients – Gmail, Outlook, Apple Mail, Thunderbird, Yahoo Mail – unterstützt HTML-E-Mails und zeigt standardmäßig die HTML-Version an. Für den typischen Empfänger im E-Mail-Marketing ist die HTML-Darstellung der Regelfall.
  • Plaintext wird angezeigt, wenn: Der Nutzer in seinem E-Mail-Client explizit eingestellt hat, E-Mails nur als Text anzuzeigen. Das Unternehmens-E-Mail-Gateway oder eine Firewall HTML-Inhalte blockiert. Der E-Mail-Client kein HTML unterstützt (z. B. sehr alte oder textbasierte Clients wie Mutt). Der Nutzer auf einem Gerät oder in einer Umgebung liest, in der HTML-Rendering nicht verfügbar ist (z. B. bestimmte Smartwatch-Notifications).
  • Preview-Text (Preheader) in allen Versionen: Der Preheader-Text, der in der E-Mail-Listenansicht als Vorschautext neben dem Betreff angezeigt wird, wird aus dem Anfang der HTML-Version extrahiert – unabhängig davon, welche Version der Client letztlich darstellt. Er sollte im HTML-Template als unsichtbarer Text (weißer Text oder display:none) oder als ersten sichtbaren Textblock eingebunden werden.
  • Tracking-Pixel funktionieren nur in HTML: Öffnungstracking über 1×1-Pixel-Bilder funktioniert ausschließlich in der HTML-Version. Empfänger, die ausschließlich die Plaintext-Version öffnen, werden in Öffnungsrate-Auswertungen nicht erfasst – was die gemessene Öffnungsrate systematisch unterschätzen lässt.

Wie erstellt man eine korrekte Multipart-E-Mail – und worauf ist bei HTML-E-Mails besonders zu achten?

In der Praxis des E-Mail-Marketings erstellt kaum jemand Multipart-E-Mails manuell im MIME-Rohformat – das übernehmen E-Mail-Marketing-Plattformen und ESP-Systeme automatisch. Dennoch gibt es handwerkliche Aspekte, die direkten Einfluss auf Darstellung und Zustellbarkeit haben:

  • HTML für E-Mail ist nicht HTML für Websites: E-Mail-Clients rendern HTML deutlich restriktiver und inkonsistenter als Browser. Modernes CSS (Flexbox, Grid, externe Stylesheets) wird von vielen Clients nicht unterstützt. E-Mail-HTML verwendet traditionell tabellenbasierte Layouts und Inline-CSS – auch 2026 noch der zuverlässigste Weg für konsistente Darstellung quer über alle Clients.
  • Responsive E-Mail-Design: Da über 50 % aller E-Mails auf Smartphones geöffnet werden, sind Media Queries und fluid Layouts für mobile Darstellung unverzichtbar. Tools wie MJML (ein E-Mail-spezifisches Markup-Framework) oder Frameworks wie Foundation for Emails vereinfachen responsives E-Mail-HTML erheblich.
  • Bilder: Bilder sollten extern gehostet (auf einem CDN) und nicht inline eingebettet sein, da viele E-Mail-Clients Bilder standardmäßig blockieren. Alt-Texte für alle Bilder sind Pflicht – sowohl für Clients ohne Bildanzeige als auch für Barrierefreiheit. Dateigröße pro Bild möglichst unter 100 KB halten.
  • Plaintext sorgfältig pflegen: Automatisch generierte Plaintext-Versionen aus ESP-Systemen sind oft unstrukturiert und schwer lesbar. Eine manuell nachbearbeitete Plaintext-Version mit klaren Absätzen, vollständig ausgeschriebenen URLs und sinnvoller Gliederung verbessert sowohl Spam-Scores als auch die Nutzererfahrung von Plaintext-Lesern.
  • Testing vor dem Versand: Tools wie Litmus oder Email on Acid rendern E-Mails in über 90 verschiedenen Client-/Betriebssystem-Kombinationen vor – unverzichtbar, um Layout-Brüche in Outlook, Apple Mail, Gmail App und anderen Clients vor dem Versand zu erkennen.

Ist das Multipart-Format 2026 noch zeitgemäß – oder gibt es neuere Alternativen?

Das Multipart-Format ist seit über 30 Jahren der technische Standard für HTML-E-Mails – und bleibt es auch 2026. Neue Entwicklungen ergänzen das Format, ersetzen es aber nicht:

  • Dark Mode als neue Rendering-Herausforderung: Viele E-Mail-Clients (Apple Mail, Outlook, Gmail) unterstützen inzwischen einen Dark Mode, der E-Mail-Designs automatisch invertiert oder anpasst – oft mit unerwünschten Effekten auf Farbgebung und Kontraste. Moderne E-Mail-Templates berücksichtigen Dark-Mode-spezifisches CSS (@media (prefers-color-scheme: dark)) als dritten Darstellungspfad neben der Desktop- und mobilen HTML-Version – das Multipart-Grundkonzept bleibt dabei unberührt.
  • AMP for Email (multipart/x-amp-html): Google hat 2019 AMP for Email eingeführt – einen vierten MIME-Teil (text/x-amp-html), der interaktive Inhalte direkt in E-Mails ermöglicht: Karussells, Formulare, Echtzeit-Datenupdates, ohne dass der Nutzer die E-Mail verlassen muss. Gmail und Yahoo Mail unterstützen AMP for Email; die Verbreitung bleibt aber begrenzt, da Implementierung und Sicherheitsfreigaben aufwändig sind.
  • KI-gestützte Personalisierung im Multipart-Kontext: KI-Systeme in modernen ESPs (HubSpot, Salesforce Marketing Cloud, Klaviyo) generieren zunehmend personalisierte HTML- und Plaintext-Inhalte dynamisch auf Empfängerebene – Betreffzeilen, Produktempfehlungen und Inhaltsblöcke werden individuell zusammengestellt. Das technische Trägersystem bleibt dabei das klassische Multipart-Format.
  • Apple Mail Privacy Protection (MPP): Seit iOS 15 lädt Apple Mail alle E-Mail-Bilder – einschließlich Tracking-Pixel – vorab im Hintergrund, unabhängig davon, ob der Nutzer die E-Mail tatsächlich öffnet. Das verfälscht Öffnungsraten massiv und schwächt das Öffnungs-Tracking als KPI. Die Plaintext-Version gewinnt dadurch indirekt an Bedeutung, da Click-Tracking als zuverlässigere Alternativkennzahl in den Vordergrund rückt.

Fazit: Das Multipart-Format ist keine veraltete Technologie, sondern die stabile Infrastruktur, auf der alle Weiterentwicklungen des E-Mail-Marketings aufsetzen. Wer E-Mails professionell versendet, kommt an einer sorgfältig gepflegten Multipart-Struktur nicht vorbei.

letzte Aktualisierung: 25. März 2026