Definition
HTML vs. Plaintext beschreibt zwei unterschiedliche Arten, E-Mails technisch und visuell aufzubauen. HTML-Mails enthalten Formatierung, Farben, Buttons, Bilder und häufig Tracking-Elemente. Plaintext-Mails bestehen aus einfachem Text ohne Layout.
Für Deliverability ist das keine bloße Designentscheidung. Die Wahl beeinflusst, wie komplex eine Nachricht technisch ist, welche Signale Spam-Filter sehen und wie glaubwürdig die Mail im jeweiligen Kommunikationskontext wirkt.
Warum diese Entscheidung im B2B mehr als Optik ist
Im B2B-Outbound konkurrieren oft zwei Ziele: Die Mail soll professionell aussehen, aber nicht nach Massenkampagne wirken. Genau deshalb ist die Frage „HTML oder Plaintext?“ strategisch relevant. Sie beeinflusst, ob eine Nachricht als natürliche Arbeitsmail wahrgenommen wird oder als automatisierter Marketingversand auffällt.
Plaintext reduziert technische Komplexität und wirkt näher an echter 1:1-Kommunikation. HTML schafft Struktur, Branding und visuelle Führung. Beides kann sinnvoll sein. Problematisch wird es dann, wenn Format und Kommunikationsanlass nicht zusammenpassen. Eine kalte SDR-Mail mit Banner und CTA-Button sendet ein anderes Signal als ihr Text behauptet. Umgekehrt kann eine komplexe Event-Mail in reinem Plaintext unnötig sperrig wirken.
Technische Unterschiede, die Deliverability wirklich beeinflussen
Plaintext enthält im Wesentlichen nur Text und Zeilenumbrüche. Es gibt keine Bilder, keine Buttons und kaum versteckte technische Marker. HTML-Mails enthalten dagegen Code, Styles, Tabellen, verlinkte Elemente, zum Teil Tracking-Pixel und je nach Tool zusätzliche Metadaten. Damit steigt automatisch die Zahl der Prüfpunkte für Provider und Security-Systeme.
Das bedeutet nicht, dass HTML per se schlecht ist. Ein sauber gebautes HTML-Mail kann sehr stabil zugestellt werden. Aber je mehr Formatierung, Bilder, Buttons, Social-Icons und Tracking zusammenkommen, desto eher entstehen Auffälligkeiten: ungünstiges Text-Link-Verhältnis, überladener Code, inkonsistente Darstellung zwischen Clients oder ein Look, der nicht zur Rolle des Absenders passt.
Wichtig ist außerdem der Unterschied zwischen einer reinen HTML-Mail und einer Multipart-Mail. Letztere enthält eine HTML-Version und eine Plaintext-Version derselben Nachricht. Das ist technisch oft robuster, weil verschiedene Clients und Filter konsistentere Signale erhalten und notfalls auf die Textvariante zurückfallen können.
Wann Plaintext meist die bessere Wahl ist
Für kalte Erstansprache, kurze Follow-ups mit persönlichem Charakter oder kleine Gesprächsanbahnungen ist Plaintext oft die robustere Form. Solche Mails sehen aus wie normale Arbeitskommunikation, laden schnell und erzeugen wenig gestalterische Reibung. Das ist besonders hilfreich, wenn der Absender als Person und nicht als Kampagne wahrgenommen werden soll.
Ein typischer B2B-Fall: Ein SDR schreibt einer Vertriebsleiterin mit einem präzisen Problembezug und einer klaren Frage. Eine schlanke Plaintext-Mail mit sauberem Absatzbau wirkt hier meist glaubwürdiger als ein HTML-Layout mit Markenfarben, CTA-Button und Signaturblock im Newsletter-Stil.
Plaintext ist außerdem operativ nützlich, wenn Teams zunächst Messaging, Zielgruppenfit und Antwortqualität validieren wollen. Weniger Technik heißt weniger Variablen, die das Ergebnis verfälschen.
Wann HTML echten Mehrwert stiftet
HTML ist dann sinnvoll, wenn Struktur oder visuelle Führung die Verständlichkeit wirklich verbessern. Das gilt zum Beispiel für Event-Einladungen, Webinar-Reminder, Produktupdates, Bestandskunden-Nurturing, transaktionale Mails oder Newsletter mit mehreren Modulen. In solchen Fällen erwartet der Empfänger eher ein formatiertes Layout.
Auch hier gilt aber: zurückhaltend schlägt überladen. Eine kurze HTML-Mail mit klaren Abschnitten, wenig visueller Last und sauberem Fallback kann gut funktionieren. Eine überdesignte Mail mit Hero-Bild, drei Buttons, Social-Icons, Footer-Linkfriedhof und aggressivem Tracking wirkt im B2B schnell wie Marketingautomation – selbst wenn der Inhalt fachlich relevant wäre.
Render- und Client-Themen, die Teams unterschätzen
Ein häufiger Praxisfehler ist die Annahme, dass eine Mail überall gleich aussieht. Outlook, Gmail, Apple Mail, mobile Clients und Security-Layer in Unternehmensumgebungen rendern HTML unterschiedlich. Was im Tool-Preview sauber erscheint, kann im realen Postfach kippen: verrutschte Abstände, abgeschnittene Buttons, unleserliche Dark-Mode-Kontraste oder gebrochene Tabellenlayouts.
Plaintext hat andere Risiken. Zu lange Zeilen, schlechter Absatzbau, unklare CTAs oder rohe, unleserliche URLs können eine Nachricht ebenfalls schwer lesbar machen. Plaintext ist also nicht automatisch gut – nur weil es schlicht ist. Auch schlichte Mails brauchen handwerkliche Sorgfalt.
Deshalb sollte jede Versandform nicht nur auf Zustellbarkeit, sondern auch auf reale Lesbarkeit geprüft werden: Desktop, mobil, Outlook-lastige Umgebungen und echte Postfächer statt nur Tool-Vorschau.
Typische Fehler und Missverständnisse
- Plaintext sei automatisch inbox-sicher.
- HTML wirke immer professioneller.
- Ein Button konvertiere grundsätzlich besser als ein normaler Textlink.
- Design könne Relevanzprobleme im Inhalt kompensieren.
- Eine HTML-Mail ohne Plaintext-Alternative sei technisch egal.
Keiner dieser Punkte stimmt pauschal. Plaintext rettet keine schlechte Listenqualität oder beschädigte Domain-Reputation. HTML ist nicht schlecht, solange es technisch sauber und zum Anlass passend eingesetzt wird. Und ein schönes Layout macht eine irrelevante oder generische Nachricht nicht plötzlich überzeugend.
Operative Entscheidungslogik für B2B-Teams
Statt die Frage ideologisch zu behandeln, sollten Teams sie pro Use Case entscheiden. Hilfreich ist eine einfache Matrix:
- Kalter Erstkontakt: meist plaintext oder plaintext-nah
- Follow-up mit persönlichem Charakter: eher schlicht, wenige Links, wenig Design
- Event, Webinar, Reminder: moderates HTML kann sinnvoll sein
- Newsletter oder Customer Marketing: HTML oft passend, solange Technik und Tracking diszipliniert bleiben
- Transaktionale Kommunikation: HTML okay, wenn Übersicht und Verlässlichkeit im Vordergrund stehen
Ein guter operativer Test lautet: Sieht die technische Form so aus wie die Art von Kommunikation, die sie behauptet zu sein? Wenn eine Mail wie persönliche 1:1-Kommunikation klingen will, sollte sie nicht wie eine Kampagne aussehen.
Anwendung im Vertrieb
Für kalte B2B-Akquise gilt meist: zuerst Plaintext oder plaintext-nahe Mails einsetzen, später gegebenenfalls mehr HTML, wenn Vertrauen vorhanden ist oder der Kontext strukturiertere Kommunikation rechtfertigt. Für Newsletter, Bestandskundenstrecken und transaktionale Prozesse darf HTML deutlich mehr leisten – solange Linkmenge, Tracking und Design nicht außer Kontrolle geraten.
Teams, die hier sauber entscheiden, vermeiden nicht nur Deliverability-Probleme, sondern reduzieren auch unnötige Stilbrüche zwischen Absenderrolle, Angebotslogik und technischer Verpackung.
Kurzfazit
- HTML vs. Plaintext ist eine Zustell- und Glaubwürdigkeitsfrage, nicht nur eine Designfrage.
- Plaintext passt oft besser zu kalter, persönlicher B2B-Ansprache.
- HTML ist sinnvoll, wenn Struktur echten Nutzen stiftet und technisch sauber umgesetzt ist.
FAQ
Ist Plaintext immer besser für kalte Akquise?
Oft ja, aber nicht automatisch. Entscheidend sind auch Listenqualität, Domain-Reputation, Nachrichtenqualität und Versandmuster.
Sollte man komplett auf HTML verzichten?
Nein. HTML ist für viele Formate sinnvoll. Es sollte nur nicht dort dominieren, wo persönliche 1:1-Kommunikation glaubwürdig wirken soll.
Was ist mit Multipart-Mails?
Sie sind häufig ein guter Standard, weil sie HTML- und Textversion kombinieren und damit technisch robuster für unterschiedliche Clients sind.
Warum sind Buttons in kalten Mails oft kritisch?
Weil sie schneller nach Marketingautomation aussehen. Ein normaler Textlink wirkt in persönlicher B2B-Kommunikation oft natürlicher.
Kann HTML trotz guter Zustellbarkeit trotzdem schaden?
Ja. Selbst wenn die Mail technisch ankommt, kann ein überdesigntes Layout Vertrauen und Antwortbereitschaft senken, wenn es nicht zum Kommunikationsanlass passt.