KI für HTML-E-Mails: was ChatGPT, Claude und Gemini wirklich liefern

In E-Mail-Marketing-Kreisen kursiert gerade eine Frage, und sie klingt meistens so: Jetzt, wo ich eine KI in zehn Sekunden eine HTML-E-Mail bauen lassen kann, brauche ich überhaupt noch einen E-Mail-Builder?

Die Frage ist berechtigt. E-Mail ist kein kleiner Kanal. Weltweit werden Stand 2025 376 Milliarden E-Mails pro Tag verschickt (Radicati), der Kanal bringt laut Litmus weiterhin rund $36 für jeden investierten $1 zurück, und laut HubSpots Untersuchung zu KI-Trends 2025 setzt inzwischen eine Mehrheit der Marketer irgendwo im Workflow KI ein. Wenn ein Tool aus einem einzeiligen Prompt eine fertige Vorlage erzeugt, wirkt es wie ein klarer Gewinn, den Builder einfach zu überspringen.

Dann verschickst du das Ding wirklich, und das Bild kippt schnell. Über alle E-Mails hinweg, die wir bei Unspam prüfen, bestehen nur 30 % unsere Prüfung der HTML-Best-Practices (die Benchmark-Zahlen in diesem Artikel stammen aus unserem Benchmark zur Zustellbarkeit, rollierende zwölf Monate bis Juni 2026). Der HTML-Body ist der schwächste Einzelteil der durchschnittlichen Kampagne, die wir messen: schwächer als Betreffzeilen, schwächer als Links, schwächer sogar als Spam-Trigger-Sprache. Und genau dieser Teil wandert gerade an ein Werkzeug, das nie dafür gebaut wurde.

Diese Lücke ist die ganze Geschichte. Diese Tools sind gut darin, eine E-Mail zu schreiben. Gut darin, E-Mail-HTML zu schreiben, sind sie noch nicht, und das sind zwei sehr verschiedene Dinge. Dieser Artikel geht durch, was die großen KI-Tools tatsächlich ausgeben, warum E-Mail-HTML eine eigene Sprache ist, wo sich der Unterschied im Posteingang zeigt und wie ein eigens dafür gebauter Builder wie Postcards die Lücke schließt. Am Ende steht eine Scorecard für den Versand, an der du jede E-Mail messen kannst, egal ob ein Modell sie geschrieben hat oder du.

Ein Gedanke zieht sich durch alles, deshalb gleich hier in klaren Worten: im Browser fertig aussehen und im Posteingang korrekt rendern sind zwei verschiedene Dinge, und der einzige Test, der klärt, was von beidem du hast, ist die echte Prüfung im Posteingang.

Darum geht es in diesem Artikel:

• Warum Web-HTML und E-Mail-HTML zwei völlig verschiedene Sprachen sind und an welchen Regeln die Lücke konkret hängt
• Was v0, Bolt, Cursor, Replit, ChatGPT, Claude, Gemini und Lovable standardmäßig produzieren und wo jedes davon scheitert
• Wie sich KI im ESP und eigene E-Mail-Builder bei Portabilität und Rendering schlagen
• Wo dich kaputtes HTML Platzierung im Posteingang kostet, in Daten aus dem eigenen Benchmark von Unspam
• Eine Scorecard mit zwölf Punkten, die jede E-Mail vor dem Versand erfüllen sollte
• Der Workflow, der KI dort einsetzt, wo sie hilft, und einen getesteten Builder dort, wo es darauf ankommt

Web-HTML und E-Mail-HTML sind nicht dieselbe Sprache

Dass KI-Tools mit E-Mail kämpfen, hat nichts damit zu tun, wie klug das Modell ist. Es liegt daran, dass fast jeder KI-Builder darauf trainiert wurde, moderne Webseiten zu produzieren, und E-Mail auf einem völlig anderen, viel älteren Regelwerk aufsetzt.

Ein Browser ist eine Engine, ein Posteingang sind Dutzende

Ein Webbrowser ist eine einzige, moderne, standardkonforme Rendering-Engine. Ein Posteingang sind Dutzende inkonsistente. Einer der am weitesten verbreiteten geschäftlichen E-Mail-Clients, Outlook unter Windows, rendert dein HTML mit der Microsoft-Word-Engine, nicht mit einem Browser. Gmail schreibt Teile deines Codes um und entfernt andere, bevor es sie anzeigt. Die Referenzseite Can I Email verfolgt mehr als 300 HTML- und CSS-Features über rund 20 E-Mail-Clients hinweg, ein großer Sprung gegenüber den 50 Features zum Start 2019. Viele Einträge wurden zuletzt vor Jahren getestet, die Support-Zahlen sind also eher Schätzungen als eine Momentaufnahme, und der Abstand zwischen dem besten und dem schwächsten Client ist enorm.

Wo deine Leser Mail tatsächlich öffnen

Hier lesen die meisten Menschen, und genau das macht die Sache relevant:

Apple Mail und Gmail zusammen machen rund 89 % der Öffnungen aus. (Apples Zahl ist aufgebläht, weil Mail Privacy Protection viele Öffnungen zählt, hinter denen kein Mensch stecken muss. Nimm sie als Obergrenze, die Konzentration ist aber real.) Der Haken: Gmail, der zweithäufigste Client, ist zugleich einer der aggressivsten beim Umschreiben deines CSS, und das klassische Outlook ist zwar klein im Anteil, aber in Büros weiterhin breit installiert und der Ort, an dem Layouts am übelsten brechen. Ausgerechnet die Clients, die Web-typisches HTML bestrafen, kannst du also nicht ignorieren.

Die konkreten Unterschiede, die KI falsch macht

Das sind die konkreten Unterschiede, die ein KI-Tool treffen muss und meistens verfehlt:

Für einen E-Mail-Entwickler ist nichts davon exotisch. Für ein Tool, das für Webseiten gebaut wurde, und für die Person, die es promptet, ist es schlicht unsichtbar. Wenn du tiefer in die Regeln selbst einsteigen willst: Unser Leitfaden zu den Best Practices für E-Mail-HTML behandelt die Handarbeit im Detail.

Warum die Support-Prozente lügen

Es ist leicht, ein Feature nachzuschlagen, eine hohe Support-Zahl zu sehen und sich sicher zu fühlen. Meistens bist du das nicht, denn die Zahlen verbergen, wo die Lücken liegen. Laut Can I Email zeigen display: flex und display: grid jeweils rund 83 % Unterstützung, was gut klingt, bis du dich erinnerst, dass die Word-Engine in Outlook beides ignoriert und ein Layout auf Flex- oder Grid-Basis dort still zusammenfällt. Die CSS-Eigenschaft position kommt auf etwa 80 %, davon ist aber nur ein Drittel volle Unterstützung und der Rest teilweise: Die meisten Clients beachten nur einzelne Werte, Outlook Desktop keinen davon. Webfonts über @font-face liegen bei rund 24 %, CSS Custom Properties (Variablen) bei rund 45 %, wobei das klassische Outlook gar keine Variablen unterstützt und Gmail zwar var() zulässt, nicht aber die Deklarationen, die sie definieren. Genau dieses Paar ist der Grund, warum KI-Output, der auf eine Webfont und ein variablengetriebenes Farbsystem setzt, also exakt so, wie ein Modell eine moderne Webseite stylt, seine Typografie und seine Markenfarben verliert, sobald er in einem echten Posteingang landet. Ein Prozentwert in der Überschrift ist ein Durchschnitt über Clients, die alle gleich gewichtet werden. E-Mail funktioniert nicht so.

Was allgemeine KI-Tools tatsächlich ausgeben

Fang bei den Tools an, zu denen die meisten zuerst greifen: den Website- und App-Buildern und den Chatbots. Wichtig zu verstehen ist, dass keines davon ein E-Mail-Produkt ist. Es sind Web-Generatoren, die nebenbei HTML ausgeben, und deshalb werden sie zweckentfremdet.

Die App-Builder: richtiges Werkzeug, falsche Aufgabe

v0, Bolt, Cursor und Replit sind App-Builder. Diese Tools um eine E-Mail zu bitten, ist wie eine Textverarbeitung um eine Tabellenkalkulation zu bitten: Du kannst es erzwingen, kämpfst aber die ganze Zeit gegen das Werkzeug, und heraus kommt modernes Web-HTML, das ein Posteingang nie so rendern würde, wie die Vorschau es versprochen hat.

Die Chatbots und die Vorschau-Falle

Die Chatbots verdienen eine eigene Warnung, weil sie eine Falle aufbauen. ChatGPT Canvas und Claude Artifacts rendern beide eine Live-Vorschau des HTML, das sie erzeugen. Diese Vorschau nutzt eine Browser-Engine. Deine KI-E-Mail sieht auf dem Bildschirm also fertig und poliert aus, und genau deshalb bleibt der Schaden unsichtbar, bis du sie an einen echten Posteingang schickst. Das ist der größte Einzelgrund, warum sich Leute die Finger verbrennen: Die Vorschau lügt, nicht mit Absicht, sondern weil ein Browser kein Outlook ist.

Die Fehlerbilder wiederholen sich. Ein Layout, das in der Vorschau sauber wirkt, stützt sich auf Eigenschaften, die Outlook ignoriert, etwa max-width auf einer Tabelle oder Flexbox, also fallen Spalten zusammen oder laufen über den Rand. Webfonts fallen auf einen Standard wie Times New Roman zurück. Runde Buttons werden eckig. Und jedes Styling, das nie inline gesetzt wurde, verschwindet in Teilen von Gmail schlicht.

Der letzte Punkt lohnt eine konkrete Ausführung, denn er wiegt schwerer, als er klingt. Wenn die Gmail-App Mail aus einem Nicht-Google-Konto rendert, ein Setup, das verbreitet genug ist, um einen eigenen Spitznamen zu haben (GANGA, Gmail App with Non-Google Accounts), unterstützt sie das Tag <style> überhaupt nicht, jede Regel also, die ein Modell in einem Style-Block im Head gelassen hat, fällt für dieses gesamte Lesersegment weg. Gmail ist bei eingebetteten Styles außerdem alles oder nichts: Ein einziger Fehler, der ihm missfällt, etwa eine @font-face- oder @media-Regel, die in einer anderen At-Regel steckt, führt dazu, dass es den ganzen Style-Block entfernt, und es setzt eine harte Größengrenze pro Block durch (historisch rund 8 KB). Ein Chatbot, der selbstbewusst dein gesamtes CSS in ein großes <style>-Tag stapelt, schreibt genau das, was Gmail am ehesten wegwirft.

Die eine teilweise Ausnahme

Lovable ist die eine teilweise Ausnahme, die man nennen sollte. Weil es die E-Mail-Generierung über die Bibliothek React Email leitet, produziert es standardmäßig tabellenbasiertes Markup mit Inline-Styles, und die Dokumentation weist sogar auf die Clipping-Grenze von rund 102 KB bei Gmail hin. Das ist tatsächlich näher am Richtigen. Conditional Comments für Outlook, Dark Mode oder Apple-Mail-Eigenheiten deckt es von allein trotzdem nicht ab, und im Kern bleibt es ein Builder für Web-Apps. Es zeigt aber, wie es aussieht, wenn ein Tool E-Mail wirklich mitdenkt.

Einen Chatbot zu E-Mail-sicherem HTML lenken

Du bekommst brauchbaren Output aus einem allgemeinen Chatbot, aber nur, wenn du ihm das E-Mail-Wissen mitgibst, das er von sich aus nicht anwendet. In der Praxis heißt das: jede Anforderung im Prompt ausbuchstabieren. Das Minimum für brauchbaren Output:

• Das Layout auf verschachtelten Tabellen bauen, nicht auf Divs oder Flexbox
• Jeden Style inline am Element setzen, nicht in einem <style>-Block
• Outlook-spezifische Fixes in MSO Conditional Comments packen (<!--[if mso]>...<![endif]-->)
• Jeder Webfont einen echten benannten Fallback-Stack geben (Arial, Georgia, eine Systemschrift)
• Die gesamte Datei unter der Clipping-Grenze von rund 102 KB bei Gmail halten
• Sowohl eine HTML- als auch eine Plaintext-Version mitliefern

Selbst dann bleiben zwei Dinge wahr. Das Modell hält diesen Modus über Bearbeitungen hinweg nicht zuverlässig durch, die dritte Überarbeitung driftet also leise zurück in Web-Gewohnheiten. Und der einzige Weg herauszufinden, ob es sich daran gehalten hat, führt über einen Test in echten Clients, nicht über Vertrauen. Wenn du KI ohnehin schon für die Worte einsetzt: Unsere Sammlung an ChatGPT-Prompts fürs E-Mail-Marketing ist die bessere Nutzung derselben Werkzeuge.

„Aber in meiner E-Mail-Plattform steckt doch KI“

Als Nächstes kommt der Einwand, der eigene ESP oder Builder habe längst KI, damit sei die Sache erledigt. Manchmal. Der Haken: „KI für E-Mail“ bedeutet drei sehr verschiedene Dinge, und das Marketing verwischt sie mit Absicht.

Drei Dinge, die „KI für E-Mail“ heißen kann

• KI, die Texte schreibt. Betreffzeilen, Fließtext, ein Call to Action. Das ist die häufigste Variante und die risikoärmste, weil ein Mensch die Worte noch in ein getestetes Layout setzt.
• KI, die bearbeitbare Abschnitte zusammensetzt. Du bekommst eine grobe Struktur mit Platzhalterblöcken, die du von Hand fertigstellst. Die E-Mail-KI von Klaviyo arbeitet so, und die eigene Dokumentation hält fest, dass du Buttons, Links und Bilder weiterhin von Hand ergänzen musst, bevor es versandfertig ist.
• KI, die eine komplette Vorlage erzeugt. Layout, Text, manchmal Bilder, aus einem einzigen Prompt. Das ist die beeindruckende Demo, und zugleich der Punkt, an dem das Markup selbst zum ungeprüften Output wird.

Die Achse, auf die es für die Zustellbarkeit ankommt: Portabilität und Tests

Dann gibt es eine zweite Achse, die für die Zustellbarkeit noch mehr zählt: Kannst du das HTML überallhin mitnehmen, und prüft irgendetwas, wie es rendert? So schlagen sich die spezialisierten E-Mail-Builder, also die Tools, deren ganze Aufgabe darin besteht, dir portables HTML zu geben.

Alle vier exportieren portables HTML, das du zu jedem ESP mitnehmen kannst, und genau darum geht es bei einem Builder. Am stärksten unterscheiden sie sich darin, wie viel Arbeit die KI übernimmt. Postcards, Unlayer und Stripo bieten einen komplett Prompt-gesteuerten Workflow, während die KI von Beefree Texte und Bilder liefert und dir das Layout überlässt. Alle vier zeigen außerdem eine Rendering-Vorschau, aber eine schnelle Vorschau ist nicht dasselbe wie ein tiefer Client-übergreifender Test, sorgfältige Teams prüfen das fertige HTML deshalb vor dem Versand noch in einem eigenen Check. Der Kontrast zu einem ESP mit kompletten Vorlagen wie Mailchimp oder HubSpot fällt noch schärfer aus, denn solche Anbieter sperren den Output eher in den eigenen Versand ein, statt dir portablen Code zu geben. Einen vollständigen Vergleich dieser spezialisierten Builder nach Vorlagen, KI, Zusammenarbeit und Zustellbarkeit findest du in unserem Leitfaden zu den besten Buildern für E-Mail-Vorlagen für 2026.

Wo dich das wirklich etwas kostet: im Posteingang

Es ist verlockend zu behaupten, schlechtes HTML schicke dich direkt in den Spam. Ehrlicher und nützlicher ist es, präzise zu beschreiben, wie der Schaden wirklich entsteht, denn Übertreibung kostet Glaubwürdigkeit.

Schlechtes HTML führt nicht direkt in den Spam, sondern auf Umwegen

Moderne Filter bei Gmail, Outlook und Yahoo richten sich vor allem nach Absender-Reputation und der Interaktion der Empfänger, nicht nach einer aufgeräumten Bewertung der HTML-Qualität. Unsauberes KI-Markup löst deshalb selten eine direkte Strafe aus. Der echte Weg ist indirekt, und es ist der, den Litmus in seinem Leitfaden zur Zustellbarkeit vom Februar 2026 beschreibt: Eine E-Mail, die kaputt rendert, lässt Leute zweifeln, Zweifel senken die Interaktion und erhöhen Beschwerden, und schwache Interaktion plus Beschwerden sind exakt das, was deiner Absender-Reputation schadet und künftige Sendungen Richtung Spam drückt. Googles Regeln für Massenversender setzen für das schädlichste Signal eine harte Zahl: Halte Spam-Beschwerden unter 0,1 %, das ist eine von tausend. Eine Vorlage, die in einem Viertel aller Posteingänge kaputt aussieht, führt schnell über diese Linie.

Der HTML-Body ist der schwächste Teil der durchschnittlichen Kampagne

Dieses Muster sehen wir in unseren eigenen Daten. Über alle E-Mails hinweg, die in den rollierenden zwölf Monaten bis Juni 2026 durch Unspam gelaufen sind, ist der HTML-Body durchgehend der schwächste Bereich der gesamten Nachricht:

Lies die oberste Zeile noch einmal. HTML ist die Prüfung, an der die meisten E-Mails scheitern, mit großem Abstand und weit häufiger als an Betreffzeilen oder Spam-Wörtern. Und es ist zugleich die Prüfung, deren Gegenstand du am ehesten einem Chatbot überlässt.

Clipping, heuristische Filter und andere konkrete Haken

Zu kaputtem HTML gibt es noch ein paar konkrete Haken, die du kennen solltest:

• Ältere heuristische Filter existieren weiter unten in der Kette. Open-Source-Filter wie SpamAssassin bewerten reine HTML-Mail ohne Plaintext-Teil weiterhin negativ (ein paar Punkte wert), ebenso bildlastige Mail mit wenig Text. Das ist nicht das, was Gmail betreibt, aber es beschreibt genau die Muster, in die schluderiger KI-Output tendiert, und viele Unternehmens-Gateways setzen sie weiterhin ein.
• Clipping verbirgt deinen Abmeldelink. Wenn aufgeblähtes Markup dich über die Schwelle von rund 102 KB bei Gmail schiebt, kürzt Gmail die Nachricht. Lag dein Abmeldelink unterhalb des Schnitts, klicken genervte Leser stattdessen auf „Spam melden“. Beachte, dass externe Bilddateien nicht auf dieses Limit einzahlen, nur das Markup, und genau davon produzieren KI-Tools gern zu viel.
• Dark Mode lässt sich nicht gleichmäßig ausliefern. Die Query @media (prefers-color-scheme) liegt bei rund 42 % Unterstützung, wird von Gmail nur teilweise beachtet (es wendet eher eine eigene Farblogik an als deine Query) und von Yahoo in ungültige Syntax umgeschrieben. Outlook unter Windows ignoriert sie und schiebt stattdessen eigene Attribute ein, die du separat ansprechen musst, während Apple Mail reines #FFFFFF automatisch umdreht, weshalb sorgfältige Designer ein gebrochenes Weiß nehmen. Ein Modell, das eine hübsche Dark-Mode-Regel ausgibt, hat damit eine Minderheit der Clients abgedeckt, die deine E-Mail tatsächlich umfärben werden.
• Kaputtes HTML ist die Regel, nicht die Ausnahme. Das ist keine Eigenheit unserer Zahlen. Der Bericht zur Barrierefreiheit des Email Markup Consortium von 2026 hat 376.348 echte E-Mails analysiert und festgestellt, dass 99,88 % mit schweren oder kritischen Barrierefreiheits-Mängeln verschickt wurden, nur 8 bestanden jede Prüfung. Diese Mängel (Layout-Tabellen ohne Presentation-Rolle, fehlende Alt-Texte, keine Dokumentsprache) gehen auf dieselben Web-zuerst-Gewohnheiten zurück, und die Lehre trägt: Sauberes E-Mail-HTML ist selbst für Profis schwer, ein ungetesteter Auswurf aus einem Chatbot wird diese Grundlinie kaum schlagen.

Was ein Prozentpunkt Platzierung wert ist

Der Einsatz ist nicht abstrakt. Je nachdem, was dir eine einzelne E-Mail wert ist, liegt ein einziger Prozentpunkt Platzierung im Posteingang bei einem Versand an eine Million E-Mails zwischen rund $1.000 bei typischen $0.10 pro E-Mail und $20.000 bei einer hochwertigen Liste. So oder so ist eine Vorlage, die für ein Viertel deiner Liste leise bricht, echter wiederkehrender Umsatz und kein kosmetischer Schönheitsfehler. Wenn du sehen willst, wie deine eigene Versanddomain und deine Inhalte über diese Faktoren abschneiden: Der Benchmark zur Zustellbarkeit von Unspam zeigt aggregierte Daten aus Millionen von Tests, und du kannst deine eigene Nachricht vor dem Versand durch die Prüfungen weiter unten schicken.

Was E-Mail-tauglich wirklich heißt: die Scorecard vor dem Versand

Das Muster ist inzwischen klar: Ein KI-Entwurf kann fertig aussehen und trotzdem weit davon entfernt sein, versandfähig zu sein. Es hilft also, das vage Gefühl „das sieht fertig aus“ durch einen expliziten Maßstab zu ersetzen. Das ist der, an dem wir eine E-Mail messen, bevor sie rausgeht, egal wer oder was sie geschrieben hat.

Die Vorschau ist das irreführendste Signal in der E-Mail

Es lohnt sich, deutlich zu sagen, warum. Code, der in einem Browser-Tab oder im Vorschaufenster eines Chatbots perfekt rendert, fällt in Outlook, in der Gmail-App, in Yahoo- und AOL-Webmail und auf kleinen Mobilbildschirmen regelmäßig auseinander. Keiner dieser Fehler taucht im Browser auf, weil ein Browser keine dieser Engines ausführt. Der einzige aussagekräftige Test besteht darin, das echte HTML in einer Client-übergreifenden Rendering-Prüfung zu öffnen und sich die Screenshots anzusehen. Alles in der Scorecard unten ist etwas, das diese Prüfung bestätigen kann, eine Vorschau nicht.

Die Scorecard: zwölf Dinge, die vor dem Versand stimmen müssen

Warum eine fast perfekt wirkende E-Mail trotzdem durchfällt

Das Wichtige an dieser Liste: Sie ist kein Punktedurchschnitt. Eine E-Mail kann elf Zeilen glänzend erfüllen und wegen der zwölften trotzdem nicht einsetzbar sein. Ein einziger fehlender Abmeldelink, eine Schrift ohne Fallback oder ein nicht inline gesetztes Stylesheet reicht, um den Versand zu versenken. Deshalb sind „sieht zu 90 % fertig aus“ und „ist versandfähig“ zwei Aussagen ohne Zusammenhang. KI-Entwürfe scheitern permanent auf diese Weise: Das Design sieht großartig aus, und dann macht ein einziger blockierender Mangel leise das Ganze unversendbar.

Die meisten dieser blockierenden Mängel führen zu einem Client zurück. Das klassische Outlook für Windows, also die Versionen 2007 bis 2019 und der klassische Office-365-Desktop-Client, rendert mit der Microsoft-Word-Engine statt mit einem Browser. Diese Engine hat einen festen Satz an Verhaltensweisen, den jeder E-Mail-Entwickler auswendig kennt:

• Ignoriert CSS-width und -height, du musst also die HTML-Attribute width und height an Bildern setzen
• Entfernt padding und margin an Bildern, du polsterst deshalb die umgebende Tabellenzelle
• Ignoriert width und padding an Divs, weshalb Layouts Tabellen statt Divs nutzen
• Lässt den Zustand :hover komplett fallen
• Zeigt nur das erste Bild eines animierten GIF

Die Engine bringt auch eigene Fehler mit. Auf Windows-Anzeigen, die auf 125 % oder höher skaliert sind, verzerrt sie Layouts, sofern du nicht den Office-Namespace deklarierst und PixelsPerInch in einem Conditional-Block auf 96 setzt. Und sie fällt auf Times New Roman zurück, sobald eine Webfont an erster Stelle im Stack steht, es sei denn, du kapselst die @font-face-Regel so, dass Outlook sie nie sieht. Das sind keine Randfälle. Das ist das Standardverhalten der Engine hinter einem großen Teil der geschäftlichen E-Mail, und ein auf Webseiten trainiertes Modell hat keinen Grund, irgendeines der Gerüste zu schreiben, die das umgehen.

Am Horizont wird es heller. Das neue Outlook für Windows, seit 2022 in der Beta und seit 2023 im Windows Store, nutzt eine Web-Rendering-Engine statt Word, und Microsoft steuert Nutzer aktiv dorthin. Der klassische Client mit Word-Engine wird in den nächsten Jahren auslaufen, aber Microsoft hat für viele Pläne Support bis 2029 zugesagt, du musst also weiterhin für die Word-Engine bauen, weil ein spürbarer Teil deiner Empfänger sie weiterhin nutzt.

Prüfe deinen Entwurf dagegen, bevor er rausgeht

Die Scorecard nützt nur, wenn du eine E-Mail wirklich dagegen prüfst, und das musst du nicht mit dem Auge machen. Schick die fertige Nachricht durch ein Tool, das sie in echten Clients öffnet und diese Faktoren für dich prüft. Unser Spam-Check von Unspam deckt Inhalt, Authentifizierung und Code-Qualität ab, und der Inbox-Placement-Test zeigt, wo die Nachricht bei Gmail, Outlook und Yahoo tatsächlich landet. Das ist der Unterschied zwischen glauben, dass eine E-Mail fertig ist, und wissen, dass sie es ist.

Was dir ein eigens gebauter Builder gibt und wo KI hineinpasst

Das ist die Antwort auf die ursprüngliche Frage.

Tippen war nie der schwere Teil

Bei einem E-Mail-Builder ging es nie darum, dir das Tippen von HTML zu ersparen. Der schwere Teil ist, HTML zu erzeugen, das über Dutzende inkonsistente Clients hinweg gleich rendert und jede Zeile dieser Scorecard gleichzeitig erfüllt. Genau das löst ein getesteter Builder und ein Chatbot nicht.

LLM-Output gegen einen Builder, Standard für Standard

Stell beides nebeneinander gegen die Standards, die tatsächlich entscheiden, ob eine E-Mail rendert und ankommt. Hier steht roher Output eines allgemeinen LLM gegen das HTML, das ein eigens gebauter, Client-übergreifend getesteter Builder ausgibt.

Das Muster ist eindeutig: Das LLM optimiert darauf, was im Browser richtig aussieht, und der Builder darauf, was den Posteingang übersteht.

Wie die Scorecard von Haus aus erfüllt wird

Nimm Postcards als durchgerechnetes Beispiel. Die über 100 Module sind handgebaut und nach Angaben von Designmodo in Litmus und Email on Acid über 16 Clients hinweg getestet, darunter die, die Web-HTML zerlegen: Outlook Desktop, die Gmail-App, Apple Mail, Yahoo, sogar ältere Clients wie Lotus Notes. Jede Vorlage wird responsiv und im Dark Mode geprüft, und du siehst sie in Vorschauen auf echten Geräten statt in einer Browser-Annäherung. Der exportierte Code ist sauberes, produktionsreifes HTML, das du mit einem Klick zu den großen ESPs schieben kannst, darunter Mailchimp, HubSpot, Klaviyo, SendGrid, Brevo, Constant Contact, Zoho und SendPulse, oder das du einfach als rohes HTML herunterlädst. Der Einstieg ist kostenlos, bezahlte Stufen liegen bei $16 und $24 im Monat.

Übertrage das zurück auf die Scorecard, und der Wert wird konkret. Die Fallbacks für Outlook und MSO, das Inline-CSS, das Verhalten im Dark Mode und das Client-übergreifende Rendering sind nichts, was du hinterher prüfst, sie sind vorab erfüllt, weil die Module bereits so gebaut und getestet wurden. Du startest mit einer bestandenen Note, statt dich zu ihr zurückzuarbeiten.

Derselbe Prompt, E-Mail-sicherer Output

Hier kommt der Teil, der die KI-Frage auflöst, statt gegen sie zu kämpfen. Postcards gibt dir den kompletten KI-Workflow, den Leute tatsächlich wollen: Beschreibe die E-Mail, und es baut eine, danach änderst du das Design, übersetzt es oder stylst es um, alles aus einem Prompt-Chat. Der Unterschied liegt darin, was herauskommt. Ein allgemeiner Chatbot reicht dir rohes Web-HTML und überlässt das Rendering dem Zufall. Postcards generiert gegen seine getesteten, Client-übergreifend geprüften Module, dieselbe Prompt-Geschwindigkeit produziert also E-Mail-sicheres, portables HTML, das den Großteil der Scorecard bereits erfüllt. Du bekommst das KI-Erlebnis, ohne dir das KI-Rendering-Problem einzuhandeln.

Der Workflow, der wirklich funktioniert

Du musst dich nicht zwischen KI und einem Builder entscheiden. Die Teams mit guten Ergebnissen nutzen beides, in der richtigen Reihenfolge.

Mit KI entwerfen

Konzept brainstormen, Texte schreiben, Varianten für die Betreffzeile erzeugen. Genau hier glänzen Modelle, und in einem Absatz Text steckt kein Rendering-Risiko. Unser Leitfaden zu ChatGPT-Prompts ist für diesen Schritt gemacht.

Die Vorlage in etwas Getestetem bauen

Pack diese Texte in einen Builder, dessen HTML bereits über Clients hinweg validiert ist, oder überführe den KI-Output, wenn du programmierst, in ein E-Mail-Framework, statt rohes Chatbot-HTML zu verschicken. Frameworks teilen einen Kniff: einen Build-Schritt, der freundliche moderne Syntax in das verschachtelte, inline gesetzte, mit Conditional Comments versehene HTML übersetzt, das E-Mail-Clients tatsächlich unterstützen:

• MJML kompiliert eine eigene Komponenten-Syntax in responsives, tabellenbasiertes HTML mit Inline-Styles
• React Email macht aus React und Tailwind Output, der in Gmail, Apple Mail, Outlook und Yahoo getestet ist
• Maizzle kompiliert Tailwind zu produktionsreifem HTML mit inline gesetzten Styles und eingebackenen mso-Conditionals

Genau diesen Übersetzungsschritt überspringt roher KI-Output.

Vor dem Versand prüfen

Schick die fertige E-Mail durch eine Rendering- und Zustellbarkeits-Prüfung, und genau dort hältst du sie gegen die Scorecard von vorhin. Nutze das Tool für die E-Mail-Vorschau, um pixelgenaue Screenshots deines HTML über 50+ echte Clients hinweg in hell und dunkel zu sehen, den Spam-Check von Unspam für Authentifizierung und Inhalt und den Inbox-Placement-Test, um zu sehen, wo sie bei Gmail, Outlook und Yahoo landet. Unsere Fünf-Minuten-Prüfung vor dem Versand geht die ganze Routine durch.

Diese Abfolge gibt dir das Tempo der KI auf den Teilen, bei denen Tempo sicher ist, und ein getestetes Fundament plus eine finale Prüfung auf den Teilen, bei denen es das nicht ist.

Brauchst du also noch einen E-Mail-Builder?

Ja, aber die nützlichere Frage ist warum, und sie sieht anders aus, je nachdem, wo in der Produktionskette du sitzt.

Wenn du E-Mail-Designer bist

Dein Thema ist Markentreue: die Schrift der Headline, die Form des Buttons, der Farbwechsel im Dark Mode, die Abstände zwischen Abschnitten. KI ist in der Briefing-Phase nützlich, um Layout-Richtungen zu erzeugen, visuelle Konzepte durchzuspielen, eine Farbwelt zu testen, bevor du dich aufs Bauen festlegst. In dem Moment aber, in dem das Design über echte Posteingänge hinweg halten muss, geht die Lücke schnell auf.

Schriften fallen in Outlook auf Times New Roman zurück, weil die Webfont-Deklaration nie so gekapselt wurde, dass die Word-Engine sie nicht sieht. Abgerundete Ecken verschwinden, weil CSS-border-radius ignoriert wird. Hintergrundbilder verschwinden, weil die Word-Engine CSS-Hintergründe ignoriert, dein dunkler Markenkopf landet also als leerer weißer Kasten. Ein sorgfältig ausgemessenes zweispaltiges Layout fällt in eine einzige gestapelte Spalte zusammen, weil die Struktur auf Flexbox statt auf verschachtelten Tabellen gebaut war. Nichts davon zeigt sich in der Browser-Vorschau, die den KI-Output fertig aussehen ließ.

Ein getesteter Builder löst das auf Modulebene. Die Komponenten wurden von vornherein so entworfen, dass sie Markenelemente durch die Clients tragen, die dir Widerstand leisten: Der Button bleibt rund, weil er VML nutzt, der Hintergrund hält, weil es einen Farb-Fallback in der Tabellenzelle gibt, das Layout stapelt auf dem Handy sauber, weil die Media Query richtig geschrieben ist. Die KI-Vision ist das Briefing. Der Builder ist die Stelle, an der aus dem Briefing etwas wird, das ein Abonnent auch wirklich sehen kann.

Wenn du E-Mail-Marketer bist

Für Marketer läuft die Frage auf Kampagnenergebnisse hinaus. Die Daten machen die Kosten von schlechtem HTML konkret: Über alle E-Mails hinweg, die in den letzten zwölf Monaten über Unspam geprüft wurden, bestehen nur 30 % die Prüfung der HTML-Best-Practices, die niedrigste Bestehensquote von allem, was wir messen. Die meisten Kampagnen gehen mit strukturellen Mängeln raus, von denen der Absender nichts wusste.

Diese Mängel zeigen sich in deinen Kennzahlen. Eine E-Mail, die kaputt rendert, senkt die Interaktion, weil sie falsch aussieht oder schwer zu lesen ist. Weniger Interaktion trainiert Posteingangsfilter darauf, künftige Sendungen Richtung Spam zu leiten. Eine Nachricht, die Gmail kappt, weil das Markup die Grenze von 102 KB gerissen hat, verbirgt den Abmeldelink, und genervte Abonnenten klicken stattdessen auf „Spam melden“. Ein Prozentpunkt Platzierung im Posteingang bei einem Versand an eine Million E-Mails ist eine echte Umsatzgröße, und sie verstärkt sich über jede weitere Sendung.

KI macht Marketer bei allem schneller, was das Markup nicht berührt: Textvarianten, Tests von Betreffzeilen, Personalisierungs-Tokens, Ideen für Abfolgen. Die Vorlage muss aber aus einem getesteten Fundament kommen, denn ein schneller Entwurf, der in einem Drittel der Posteingänge bricht, ist nicht wirklich schneller. Er ist ein schnellerer Weg zu einem Problem, das du erst siehst, wenn die Kampagne längst draußen ist.

Wenn du E-Mail-Entwickler bist

Ein Entwickler kennt die Antwort bereits, weil er <!--[if mso]>-Blöcke geschrieben und debuggt hat, warum ein Layout, das in Chrome sauber rendert, in Outlook bei 125 % Anzeigeskalierung zusammenfällt. Die Entwicklerversion der Frage ist präziser: An welcher Stelle der Pipeline gehört KI wirklich hin?

Der nützliche Rahmen ist Input gegen Output. KI gehört auf die Input-Seite: Texte für die Vorlage entwerfen, Layout-Konzepte prototypen, bevor du sie baust, die Plaintext-Version schreiben und gelegentlich einen ersten Durchgang in MJML oder React Email anlegen, den du dann aufräumst. Der Output, also das HTML, das tatsächlich an Abonnenten geht, muss aus einem Framework oder getesteten Builder kommen, der die Fallbacks für die Word-Engine, das CSS-Inlining, die MSO-Conditionals, die Grundlage für Barrierefreiheit und das Dateigrößen-Budget bereits abdeckt. Was KI produziert, ist ein Ausgangspunkt. Was rausgeht, ist das, was einen echten Client-übergreifenden Rendering-Test übersteht.

Frameworks wie MJML, React Email und Maizzle sind die Entwicklerversion derselben Antwort, die ein Builder Designern oder Marketern gibt: eine geprüfte Übersetzungsschicht zwischen einer Idee und einem Posteingang.

Aus allen drei Perspektiven dieselbe Antwort

Drei Rollen, ein Fazit. KI arbeitet auf der Sprachebene, Browser rendern auf der Web-Ebene, und E-Mail-Clients arbeiten auf einer dritten Ebene, die keine der beiden vollständig versteht. Ein eigens gebauter Builder oder ein Framework ist die Übersetzung zwischen dem KI-Entwurf und einem Posteingang, der ihn korrekt empfängt.

Nutze KI für Tempo dort, wo Tempo sicher ist: Ideen, Texte, Betreffzeilen. Nutze den Builder für das Rendering, wo es das nicht ist. Lass so oder so die Prüfung vor dem Versand laufen. Eine Browser-Vorschau sagt dir, dass eine E-Mail fertig aussieht, nie, dass sie rendert. Der Builder plus die Prüfung schließen diese Lücke.