1) Der wichtigste Grund: E-Mail-Clients sind keine Browser

HTML in E-Mails ist „Sandbox-HTML“. Viele Clients erlauben nur einen stark eingeschränkten Satz an Tags und CSS. JavaScript ist praktisch immer blockiert. Moderne Layout-Techniken wie Flexbox, Grid, externe Stylesheets oder komplexe Selektoren funktionieren je nach Client nur teilweise oder gar nicht.

Besonders bekannt ist Outlook für Windows, das bei vielen Versionen eine Word-basierte Rendering-Engine nutzt. Das führt dazu, dass HTML/CSS nicht wie im Browser interpretiert wird. Was im Web sauber aussieht, kann in Outlook plötzlich zu verschobenen Spalten, falschen Zeilenhöhen oder „unsichtbaren“ Buttons führen.

2) Buttons fehlen: Die häufigsten Ursachen (und was du dagegen tun kannst)

2.1 Der Button ist eigentlich da – aber als Bild blockiert

Viele Templates „designen“ Buttons als Bild (PNG/JPG). Wenn der Client Bilder standardmäßig blockiert, wirkt es, als würde der Button fehlen. Das betrifft besonders neue Absender, unbekannte Domains oder streng konfigurierte Business-Postfächer.

• Lösung: Buttons als echtes HTML bauen (Tabelle + Link + Background-Farbe).
• Fallback: Klarer Textlink direkt unter dem Button („Falls der Button nicht funktioniert…“).
• Alt-Text: Sinnvoller Alt-Text auf Bildern hilft, wenn Bilder blockiert sind.

2.2 CSS wird entfernt oder ignoriert (besonders bei externem CSS)

Externe Stylesheets (<link rel="stylesheet">) werden in vielen Clients ignoriert. Auch <style>-Blöcke im Head können je nach Client entfernt oder teilweise ignoriert werden. Ergebnis: Der Button verliert Padding, Hintergrundfarbe oder Display-Regeln – und schrumpft zu einem nackten Link, der optisch „verschwindet“.

• Lösung: Kritische Styles inline setzen (style="..." direkt am Element).
• Praxis-Standard: Buttons als Tabellenkonstruktion mit inline Styles.
• Vermeiden: Abhängigkeit von komplexen Klassen-Kaskaden.

2.3 Sicherheitsfilter entfernen Styles/Attribute (Sanitizing)

Manche Systeme (Gateways, Mailing-Tools, Corporate Security) „säubern“ HTML, um Risiken zu reduzieren. Dabei können bestimmte Attribute oder CSS-Eigenschaften entfernt werden – z. B. position, background-image oder sogar ganze Style-Blöcke.

• Lösung: Minimalistisches, kompatibles HTML verwenden (Tabellenlayout, Inline-CSS).
• Check: Die tatsächlich zugestellte E-Mail-Quelle prüfen (nicht nur das Template im Editor).

2.4 „Bulletproof Button“ fehlt: Outlook braucht oft Spezialbehandlung

Ein klassischer HTML-Button mit border-radius und display:inline-block funktioniert in vielen Clients, aber Outlook kann dabei schwächeln. In der Praxis setzt man deshalb oft sogenannte Bulletproof Buttons ein: Tabellenbasierte Buttons, optional mit VML-Fallback für Outlook, damit Hintergrundfarben und Maße sicher bleiben.

• Lösung: Tabellenbutton als Basis, optional VML-Fallback für Outlook.
• Bonus: Keine Abhängigkeit von background-image für den Button-Hintergrund.

2.5 Dark Mode „dreht“ Farben – Button wirkt unsichtbar

Dark Mode ist einer der häufigsten Gründe für „fehlende Buttons“: Manche Clients invertieren Farben automatisch oder passen Kontraste an. Ein Button, der im Hellmodus gut aussieht, kann im Dark Mode plötzlich nahezu die gleiche Farbe wie der Hintergrund bekommen. Ergebnis: Der Button ist da – aber nicht mehr erkennbar.

• Lösung: Kontraste robust planen (nicht nur „schön“, sondern „lesbar in beiden Modi“).
• Fix: Textfarbe und Hintergrundfarbe explizit inline setzen.
• Fallback: Zusätzlich sichtbarer Textlink unter dem Button.

2.6 Der Link wird von Security/Tracking-Schutz umgeschrieben

Manche Empfängerumgebungen ersetzen Links (Safe Links, Link-Scanning). In seltenen Fällen bricht dabei das Markup, wenn Links nicht sauber geschlossen sind oder Sonderzeichen falsch encodiert wurden. Auch Tracking-Parameter können unerwartete Umbrüche verursachen.

• Lösung: Saubere HTML-Struktur, korrekte Escapes, URLs nicht „zu kreativ“ formatieren.
• Tipp: Den finalen Link aus dem empfangenen Quelltext kopieren und testen.

3) Layout kaputt: Die häufigsten Formatting-Probleme

3.1 Kein Tabellenlayout – oder Tabellen sind fehlerhaft verschachtelt

E-Mail-Layouts werden seit Jahren stabil über Tabellen gebaut, weil das in fast allen Clients am zuverlässigsten ist. Wenn du stattdessen Div-basierte Layouts nutzt, kann es je nach Client zu verschobenen Spalten, kaputten Abständen oder Zeilenumbrüchen kommen. Auch kleine Fehler wie fehlende <td>-Schließtags sind Gift.

• Lösung: Layout-Grundgerüst als Tabellen (Container-Tabelle, Zeilen, Spalten).
• Check: Validität: sind alle Tabellenzellen korrekt geschlossen?
• Praxis: Maximalbreite (z. B. 600px) als bewährter Standard.

3.2 Margin wird ignoriert – besonders bei Outlook

Viele Clients (allen voran Outlook) ignorieren margin an bestimmten Elementen oder interpretieren es anders. Was im Browser sauber Abstand erzeugt, klebt in Outlook plötzlich zusammen.

• Lösung: Abstände lieber über Tabellenzellen-Padding oder Spacer-Tabellen.
• Alternative: padding statt margin, wo möglich.

3.3 Webfonts werden nicht geladen – Typografie springt

Viele E-Mail-Clients unterstützen keine externen Webfonts oder blockieren sie. Dann fällt der Text auf Standardschriften zurück, was Zeilenumbrüche, Buttonbreiten oder Layout-Höhen verändert.

• Lösung: Solide Font-Stacks definieren (z. B. Systemfonts als Fallback).
• Plan: Layout so bauen, dass ein Fontwechsel nicht alles sprengt.

3.4 Bilder skalieren falsch oder brechen Spalten

Ein häufiges Problem: Bilder ohne feste Breite oder ohne display:block erzeugen unerwünschte Abstände, kleine „Gaps“ unter Bildern oder sprengen Container. Auf mobilen Clients kommt hinzu, dass manche automatisch skalieren, wenn keine width-Angaben existieren.

• Lösung: Bilder mit klarer Breite, display:block, und responsive Regeln via Inline/Attribute.
• Tipp: Wichtige Grafiken nie als einziges Trägermedium für Text nutzen.

3.5 Mobile Auto-Zoom & Text-Resizing

Einige mobile Clients passen Schriftgrößen automatisch an („Text size adjust“). Dadurch ändern sich Zeilenhöhen, Buttons werden größer/kleiner, Abstände kippen. Das wirkt wie „kaputtes Layout“, ist aber eher eine automatische Lesbarkeitsfunktion.

• Lösung: Schriftgrößen konsistent und nicht zu klein wählen.
• Robustheit: Genügend „Luft“ im Layout einplanen, damit Reflow nicht zerstört.

4) Der stille Killer: Copy/Paste aus Web-Editoren

Viele Rendering-Bugs entstehen, weil Inhalte aus Website-Buildern, Word, Google Docs oder visuellen Editoren kopiert werden. Das bringt versteckte Styles, unnötige Wrapper, nicht unterstützte CSS-Eigenschaften und teils kaputte HTML-Strukturen mit.

• Lösung: E-Mail-Markup bewusst als E-Mail-Markup erstellen (nicht als Webpage kopieren).
• Sauberkeit: Unnötige Tags entfernen, Inline-CSS gezielt setzen.
• Test: Immer in mehreren Clients prüfen, nicht nur im Editor-Preview.

5) Warum „nur bei manchen Empfängern“? Die Client-Matrix

Wenn ein Teil der Empfänger alles korrekt sieht und ein anderer Teil nicht, ist das ein starker Hinweis: Das Problem liegt am Client oder an Security/Policies in einer bestimmten Umgebung. Typische Unterschiede:

• Gmail Web vs. Gmail App: Unterschiedliche CSS-Unterstützung.
• Outlook Windows vs. Outlook Web: Andere Rendering-Engines.
• iOS Mail (WebKit) ist oft moderner als viele Desktop-Clients.
• Firmenpostfächer mit zusätzlichen Gateways können HTML stärker „säubern“.

Deshalb ist „sieht bei mir gut aus“ in E-Mail-Design leider kein Beweis. Entscheidend ist: Wie rendert es in den typischen Ziel-Clients deiner Empfängerbasis?

6) Praktische Checkliste: So findest du die Ursache schnell

1. Quelltext der empfangenen Mail prüfen: Wurde HTML/CSS unterwegs verändert oder entfernt?
2. Bilder-Blocking testen: Ist der Button als Bild umgesetzt? Gibt es Alt-Text oder Textlink-Fallback?
3. Inline-CSS: Sind kritische Styles direkt am Element gesetzt?
4. Outlook-Test: Bricht es nur dort? Dann Tabellen + ggf. VML für Buttons einsetzen.
5. Dark Mode: Sind Kontraste robust oder wird der Button „unsichtbar“?
6. Links: Werden sie umgeschrieben? Sind Sonderzeichen korrekt encodiert?
7. Tabellenvalidität: Sind alle <table>, <tr>, <td> sauber geschlossen?

Diese Reihenfolge spart Zeit: In der Praxis sind es meistens Bild-Blocking, fehlendes Inline-CSS, Outlook-Kompatibilität oder Dark-Mode-Kontrastprobleme.

7) Best Practices: So baust du E-Mails, die zuverlässig rendern

• Tabellenlayout als Standard: Container, Spalten, Abstände – alles stabil über Tabellen.
• Inline-CSS für kritische Styles: Buttons, Typografie, Abstände, Farben.
• Bulletproof Buttons: Keine rein div-basierten Buttons als einzige CTA-Quelle.
• Text-Fallbacks: Unter jedem Hauptbutton ein klarer Link („Wenn der Button nicht funktioniert…“).
• Kontrast & Dark Mode: Farben so wählen, dass sie auch bei automatischen Anpassungen lesbar bleiben.
• Wichtige Infos nie nur als Bild: Überschriften, Codes, Handlungsanweisungen als Text.
• Saubere Struktur: Keine verschachtelten, unnötigen Wrapper aus Web-Editoren.

8) Fazit: „Missing Buttons“ sind selten mysteriös – meist sind es 4–5 Klassiker

Fehlende Buttons oder kaputtes Formatting wirken zunächst wie Chaos, folgen aber fast immer wiederkehrenden Regeln: Bilder werden blockiert, CSS wird entfernt, Outlook interpretiert anders, Dark Mode kippt Kontraste oder Security-Systeme verändern Links und Markup. Wer E-Mail-HTML wie Web-HTML behandelt, produziert zwangsläufig Überraschungen.

Wenn du dagegen auf ein bewährtes Fundament setzt – Tabellenlayout, Inline-CSS, bulletproof Buttons und klare Fallbacks – bekommst du Templates, die in den wichtigsten Clients stabil bleiben und vor allem: bei denen dein CTA nicht „verschwindet“, wenn es drauf ankommt.