Responsive E-Mail-Design: Ein technischer Leitfaden

Wer responsive E-Mails für Kampagnen oder Transaktionsmails baut und einen Editor oder ein Framework sucht, fährt mit MJML als Ausgangspunkt meist am sichersten. MJML ist ein Open-Source-Framework: Sie beschreiben Spalten, Abstände und Textblöcke in einer einfachen Auszeichnungssprache, und der Compiler erzeugt tabellenbasiertes HTML, das sich auf Mobilgeräten automatisch untereinander anordnet. Für das selbst gehostete Framework fällt keine Lizenzgebühr an, und auf der Preisseite ist kein Stufenmodell hinterlegt. Ob MJML für Sie die richtige Wahl ist, hängt davon ab, wer die Vorlagen später pflegt.

Dieser Leitfaden erklärt die Techniken, die in E-Mail-Clients tatsächlich funktionieren, und ordnet die gängigen HTML-Builder und Frameworks danach ein, wie sie diese Techniken für Sie übernehmen: MJML, React Email, Maizzle, Stripo, BEE und Unlayer. Email on Acid behandeln wir separat, weil es Vorlagen prüft, aber nicht baut. Welche Versandplattform das fertige HTML anschließend ausliefert, ist eine eigene Entscheidung und wird hier nur am Rand behandelt.

Warum responsive E-Mail eine eigene Disziplin ist

Im Browser sind Flexbox, Grid und moderne Media Queries selbstverständlich. In E-Mails sind sie es nicht. E-Mail-Clients sind keine vollwertigen Browser, sondern Darstellungsmaschinen mit eigenen Regeln, und jede Maschine hat ihre Lücken. Für die Praxis bedeutet das vor allem drei Dinge: Layouts werden mit Tabellen gebaut, Stile werden möglichst inline gesetzt, und Anpassungen für kleine Bildschirme sind eine Zugabe, auf die sich das Design nicht verlassen darf.

Die wichtigsten Unterschiede im Alltag sind diese:

• Apple Mail auf iOS wertet Media Queries aus und verhält sich weitgehend wie ein kleiner Browser.
• Gmail-App unterstützt Media Queries ebenfalls, reagiert aber empfindlich auf Stile im Kopfbereich und verlangt deshalb Inline-Styles für alles Wichtige.
• Outlook für Windows rendert mit der Word-Engine. Viele Media Queries werden ignoriert, und Layouts, die sich auf div-Elemente verlassen, brechen.
• Samsung Mail ist im Allgemeinen recht verlässlich, sollte aber trotzdem auf echten Geräten geprüft werden.

Daraus folgt eine einfache Regel: Das Layout muss ohne Media Queries funktionieren. Die Queries verbessern die Darstellung dort, wo sie wirken, und dürfen nie die einzige Grundlage sein.

Vergleich der Werkzeuge auf einen Blick

Die folgende Tabelle zeigt, welches Werkzeug für welche Rolle gedacht ist, was es kostet und wo die Grenzen liegen. Die Preisangaben stammen von den Preisseiten der Anbieter; wo dort kein Preis steht, ist das vermerkt.

Fluide Tabellen als Fundament

Beginnen Sie mit einer Tabelle, die auf dem Desktop 600 Pixel breit ist und sich auf kleinen Bildschirmen verkleinern darf. Die Breite wird über width="100%" und max-width festgelegt. Dieses Muster funktioniert in fast allen Clients, auch dort, wo Media Queries ausfallen:

<table role="presentation" width="100%" style="max-width: 600px;">
  <tr>
    <td style="padding: 20px;">
      Inhalt füllt die verfügbare Breite
    </td>
  </tr>
</table>

Auf dem Desktop bleibt die Nachricht bei 600 Pixel stehen und wird zentriert. Auf dem Smartphone schrumpft sie auf die Bildschirmbreite. Dafür brauchen Sie keine Media Queries. Die Abstände im Inneren nutzen Padding in Pixeln, nicht in Prozent, weil Prozentangaben für Innenabstände in Outlook unzuverlässig sind.

Verschachteln Sie Tabellen sauber: jede Ebene bekommt ihr eigenes role="presentation", und es gibt keine leeren Zellen als Abstandshalter. Alt-Texte sind Pflicht, sobald Bilder ausgeschaltet sind, und die Reihenfolge der Inhalte muss auch ohne Layout Sinn ergeben.

Media Queries als Verbesserung

Media Queries erlauben es, das Layout in den Clients zu verfeinern, die sie unterstützen. Ein typischer Satz für kleine Bildschirme sieht so aus:

<style>
  @media screen and (max-width: 600px) {
    .column {
      width: 100% !important;
      display: block !important;
    }
    .stack-on-mobile {
      display: block !important;
      width: 100% !important;
    }
    .hide-on-mobile {
      display: none !important;
    }
    .mobile-padding {
      padding: 10px !important;
    }
  }
</style>

Die wichtigsten Anpassungen sind:

• Spalten stapeln: Nebeneinanderliegende Spalten werden auf schmalen Bildschirmen zu untereinanderliegenden Blöcken.
• Padding reduzieren: Auf dem Smartphone bleibt weniger Rand, damit mehr Text in die Zeile passt.
• Sekundäres ausblenden: Zusatzinhalte wie lange Fußzeilen-Blöcke dürfen auf dem Handy fehlen, nicht aber der Kern der Nachricht.
• Bilder skalieren: Bilder werden auf volle Breite gesetzt, ohne das Seitenverhältnis zu verlieren.

Die Ausrufezeichen bei !important sind notwendig, weil Inline-Styles eine höhere Spezifität haben und Media Queries sonst ins Leere laufen. Achten Sie darauf, dass die Queries nur Verbesserungen enthalten. Wenn Ihr Layout ohne sie unbrauchbar ist, liegt der Fehler in der Grundstruktur, nicht im CSS.

Die Hybrid-Methode für Outlook

Outlook für Windows ignoriert Media Queries und kann flexible div-Layouts nicht zuverlässig darstellen. Die Hybrid-Methode löst dieses Problem mit bedingten Kommentaren: Outlook liest den Tabellenteil, alle anderen Clients lesen die div-Elemente, die sich dank display: inline-block und max-width bei schmalen Breiten untereinander anordnen.

<!--[if mso]>
<table role="presentation" width="600">
<tr>
<td width="300">
<![endif]-->

<div style="display: inline-block; width: 100%; max-width: 300px;">
  Inhalt Spalte 1
</div>

<!--[if mso]>
</td>
<td width="300">
<![endif]-->

<div style="display: inline-block; width: 100%; max-width: 300px;">
  Inhalt Spalte 2
</div>

<!--[if mso]>
</td>
</tr>
</table>
<![endif]-->

Das Ergebnis sind nebeneinanderliegende Spalten in Outlook und gestapelte Spalten überall sonst, ohne eine einzige Media Query. Der Preis dafür ist Handarbeit: Sie pflegen den bedingten Teil selbst, und jede Änderung an der Spaltenzahl betrifft beide Varianten. Genau an dieser Stelle nehmen Ihnen Frameworks wie MJML einen großen Teil der Arbeit ab.

Responsive Bilder und Buttons

Bilder müssen sich an ihren Container anpassen. Das Attribut width legt die vorgesehene Größe fest, max-width: 100% verhindert Überlauf, und height: auto erhält das Seitenverhältnis:

<img src="bild.jpg"
     width="600"
     style="display: block; max-width: 100%; height: auto;"
     alt="Beschreibung des Bildes">

Setzen Sie display: block, damit in Outlook und Gmail keine Leerzeile unter dem Bild entsteht. Wichtige Texte sollten nie allein im Bild stehen, weil viele Clients Bilder zunächst blockieren.

Buttons sind die zweite Stelle, an der responsive Arbeit sichtbar wird. Mobile Leser tippen, sie klicken nicht. Ein Button, der als Tabellenzelle mit Hintergrundfarbe und einem Link im Inneren gebaut ist, bleibt auch in Outlook bedienbar:

<table role="presentation">
  <tr>
    <td style="background-color: #007bff; border-radius: 4px; padding: 12px 24px;">
      <a href="https://example.com"
         style="color: #ffffff; text-decoration: none; font-weight: bold; display: block;">
        Jetzt öffnen
      </a>
    </td>
  </tr>
</table>

Als Richtwert für die Trefferfläche gilt die Apple-Empfehlung von 44 × 44 Punkten. Mehr Innenabstand ist hier fast immer besser als weniger. Ein Button, der auf dem Smartphone nur als dünne Textzeile erscheint, wird häufig übersehen.

Die Werkzeuge im Einzelnen

Die Auswahl hängt davon ab, wer die Vorlagen baut. Entwickler, die Code versionieren, arbeiten anders als Marketingteams, die Blöcke ziehen. Die folgenden Abschnitte beschreiben, wofür jedes Werkzeug taugt, wo es an Grenzen stößt und was es kostet.

MJML

Was gut funktioniert: MJML beschreibt eine Nachricht mit wenigen Bausteinen wie mj-section, mj-column und mj-text. Der Compiler erzeugt daraus tabellenbasiertes HTML mit den Techniken aus diesem Leitfaden, inklusive der bedingten Teile für Outlook. Spalten stapeln sich auf Mobilgeräten ohne eigene Media Queries von Ihnen. Die Vorlagen liegen als Text im Repository, lassen sich prüfen, vergleichen und zurückrollen.

<mj-section>
  <mj-column>
    <mj-text>Spalte 1</mj-text>
  </mj-column>
  <mj-column>
    <mj-text>Spalte 2</mj-text>
  </mj-column>
</mj-section>

Wo es hakt: MJML ist kein Editor. Redakteure ohne Technikkenntnisse brauchen eine Oberfläche davor oder eine Übergabe an Entwickler. Außerdem ist der Compiler nur der halbe Weg: Die erzeugte HTML-Datei muss noch in den Versandweg, und Sie müssen festlegen, wie Bilder und Links dort landen.

Preis: Das Framework wird selbst gehostet. Auf der Preisseite ist kein Stufenmodell hinterlegt, daher entstehen keine festen monatlichen Gebühren für die Nutzung des Frameworks selbst. Ihre Kosten liegen in Zeit und Infrastruktur. Details und Hinweise finden Sie auf der Preisseite von MJML.

React Email

Was gut funktioniert: Wenn Ihr Team ohnehin mit React arbeitet, lassen sich Nachrichten als Komponenten schreiben, wiederverwenden und mit Tests absichern. Eine Komponente für Kopfzeile, Produktkarte oder Fußzeile wird einmal gebaut und in vielen Vorlagen eingesetzt. Das ist für Produktteams mit vielen transaktionalen Mails besonders praktisch, etwa für Bestätigungen, Passwort-Zurücksetzungen oder Rechnungen.

Wo es hakt: Die Vorlagen sind Code, und Redakteure ohne React-Kenntnisse können sie nicht ohne Weiteres anpassen. Die Tabellenstruktur, die in E-Mail-Clients nötig ist, müssen Sie beim Schreiben der Komponenten im Blick behalten, sonst entsteht sauberes React, das in Outlook trotzdem bricht.

Preis: Auf Anfrage. Für die aktuellen Konditionen prüfen Sie bitte die Angaben des Anbieters.

Maizzle

Was gut funktioniert: Maizzle richtet sich an Entwickler, die mit Utility-Klassen arbeiten. Die Styles werden beim Bauen in Inline-Styles umgewandelt, und die Vorlagen bleiben übersichtlich, weil Layout und Gestaltung am Element selbst stehen. Für Teams, die schon Tailwind verwenden, ist der Einstieg kurz.

Wo es hakt: Es gibt einen Build-Schritt, und ohne ihn sehen Sie nur Rohvorlagen. Redakteure brauchen wie bei MJML eine eigene Oberfläche. Außerdem müssen Sie die Ergebnisse für Outlook selbst kontrollieren, weil die Utility-Klassen nicht automatisch jede Sonderregel mitbringen.

Preis: Auf Anfrage.

Stripo

Was gut funktioniert: Stripo ist ein visueller Editor. Marketingteams ziehen Blöcke für Text, Bild, Button oder Produktraster per Drag-and-drop in die Vorlage und sehen die Änderungen direkt. Für wiederkehrende Kampagnen mit festen Bausteinen ist das ein effizienter Weg, besonders wenn Redaktion und Technik getrennt arbeiten.

Wo es hakt: Exportierter Code ist häufig umfangreich. Er muss vor dem Versand in den Ziel-Clients geprüft werden, besonders in Outlook und bei ausgeschalteten Bildern. Wer Vorlagen versioniert oder mit Code-Reviews arbeiten möchte, tut sich mit einem visuellen Editor schwerer als mit Textdateien.

Preis: Auf Anfrage.

BEE

Was gut funktioniert: BEE ist ebenfalls ein Editor mit Modulen, die Redakteure frei zusammenstellen. Es eignet sich, wenn Ihre Teams eine klare Bausteinbibliothek brauchen, die sich an einer Marke orientiert. Die Module lassen sich so vorbereiten, dass Redakteure nur Inhalte ersetzen und nicht am Layout drehen.

Wo es hakt: Ein eigenes Designsystem braucht sorgfältige Einrichtung. Wer die Module nicht vorher für responsive Darstellung und Barrierefreiheit festlegt, erbt die Lücken in jeder Kampagne. Prüfen Sie außerdem, wie Sie die Vorlagen exportieren und in Ihren Versandweg übergeben.

Preis: Auf Anfrage.

Unlayer

Was gut funktioniert: Unlayer ist für Produkte gedacht, die einen E-Mail-Editor direkt in die eigene Anwendung einbetten. Kunden können dann ihre Nachrichten selbst gestalten, ohne Ihr Team einzubeziehen. Das passt gut zu Plattformen, auf denen Nutzer eigene Newsletter oder Benachrichtigungen erstellen.

Wo es hakt: Sie betreiben die Integration, die Verwaltung der Vorlagen und die Rechteverwaltung selbst. Der Editor ist nur so gut wie die Bausteine, die Sie freigeben, und die Ausgabe muss in Ihrem Versandweg wie jede andere Nachricht getestet werden.

Preis: Auf Anfrage.

Email on Acid: Prüfung statt Bau

Was gut funktioniert: Email on Acid zeigt Ihre fertige Nachricht in einer großen Zahl von Clients und Geräten. Die höheren Stufen enthalten Barrierefreiheitsprüfungen und eine Analyse des HTML. Dieses Werkzeug ersetzt keinen Editor, aber es ist der schnellste Weg, Fehler in Outlook, Gmail oder Apple Mail zu finden, bevor Empfänger sie sehen. Das passt zu jedem der oben genannten Bauwerkzeuge.

Wo es hakt: Die Vorschauen sind ein monatliches Kontingent. Wer viele Varianten pro Woche prüft, muss das Kontingent einplanen, und Vorschauen bestätigen nicht, wie sich eine Nachricht im echten Postfach mit echten Bildern verhält.

Preis: Die Basic-Stufe kostet 99 US$ pro Monat und umfasst 1.000 Vorschauen pro Monat, über 100 Clients und Geräte sowie API-Zugang. Die Premium-Stufe kostet 199 US$ pro Monat und umfasst 2.000 Vorschauen pro Monat, Barrierefreiheitsprüfungen und HTML-Analyse. Details finden Sie auf der Preisseite von Email on Acid.

Was Vorschauen kosten, wenn das Prüfvolumen wächst

Die Kosten für Prüfungen hängen vom Volumen ab, nicht von Ihrer Kontaktzahl. Die folgende Tabelle rechnet mit den veröffentlichten Stufen von Email on Acid. Für Werkzeuge ohne veröffentlichten Stufenpreis steht bewusst keine Zahl.

Die Zahlen oben sind Monatspreise ohne Umsatzsteuer und ohne Zusatzkosten für Ihre Infrastruktur. Wenn ein Vorschau-Kontingent nicht reicht, ist der Sprung von Basic zu Premium der nächste Kostenschritt: Sie zahlen dann 100 US$ mehr pro Monat für doppeltes Kontingent und die Barrierefreiheitsprüfung. Rechnen Sie den Sprung gegen den Nutzen, bevor Sie buchen.

Wie Sie auswählen

Die passende Kombination hängt weniger vom Feature-Umfang ab als von drei Fragen: Wer baut die Vorlagen, wer pflegt sie, und wie oft ändert sich das Design? Die Entscheidungstabelle hilft beim Sortieren.

Ein Hinweis zur Entscheidung: Die meisten Probleme entstehen nicht beim Bauen, sondern bei der Übergabe. Wenn Ihr Team Vorlagen in einem Werkzeug erstellt, aber in einem anderen Versand, dann liegt der Fehler oft in der Konvertierung. Prüfen Sie deshalb immer die fertige Ausgabe, nicht nur die Vorlage im Editor.

Einrichtung und Arbeitsablauf

Ein Vorgehen, das für fast alle Werkzeuge funktioniert, hat fünf Schritte. Sie lassen sich in einer Checkliste abarbeiten, bevor die erste Kampagne den Versand verlässt.

Für Teams, die bereits eine Vorlagenbibliothek haben, lohnt es sich, nicht alles auf einmal umzubauen. Beginnen Sie mit der Vorlage, die am häufigsten verschickt wird, etwa der Bestätigungsmail oder dem wöchentlichen Newsletter. Wenn sie in allen Clients funktioniert, übertragen Sie die Bausteine auf die übrigen Nachrichten.

Ein Vorgehen für die ersten vier Wochen

Wer ein neues Werkzeug einführen möchte, sollte es an einer echten Nachricht prüfen, nicht an einer Beispielvorlage. Eine Woche reicht für die Entscheidung, wenn der Ablauf klar ist. Nehmen Sie eine Nachricht mit typischen Anforderungen: dynamische Inhalte, wiederverwendete Module und klare Schaltflächen. Bauen Sie genau diese Nachricht mit jedem Kandidaten nach und notieren Sie die Schritte, die Mühe machen. Die Notizen sind wichtiger als Funktionslisten.

Begrenzen Sie die Auswahl auf höchstens drei Werkzeuge. Jeder weitere Kandidat vervielfacht den Aufwand für Prüfung und Dokumentation, ohne dass die Entscheidung klarer wird. Lassen Sie die Preise, die auf den Anbieterseiten stehen, in die Entscheidung einfließen, und fragen Sie bei Werkzeugen ohne veröffentlichte Preise schriftlich nach dem Angebot.

Versand und Gestaltung trennen

Eine fertige HTML-Datei ist nur ein Teil der Kette. Die Versandplattform entscheidet, wie Bilder gehostet werden, wie Links nachverfolgt werden und ob ein Abmeldelink automatisch eingefügt wird. Diese Entscheidungen sollten Sie treffen, bevor Sie eine Vorlage als fertig bezeichnen, denn sie verändern das HTML an mehreren Stellen. Prüfen Sie, ob Ihre Plattform Inline-Styles und bedingte Kommentare unverändert übernimmt. Viele Probleme mit Outlook entstehen genau dort, wo ein Versandwerkzeug das HTML umschreibt.

Halten Sie deshalb eine Referenz-Testnachricht bereit, die Sie nach jeder Änderung an der Vorlage oder am Versandweg verschicken. Ein Blick auf die eigene Testnachricht in drei Clients zeigt schneller als jede Dokumentation, ob das Ergebnis noch stimmt.

Barrierefreiheit gehört zum Responsive-Design

Ein Layout, das auf dem Smartphone funktioniert, aber für Leser mit Sehbehinderung nicht verständlich ist, ist nicht fertig. Achten Sie auf eine logische Reihenfolge der Inhalte, aussagekräftige Alt-Texte, ausreichende Kontraste und Linktexte, die auch ohne Kontext verständlich sind. Ein Link mit dem Text »hier klicken« hilft niemandem, der nur die Linkliste eines Screenreaders hört. Die höheren Stufen mancher Prüfwerkzeuge enthalten Barrierefreiheitstests, die diese Punkte automatisch erfassen, ersetzen aber keine manuelle Durchsicht.

Das Wichtigste in Kürze

Responsive E-Mail ist machbar, verlangt aber, die Grenzen der Clients zu kennen. Beginnen Sie mit einem fluiden Tabellenlayout, verbessern Sie es mit Media Queries und sorgen Sie mit der Hybrid-Methode dafür, dass Outlook nebeneinanderliegende Spalten zeigt. Testen Sie in den Clients, die Ihre Leser tatsächlich nutzen.

Für die Auswahl des Werkzeugs gilt: MJML ist der nüchterne Ausgangspunkt für Entwickler, die Vorlagen als Code pflegen. React Email passt zu React-Teams, Maizzle zu Tailwind-Teams, Stripo und BEE zu Marketingteams mit Blöcken, Unlayer zu Produkten mit eingebettetem Editor. Email on Acid ergänzt jedes dieser Werkzeuge als Prüfung vor dem Versand.