---
url: "/de/emailify/faq/troubleshooting.md"
description: "Anleitung zur Fehlerbehebung bei Design, Export und clientspezifischen Problemen in Emailify."
---

# Fehlerbehebung für Emailify

> Anleitung zur Fehlerbehebung bei Design, Export und clientspezifischen Problemen in Emailify.

## Figma

### E-Mail-Designs in Figma, die außerhalb von Emailify erstellt wurden, werden nicht unterstützt

Erstelle das E-Mail-Layout mit den Design-Werkzeugen von Emailify, bevor du produktionsreifes HTML exportierst. Diese Werkzeuge fügen die Ebenen Row, Column, Button und andere strukturierte Ebenen hinzu, die Emailify zum Erzeugen des HTML braucht. Inhalte und Stile kannst du nach dem Hinzufügen anpassen.

Ebenen oder Frames, die vorher ohne das Emailify-Plugin in Figma gestaltet wurden, werden beim Hinzufügen als statisches Bild gerendert statt als Rich Text bzw. HTML-Inhalt.

### Bildformat überschreiben

Emailify erkennt automatisch, ob eine Ebene vollständig transparente Bereiche enthält, und legt dann **PNG** als Standard-Exportformat fest, andernfalls **JPG**. Du kannst das überschreiben und das Exportformat jeder Ebene auf **JPG** oder **PNG** setzen, indem du eine eigene Exporteinstellung hinzufügst.

### Einfrieren bei aktivierten Figma-Einstellungen „Scroll Wheel“ oder „Drag to Pan“

Gelegentlich tritt ein Problem auf, bei dem das Plugin oder der Canvas seltsam einfriert, wenn diese Einstellungen (siehe Screenshot unten) aktiviert sind.

Wenn das in deiner Figma-Datei passiert, deaktiviere diese Einstellungen in Figma: Öffne das **Main Figma Menu**, geh zu **Preferences** und _deaktiviere_ dort **Use scroll wheel zoom** und **Right-click and drag to pan**.

![Figma-Einstellungen zum Zoomen mit dem Mausrad und Verschieben per Rechtsklick und Ziehen](/assets/images/emailify/scroll-pan.png)

### Links in normalen Absätzen und Inhalten einer Figma-Textebene hinzufügen

Markier in der Figma-Textebene den Text, den du verlinken möchtest, und klick dann in der Kopfzeilen-Werkzeugleiste von Figma auf das [native „Link“-Symbol von Figma](https://help.figma.com/hc/en-us/articles/360045942953-Add-links-to-text). Dort kannst du eine URL einfügen, die Emailify automatisch rendert.

**Nutze das nur für Inhalts-Textebenen (nicht für Buttons oder Navigationslinks)**. Das funktioniert nur bei normalen Inhalts-Textebenen. Wenn du einen Link für eine von Emailify erzeugte Button-, Social-Icon- oder Navigationslink-Ebene festlegen musst, klick auf diese Figma-Ebene, dann im Kopfbereich des Emailify-Plugins auf den Button **Settings** und füg deine URL in das Link-Feld ein.

### Beschriftungen von Buttons oder Links sind in Figma sichtbar, fehlen aber in Vorschau oder Export

Wenn ein Button leer ist oder ein Navigationslink fehlt, obwohl sein Text in Figma sichtbar ist, kann ein Exportproblem mit gemischten Schriftdaten die Ursache sein, auch bei variablen Schriften. Eine korrekte Link-URL garantiert nicht, dass auch die Beschriftung exportiert wurde.

Lass die Beschriftungen als bearbeitbaren Text in ihren ursprünglichen Emailify-Komponenten für Buttons oder Navigation. Schließ Emailify, öffne es wieder, aktualisiere die Vorschau und exportiere erneut. Prüf das heruntergeladene HTML, bevor du es auf deine E-Mail-Plattform hochlädst.

Wenn die Beschriftungen weiterhin fehlen, [wende dich an den Support](https://www.hypermatic.com/contact/) und schick den betroffenen E-Mail-Frame aus Figma sowie das exportierte HTML oder ZIP mit, damit wir die Textebenen untersuchen und das Problem nachstellen können.

### Hochgestellten oder tiefgestellten Text hinzufügen

Du kannst [deinen Figma-Textebenen hochgestellten und tiefgestellten Text hinzufügen](https://docs.hypermatic.com/emailify/design/superscript-and-subscript). Beim HTML-Export aus dem Plugin wird er automatisch als hochgestellt (zum Beispiel `sup`) oder tiefgestellt (zum Beispiel `sub`) gerendert.

### Überschrift-Tags (zum Beispiel h1, h2, h3) im HTML-Text verwenden

 Bei Bedarf kannst du das Standard-Absatz-Tag (`p`) durch ein beliebiges Überschrift-Tag (z. B. `h1`, `h2`) ersetzen. Du kannst [den Inhalt deiner Figma-Textebene mit dem gewünschten Überschrift-Tag umschließen](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/Heading_Elements). Beim HTML-Export über das Emailify-Plugin wird das Tag dann automatisch geändert.

### Leere Dateiendungen in der Figma-Desktop-App unter Windows

Es gibt ein bekanntes Problem mit der Figma-Desktop-App (nur unter Windows), das auch bei normalen Datei-Exporten aus Figma auftritt. Beim Speichern deiner Datei siehst du möglicherweise die Bezeichnung „all files“. Wenn du das ignorierst und auf „Save“ klickst, sollte die Datei trotzdem mit der richtigen Endung gespeichert werden und sich nach dem Herunterladen wie erwartet öffnen lassen. Wird die Datei trotzdem ohne Endung gespeichert, kannst du sie umbenennen und die richtige Endung von Hand an den Dateinamen anhängen.

### Designs optimieren, um das HTML beim Export zu verkleinern

Die Anzahl der Row-Komponenten hat den größten Einfluss auf die Größe des exportierten HTML, weil jede Row einen weiteren Satz Tabellenelemente erzeugt. Verwende eine Row wieder, wenn ihr Inhalt in dieselbe Struktur passt.

Zum Beispiel können sich Überschrift, Unterüberschrift, Fließtext und Button eine Column in einer Row teilen. Dafür brauchst du keine vier separaten Row-Ebenen.

### Optionen im Emailify-Einstellungspanel erscheinen nicht beim Klick auf eine Emailify-Ebene in Figma

Wenn du in deinem Figma-Design auf eine Emailify-Ebene klickst und beim Klick auf den Button **Settings** im Kopfbereich des Plugins keine Einstellungen erscheinen, ist dein Emailify-Hauptframe möglicherweise in andere Frames, Gruppen o. Ä. verschachtelt. Verschieb deinen Emailify-Frame in diesem Fall aus allen verschachtelten Frames bzw. Ebenen heraus zurück auf die Ebene der „Seite“, sodass er in keiner anderen Ebene mehr steckt.

### UTM-Parameter werden beim Versand einer HTML-E-Mail entfernt

Es gibt [ein paar Gründe](https://www.netnatives.com/blog/utm-tracking), warum UTM-Parameter im Query-String beim Versand deiner HTML-E-Mails entfernt werden können: Seit etwa einem Jahr entfernen immer mehr Browser und Geräte diese (aus Datenschutzgründen) automatisch. Wenn die Query-Strings funktionieren, solange du die Links aus dem Vorschaufenster von Emailify öffnest, aber nicht mehr, nachdem die E-Mail von deiner E-Mail-Marketing-Plattform versendet wurde, wird beim Versand wahrscheinlich zusätzlich eine Link-Weiterleitung oder ein Link-Kürzer angewendet, der sie entfernt oder beschädigt.

### Geschwindigkeit von „Please wait, loading Figma images...“

Figma hat vor einiger Zeit ein Update veröffentlicht, durch das alle Figma-Plugins warten müssen, bis jedes einzelne Bild auf der aktuellen Figma-Seite in voller Auflösung geladen ist, bevor ein Plugin Bilddaten exportieren kann (selbst wenn es nur eine Ebene bzw. ein Bild braucht).

Die einzige Lösung ist derzeit, die Anzahl der Frames bzw. Ebenen auf der aktuellen Figma-Seite möglichst gering zu halten. Dadurch geht dieser Vorgang beim ersten Start des Plugins deutlich schneller. Du kannst zum Beispiel in deiner aktuellen Figma-Datei eine ganz neue Seite anlegen und nur die Emailify-Frames, an denen du arbeiten oder die du exportieren möchtest, auf diese leere Seite legen. Wenn du das Plugin dort erneut ausführst, sollte alles viel schneller laden.

### Verpixelte Bilder beim Export

Wenn du deine E-Mail exportierst, während die Bilder in Figma noch schrittweise geladen werden, sehen sie im Export möglicherweise verpixelt aus, weil sie vor dem Export noch nicht vollständig in der Figma-Datei geladen waren. Stell deshalb sicher, dass alle Bilder zu 100 % geladen sind und in der Figma-Datei scharf aussehen, bevor du deine E-Mails mit dem Emailify-Plugin exportierst.

Zusätzlich kannst du mit der [Funktion „Downsizer“](/de/tinyimage/downsize) in [TinyImage](https://www.figma.com/community/plugin/789009980664807964/TinyImage-Compressor) deine Bildfüllungen auf die Größe ihrer Ebene verkleinern. Das reduziert ihre Dateigröße und sorgt dafür, dass sie in deiner Figma-Datei viel schneller laden.

### Beim Bearbeiten von PDFs in Adobe Acrobat erscheinen gepunktete Linien

Das lässt sich beheben, indem du beim Bearbeiten deines PDFs in der Seitenleiste der Acrobat-App den Schalter „Show bounding boxes“ deaktivierst. Die gepunkteten Begrenzungsrahmen blendet [Adobe standardmäßig ein](https://archive.md/Uhdbk), sobald du bei einem geöffneten PDF in den Modus „Edit“ wechselst. Mit einem Klick auf den Schalter „Show bounding boxes“ blendest du sie wieder aus.

### In China ist möglicherweise ein VPN nötig

Hinweis: Wenn du in China bist, wird der Kontoserver _möglicherweise_ von der „Great Firewall“ blockiert. Wenn du trotz eines gültigen Schlüssels einen Aktivierungsfehler siehst, brauchst du zur Lösung wahrscheinlich ein [VPN](https://protonvpn.com/free-vpn/).

### „An error occurred while loading the plugin environment“

Das kann in der Figma-Desktop-App passieren, wenn in Figma versehentlich die Debug-Einstellung [Use Developer VM](https://www.figma.com/plugin-docs/debugging/#developer-vm) aktiviert ist. Um sicherzugehen, dass sie ausgeschaltet ist, klick mit der **rechten Maustaste** auf eine beliebige Stelle im Figma-Canvas, fahr mit der Maus über **Plugins** und dann über **Development** und prüf, ob **Use Developer VM** _deaktiviert_ ist. Sobald die Option deaktiviert ist (und _kein_ Häkchen mehr daneben steht), sollte das Figma-Plugin beim erneuten Ausführen wie erwartet funktionieren.

### Bild-Uploads werden in deinem Netzwerk blockiert

Wenn du die Funktion **Upload Hosted Image URLs** aktiviert oder die HTML-E-Mail mit den integrierten Exportoptionen von Emailify auf eine E-Mail-Plattform hochgeladen hast, lädt das Plugin die Bilder automatisch hoch, damit sie online gehostet werden.

Wenn im Plugin eine Warnung erscheint (**Images uploads _may_ be blocked on your current network**), kann das Plugin den Upload-Dienst nicht erreichen, der zum Online-Hosting dieser Bilder nötig ist.

Meist liegt das daran, dass das Netzwerk (zum Beispiel das deines Unternehmens, dessen Firewall bestimmte URLs blockieren kann) oder der Internetanbieter, mit dem du verbunden bist, die URLs einschränkt oder blockiert. So gehst du bei der Fehlersuche vor:

- Nutz dein Smartphone per Tethering als WLAN-Hotspot für deinen Computer und führ das Figma-Plugin Emailify dann erneut aus, um zu sehen, ob das Problem damit gelöst ist. Wenn ja, hat dein anderes Netzwerk die Anfragen blockiert.
- Du kannst auch ein [VPN](https://protonvpn.com/) ausprobieren. Es tunnelt deine Netzwerkanfragen und sollte Netzwerksperren umgehen.
- Wenn du bereits ein VPN nutzt, schalte es _aus_ und führ das Figma-Plugin Emailify dann erneut aus, um zu sehen, ob das Problem damit gelöst ist.

Wenn das Problem weiterhin besteht, [melde dich gern](https://www.hypermatic.com/contact/) per E-Mail bei uns.

## E-Mail-Clients

### Das neue Outlook kann Stile nach dem Laden einer E-Mail umschreiben

Beim neuen Outlook für Windows wird ein Problem bei der Nachbearbeitung gemeldet: Eine E-Mail wird zunächst korrekt angezeigt und verändert sich dann, nachdem sie geladen wurde. Outlook scheint in diesem zweiten Rendering-Schritt Teile des CSS der E-Mail umzuschreiben. Das kann zu Problemen führen, etwa dass Desktop-Spalten unerwartet untereinander gestapelt werden.

Das Verhalten ist uneinheitlich: Ein Empfänger kann betroffen sein, während alle anderen das erwartete Layout sehen, und identische Testsendungen können im selben Postfach unterschiedlich dargestellt werden. Customer.io hat diese Symptome und die aktuellen Erkenntnisse in [New Outlook, same headache](https://customer.io/learn/message-composing/new-outlook-rendering-issues) dokumentiert.

Neue Emailify-Exporte enthalten eine vorsorgliche Kompatibilitätsschicht für den bekannten Fall gestapelter Spalten. Emailify behält die ursprünglichen responsiven Stile von MJML und die klassischen Tabellen-Fallbacks für Outlook bei und fügt zusätzlich eine zweite Kopie nur der erzeugten Regeln für Desktop-Spaltenbreiten in den Body der E-Mail ein. Das hilft webbasierten Outlook-Varianten, die Stile aus dem Head der E-Mail entfernen, und erhält gleichzeitig das normale mobile Stapeln und die Breakpoints von MJML für andere Clients.

Du musst das Design nicht neu aufbauen. Aktualisiere Emailify und exportiere die E-Mail erneut, damit das erzeugte HTML den Fallback enthält, bevor du einen weiteren Test sendest.

Wenn dieses Problem bei dir auftritt:

- Öffne die betroffene E-Mail in einem eigenen Fenster statt im Lese- bzw. Vorschaubereich von Outlook. In gemeldeten Fällen wird sie im eigenen Fenster oft korrekt dargestellt.
- Schick dasselbe exportierte HTML an einen anderen Empfänger oder E-Mail-Client, um zu prüfen, ob das Problem nur einen Outlook-Nutzer betrifft.
- Wenn identische Sendungen unterschiedlich dargestellt werden, lade beide empfangenen Nachrichten als `.eml`-Dateien herunter und vergleiche ihr HTML, bevor du das Emailify-Design oder den Export änderst.

> **Note:** Der Fallback verringert das gemeldete Stapeln der Desktop-Spalten, aber Emailify kann nicht jede Stiländerung kontrollieren, die nach der Zustellung vorgenommen wird. Wenn das Problem weiter besteht und das empfangene HTML unverändert ist, nimm keine größeren Designänderungen nur wegen einer einzelnen uneinheitlichen Outlook-Vorschau vor.

### Das Weiterleiten von HTML-E-Mail-Vorlagen macht sie kaputt

Wenn jemand eine empfangene, individuell gestaltete HTML-E-Mail an eine andere Person weiterleitet, wird die Darstellung der E-Mail dadurch leider oft beschädigt.

Der Grund: Verschiedene E-Mail-Clients verändern (oder entfernen) beim Weiterleiten Teile des HTML-Codes, wodurch die E-Mail kaputtgeht. Der Litmus-Artikel [When Forwarded Emails Break](https://www.litmus.com/blog/when-forwarded-emails-break/) beschreibt das so:

>Es ist allgemein bekannt, dass jeder E-Mail-Client E-Mails anders darstellt. Wenn ein Abonnent eine E-Mail weiterleitet, verändern manche E-Mail-Clients den Code der weitergeleiteten Nachricht. Dazu kann gehören, dass bestimmte HTML-Elemente entfernt werden, die E-Mail in ein Blockquote eingeschlossen wird oder zusätzliche Klassen in den Code eingefügt werden – all das kann dein Design zerstören und die E-Mail für den Empfänger der Weiterleitung weniger brauchbar machen.

Eine gängige Möglichkeit, die Auswirkungen abzumildern, ist eine „Web-Link“-Version, die im Browser geöffnet werden kann, falls die E-Mail nicht korrekt dargestellt wird. Dieser Link steht meist irgendwo oben in der E-Mail (wie [dieser hier](https://mailchimp.com/help/add-a-campaign-page-link-to-your-email-campaign/) in MailChimp). Bei Bedarf kannst du ihn auch als teilbaren Link an anderer Stelle in der E-Mail einbauen.

### Meine E-Mails landen im Spam. Woran könnte das liegen?

Es gibt ein paar häufige Gründe, warum deine E-Mails im Spam landen können:

- **Zu viele Links**: Jeder Link beeinflusst die Zustellbarkeit. Entferne Links, die nicht unbedingt nötig sind, auch überflüssige Social-Media-Links, damit deine E-Mails eher im Posteingang landen.
- **Schlechte Absenderreputation**: Wenn deine Domain oder IP eine Vorgeschichte mit geringer Interaktion, Bounces oder Beschwerden hat, können Postfachanbieter deine E-Mails markieren.
- **Spamverdächtige Inhalte**: Übermäßig werbliche Sprache (zum Beispiel „Gratis!“, „Jetzt zugreifen!“, „Nur für kurze Zeit“) oder zu viele Bilder und zu wenig Text können Filter auslösen.
- **Probleme bei der Authentifizierung**: Stell sicher, dass du SPF, DKIM und DMARC für deine Versanddomain korrekt eingerichtet hast.
- **Geringe Interaktion**: Wenn Abonnenten deine E-Mails dauerhaft nicht öffnen oder anklicken, werden künftige E-Mails eher als Spam markiert.
- **Qualität der Liste**: Der Versand an alte oder gekaufte Listen kann Bounces und Spam-Beschwerden verursachen, die deinem Sender Score schaden.

Vereinfache zuerst deine E-Mail, prüfe die Authentifizierung deiner Domain und streich überflüssige Links. Schon diese Änderungen verbessern die Zustellbarkeit oft.

### Dark-Mode-Anpassungen werden nur in Apple Mail unter iOS und Mac unterstützt

Derzeit ist die [Unterstützung für Dark-Mode-Stile in E-Mail-Clients](https://www.caniemail.com/features/css-at-media-prefers-color-scheme/) noch relativ gering. Berücksichtige das also und gestalte deine E-Mails so, dass diese Dark-Mode-Anpassungen als „Progressive Enhancement“ dienen.

Es lohnt sich auch, [ein paar andere clevere Designtechniken](https://www.campaignmonitor.com/blog/email-marketing/designing-an-email-for-dark-mode-dark-and-light-optimization/) zu nutzen, damit deine E-Mail auch in anderen E-Mail-Clients als Fallback mit dem Dark Mode zurechtkommt.

Der [Gmail-Workaround für weiße Buttontexte](#gmail-weisser-buttontext-dark-mode) hat einen engeren Zweck: reinweißen Buttontext zu erhalten. Er bietet keine Möglichkeit, schwarzen Text auf hellem Hintergrund im Dark Mode von Gmail unverändert zu lassen.

### Dünne weiße Subpixel-Linien bei gestapelten Bildern auf Mobilgeräten

Das passiert manchmal bei Inline-Bildern in voller Breite: Je nach Gerätebreite können sich beim Verkleinern des Bildes auf Mobilgeräten „Subpixel“ in die Bildhöhe einschleichen. Dadurch entsteht zwischen den Bildern eine feine Lücke, durch die der Hintergrund dahinter durchscheint.

Der schnellste Workaround ist, [eine Wrapper-Ebene](https://docs.hypermatic.com/emailify/design/wrappers) um die „Row“-Ebenen mit diesen Bildern zu legen und den Hintergrund dieses Wrappers als „Linear Gradient“ festzulegen, mit deiner Hintergrundfarbe (zum Beispiel Grau) auf beiden Seiten des Verlaufs. So wird der Hintergrund als Bild gerendert. Das verhindert, dass die CSS-Hintergrundfarbe im Dark Mode doch ersetzt oder zu Schwarz invertiert wird, und sorgt für einen einheitlichen Hintergrund hinter deinen Bild-Rows, der die Subpixel-Lücken verdeckt.

### Eingebettete Google Fonts und eigene Schriften werden nur in Apple Mail unter iOS und macOS unterstützt

Eigene Schriften werden in E-Mail-Clients derzeit [nur](https://www.caniemail.com/features/css-at-font-face/) in Apple Mail unter iOS und macOS unterstützt. Für deine Figma-Textebenen empfehlen sich daher [websichere Schriften](https://www.cssfontstack.com/). Diese legst du im Panel **Configure Fonts** unter der Funktion „Preview“ in Emailify fest.

Außerdem entfernen bestimmte E-Mail-Dienstleister (wie MailChimp) eigene Schriften aktiv, noch bevor die E-Mail versendet wird, damit nur websichere Schriften verwendet werden.

Emailify fügt aber trotzdem @imports für Google Fonts ein und legt eine websichere Ersatzschrift fest (zum Beispiel „Arial“, „Georgia“ oder „Courier“), wenn ein Google Font für Rich Text verwendet wird. Die Schriften sind in allen [E-Mail-Clients sichtbar, die @font-face](https://www.caniemail.com/features/css-at-font-face/) in E-Mails unterstützen.

**Eigene Schriften in Bildern verwenden**. Wenn eine eigene Schrift in allen E-Mail-Clients gleich aussehen muss, kann es sich lohnen, deine Textebenen in einen „Image“-Frame zu legen. Dieser Text wird dann als Teil des Bildes exportiert und ist für die korrekte Darstellung nicht auf die Unterstützung eigener Webfonts angewiesen.

### Formularelemente in E-Mails werden nicht unterstützt

Die Unterstützung für **form**-Elemente in HTML-E-Mails ist [noch ziemlich gering](https://www.campaignmonitor.com/blog/email-marketing/how-forms-perform-in-html-emai/). Enthaltene Formulare können außerdem dazu führen, dass E-Mails als Spam o. Ä. markiert werden. Verzichte daher derzeit am besten auf native Formulare in HTML-E-Mails.

Der beste Workaround ist ein ansprechender Call-to-Action-Button (CTA) in deinem Emailify-Design, der auf ein externes Formular wie [Google Forms](https://docs.google.com/forms/) oder [Typeform](https://www.typeform.com/) verlinkt. Dort sammelst du die Angaben der Empfänger dann im Browser.

### So funktioniert das Blockieren von Bildern in manchen Clients

Die beiden sehr guten Artikel unten erklären, was das Blockieren von Bildern ist und welche E-Mail-Clients es standardmäßig aktivieren (hauptsächlich Outlook), während andere Clients wie Gmail, Android, Apple/iOS usw. Bilder standardmäßig anzeigen.

[How Image Blocking Works in Email](https://www.campaignmonitor.com/resources/guides/image-blocking-in-email/)

[Email Image Blocking: Answering the What, Why, Where, Who, and How](https://www.litmus.com/blog/the-ultimate-guide-to-email-image-blocking/)

Leider hat das nichts damit zu tun, ob die Bilder sicher (SSL) eingebunden sind oder nicht. Es gilt immer pauschal für alle Bilder in der E-Mail.

Der Vorteil: Empfänger, die einen der zuerst genannten E-Mail-Clients nutzen, sind das meist gewohnt und klicken auf den Button „Bilder anzeigen“ – oder sie haben das Anzeigen von Bildern für eingehende E-Mails ohnehin schon standardmäßig aktiviert.

### Lila Text in Gmail (mehrere Testsendungen mit derselben Betreffzeile)

Wenn du mehrere Tests einer E-Mail an ein Gmail-Konto sendest, fällt dir vielleicht auf, dass bestimmter Text dunkellila ist.

Das ist kein Problem deines HTML-Codes. Es passiert, wenn Gmail annimmt, dass mehrere am selben Tag gesendete E-Mails mit demselben Betreff Antworten aufeinander sind. Dann zeigt Gmail die E-Mails als Thread in der „Konversationsansicht“ an.

Mehr über die Konversationsansicht von Gmail erfährst du in der [Dokumentation von Google](https://support.google.com/mail/thread/5162234?hl=en):

>Die lila Färbung ist eine reine Anzeigefunktion, die nur in der Ansicht existiert, in der sie zu sehen ist. Sie wird in keiner Nachricht mitgesendet, und du kannst das mit der Gmail-Funktion „Original anzeigen“ überprüfen – dafür musst du dich ein wenig mit HTML-Code auskennen.

>Die Farbe wird auf Text angewendet, der aus einer früheren Nachricht der aktuellen Konversation wiederholt wird. Für Empfänger ist sie sichtbar, weil sie ebenfalls Gmail nutzen und ebenfalls Kopien der früheren Nachrichten der aktuellen Konversation haben. Was in ihrer Konversation eingefärbt wird, kann sich deutlich von dem unterscheiden, was in deiner eingefärbt wird.

### E-Mail-Clients fügen Datumsangaben, Telefonnummern und Adressen blaue Links hinzu

Das ist ein altbekanntes Problem: Bestimmte E-Mail-Clients [versehen Dinge wie Datumsangaben, Telefonnummern und Adressen automatisch mit Links](https://www.litmus.com/blog/how-to-fix-blue-links-in-gmail) und [wenden außerdem ihre eigenen Farbstile](https://www.litmus.com/blog/update-banning-blue-links-on-ios-devices-2) darauf an (meist blaue Links).

Emailify wendet automatisch alle [empfohlenen Code-Korrekturen](https://email2go.io/blog/all-about-blue-links-in-emails) an, um das in manchen E-Mail-Clients abzumildern. Die Clients werden aber oft so aktualisiert, dass sie diese Korrekturen umgehen oder entfernen.

Es gibt 2 zusätzliche Methoden, mit denen du verhindern kannst, dass der E-Mail-Client automatisch Links hinzufügt (beide werden in den Artikeln oben erwähnt):

**Methode Nr. 1**: Versieh jede dieser Textebenen in Figma vorab mit einem Platzhalter-Link (zum Beispiel zu deiner eigenen Website), entferne in Figma die Unterstreichung und leg die Farbe nach Belieben fest (damit der Text nicht anklickbar wirkt). Dadurch liegt bereits ein Link-Tag um den Datumstext, und der E-Mail-Client versucht nicht, automatisch einen eigenen, ungestylten Link anzuwenden.

**Methode Nr. 2**: Füg direkt nach dem ersten Zeichen jedes Datums, jeder Telefonnummer oder Adresse eine spezielle unsichtbare HTML-Entität ein (nämlich `‌`), zum Beispiel `6‌75 Massachusetts Ave, Cambridge, MA 02139`. Damit lässt sich der E-Mail-Client hoffentlich überlisten, sodass er den Text nicht als Datum erkennt und nicht automatisch einen Datumslink anwendet.

### Bestimmte VPNs können die Anzeige hochgeladener Bilder blockieren

Wenn du die Funktion **Upload Hosted Image URLs** aktiviert oder die HTML-E-Mail mit den integrierten Exportoptionen von Emailify auf eine E-Mail-Plattform hochgeladen hast, gibt es einen sehr seltenen Sonderfall: Bestimmte IP-Adressen, die manche VPNs vergeben, werden vom Bild-Host blockiert, sodass das Bild nicht geladen wird.

Wenn Bilder nicht geladen werden, ist das wahrscheinlich die Ursache (schalte dein VPN vorübergehend aus, um das selbst zu überprüfen).

### E-Mail-Signaturen unterstützen keine eigenen Schriften

Bei vollständigen bzw. normalen HTML-E-Mails lassen sich eigene Schriften einbetten – allerdings _nur_ für Apple Mail (andere Clients wie Gmail und Outlook unterstützen keinerlei eingebettete eigene Schriften). E-Mail-Signaturen dagegen [unterstützen](https://signature.email/guides/can-i-use-google-fonts-in-email-signatures) überhaupt kein **style**-Tag, über das sich Code zum Einbetten von Schriften hinzufügen ließe. Gestalte deine Signaturen daher stattdessen mit websicheren Systemschriften.

### Die Gmail-App unter iOS rendert keine responsiven Stile für Mobilgeräte

Der Hauptgrund dafür: Wenn eine CSS-Eigenschaft oder ein Stil in der `@media`-Query einen Tippfehler enthält (zum Beispiel `padding-bottm` statt `padding-bottom`) oder mitten in einer Stileigenschaft ein Zeilenumbruch steht (zum Beispiel `padd` _neue Zeile_ `ing-top`), ignoriert die Gmail-App _alle_ anderen Stile und rendert keine responsiven Anpassungen für Mobilgeräte.

Bei Code, der direkt über das Plugin exportiert wurde, sollte das nicht vorkommen. Es kann aber passieren, wenn du den HTML-Code nach dem Export aus Emailify von Hand bearbeitest (oder wenn deine E-Mail-Marketing-Plattform den Code verändert oder Zeilenlängen begrenzt).

### Limit von 500 Zeichen pro Zeile in HTML-E-Mails

Emailify begrenzt exportiertes HTML auf 500 Zeichen pro Zeile. Das formale Limit liegt zwar bei 998 Zeichen, aber kürzere Zeilen vermeiden Probleme bei Darstellung und Zustellung, die in Outlook und bei manchen E-Mail-Dienstleistern auftreten.

### VPNs können dazu führen, dass sich manche Social-Media-Links nicht richtig öffnen

Das scheint zwar selten vorzukommen, aber wenn sich Links zu manchen sozialen Netzwerken (zum Beispiel Facebook, Instagram) nicht richtig öffnen, ist das wahrscheinlich die Ursache (schalte dein VPN vorübergehend aus, um das selbst zu überprüfen) – und kein Problem der HTML-E-Mail oder der Links selbst.

## Outlook

### Border-Radius wird in Outlook nicht angezeigt

Die Eigenschaft border-radius wird in Outlook leider nicht unterstützt. Stattdessen werden immer normale, eckige Kanten angezeigt. In der [Support-Liste für border-radius](https://www.caniemail.com/features/css-border-radius/) siehst du genauer, welche E-Mail-Clients diese CSS-Eigenschaft unterstützen.

### Button-Höhe fällt in Outlook.com zusammen (weil keine echte URL gesetzt ist)

Wenn die Höhe einer Button-Komponente auf die Größe der Textebene darin zusammenfällt, liegt das daran, dass Outlook.com so reagiert, wenn `href` nicht auf eine echte URL gesetzt ist (zum Beispiel `[replaceLinkInHere]` statt einer echten URL wie `https://google.com`). Setz eine echte URL für deine Button-Komponente: Klick in Figma auf die Button-Ebene, nutze im Plugin den Button **Settings** und füg dort deine URL ein.

### 1px breite weiße Linie bei Rows mit „umgekehrter Reihenfolge“ in bestimmten Outlook-Versionen

In manchen Outlook-Versionen gibt es einen bekannten Fehler bei der Einstellung [Spalten umkehren](/de/emailify/design/reverse-columns): Neben einer der Spalten kann eine 1px breite weiße Linie erscheinen. Das ist eine der Rendering-Eigenheiten von Outlook, verursacht durch die Rendering-Engine von Microsoft Word, und kann auftreten, wenn auch auf die umgekehrte Row ein Padding angewendet wird.

Der beste Workaround ist, das Padding von dieser umgekehrten **Row**-Ebene zu entfernen, die Row in einen [Wrapper](/de/emailify/design/wrappers) zu legen und das Padding stattdessen auf den äußeren **Wrapper** zu verschieben. So bleibt der optische Abstand gleich, aber der Outlook-Rendering-Fehler bei der umgekehrten Row selbst wird vermieden.

Dieser Workaround entspricht dem Ansatz, der im zugehörigen [MJML-Issue auf GitHub](https://github.com/mjmlio/mjml/issues/2828) diskutiert wird.

### Outlook macht aus Datums- und Zeitangaben automatisch blaue Kalenderlinks

Damit Outlook den Text nicht als Datum bzw. Uhrzeit erkennt und ihn nicht automatisch als Link darstellt, kannst du zwischen Tagen, Datumsangaben und Uhrzeiten die HTML-Entität für ein „Leerzeichen ohne Breite“ (`​`) einfügen. Das unterbricht die Mustererkennung von Outlook, wie in diesem getesteten und funktionierenden Beispiel: `Monday​ — Friday 8​am to 5​pm`

### Großbuchstaben mit Akzenten (diakritischen Zeichen) werden abgeschnitten

Wenn du eine Textebene in Großbuchstaben hast und einige Zeichen diakritische Zeichen enthalten (zum Beispiel Ä, Ö, Ü), deren oberer Akzent in Outlook nicht angezeigt wird, liegt das daran, dass der Wert für die Zeilenhöhe („line height“) der Textebene in Figma kleiner ist als die Schriftgröße („font size“). Outlook schneidet alle Inhalte ab, die nicht innerhalb der Zeilenhöhe liegen (anders als andere Clients, die sie einfach normal überlaufen lassen).

Um das zu beheben, musst du nur die Zeilenhöhe etwas größer als die Schriftgröße einstellen. Wenn du zum Beispiel eine Textebene mit der Schriftgröße „24px“ hast und die Zeilenhöhe derzeit „23px“ beträgt, erhöhst du die Zeilenhöhe in Figma von „23px“ auf „28px“ (damit genug zusätzlicher Platz für die Akzente über der Versalhöhe der 24px großen Schrift bleibt). Dann werden die Akzente bzw. diakritischen Zeichen in Outlook wie erwartet dargestellt, ohne wegen der geringeren Zeilenhöhe abgeschnitten zu werden.

### Der zufällige „1px-Linien“-Fehler in Outlook

Es gibt ein sehr lästiges Problem, bekannt als [Outlook-1px-Linien-Fehler](https://www.emailonacid.com/blog/article/email-development/how-do-i-get-rid-of-the-lines-in-outlook-emails/), das zufällig in bestimmten Outlook-Versionen auftritt:

>Outlook fügt unseren E-Mails zusätzliche Linien hinzu. Diese Linien übernehmen den Hintergrund, der für dein **body**-Tag festgelegt ist … und als wäre das nicht genug, scheint dieser Fehler zufällig aufzutreten, wobei er auf Windows-10-Rechnern häufiger vorkommt als unter Windows 7.

Wie im Artikel oben erwähnt, tritt der Fehler ziemlich zufällig auf, und es gibt keine zuverlässige Lösung. Er lässt sich aber _meist_ durch Ausprobieren beheben, indem du die Schriftgröße des Textes oberhalb der Stelle anpasst, an der die Linie erscheint. Zum Beispiel (aus dem Artikel):

>Bei manchen ist die Lösung so einfach, wie Schriftgrößen von ungeraden auf gerade Zahlen zu ändern. Wenn du zum Beispiel eine Schriftgröße von 13px oder 15px hast, versuch es mit 14px.

Ein weiterer guter Überblicksartikel, [Fixing White Lines in Outlook](https://www.actionrocket.co/email-design-review/white-lines-in-outlook), geht ebenfalls auf weitere Details und mögliche Lösungen ein.

Wenn du tiefer einsteigen möchtest: Der Artikel [Outlook 2016 madness and the weird 1px thin horizontal lines](https://mosaico.io/email-client-tricks/outlook-2016-weird-1px-horizontal-lines/) erklärt das zugrunde liegende Problem genauer, und diese ausführliche [Diskussion im Litmus-Forum](https://litmus.com/community/discussions/4990-outlook-2016-1px-horizontal-lines-showing-up-in-the-body) stellt Vermutungen zu möglichen Ursachen und Ansätzen zur Fehlersuche an.

## Gmail

### Gmail kürzt die E-Mail

Gmail [kürzt E-Mails](https://mailchimp.com/help/gmail-is-clipping-my-email/), deren Nachrichtengröße 102KB übersteigt, und verbirgt den vollständigen Inhalt hinter einem Link „View entire message“. Um das zu vermeiden, prüf vor dem Export mit dem Button **Preview** die Größe deiner HTML-Datei und entferne so viel Inhalt wie möglich, um die Dateigröße zu verringern.

Wird die E-Mail trotzdem gekürzt, obwohl sie unter dem Limit für die HTML-Dateigröße liegt, liegt das [höchstwahrscheinlich](https://www.emailonacid.com/blog/article/email-development/gmail-email-clipping/) an einem UTF-8-Zeichen im Inhalt der E-Mail, das Gmail ebenfalls dazu bringen kann, die E-Mail zu kürzen. Die beste Lösung ist, das UTF-8-Zeichen durch seine HTML-codierte Version zu ersetzen (zum Beispiel `&copy` statt `©`). Das erledigt das Plugin automatisch.

Ein weiterer Grund: Wenn du E-Mails mit derselben Betreffzeile versendest (zum Beispiel mehrere Tests an dich selbst), fasst Gmail die E-Mails in einem einzigen Thread zusammen und kann den Inhalt der folgenden Sendungen kürzen. Um das zu umgehen, verwende immer eine andere Betreffzeile (zum Beispiel „Test v1“, „Test v2“ usw.).

### Buttons mit weißem Text werden in der mobilen Gmail-App im Dark Mode schwarz {#gmail-weisser-buttontext-dark-mode}

Gmail (und andere Apps) wenden automatisch Dark-Mode-Stile auf deine E-Mail an, wenn das System des Nutzers auf den Dark Mode eingestellt ist – das betrifft auch Buttons.

Für Buttons, die im Light Mode und im Dark Mode weißen Text haben sollen:

1. Setz die Textebene des Buttons in Figma auf reines Weiß (`#FFFFFF`).
2. Wähl die Komponente **Button** aus, öffne **Settings** und setz die Textfarbe für die Dark-Mode-Anpassung ebenfalls auf reines Weiß (`#FFFFFF`).
3. Exportiere die E-Mail erneut und sende einen Test an die mobile Gmail-App, in der du das Problem gesehen hast.

Wenn beide Farben auf reines Weiß gesetzt sind, fügt Emailify zusätzlichen Kompatibilitätscode hinzu, der den weißen Buttontext erhalten soll. Dieser Workaround erhält keinen schwarzen oder anderen nicht weißen Text und fixiert auch nicht die Hintergrundfarbe des Buttons. Wenn dein Design schwarzen Text auf hellem Hintergrund braucht, behalte diese beabsichtigten Farben bei und teste dieses Design separat. Den Text auf Weiß umzustellen, würde das Design verändern, statt diese Anforderung zu erfüllen.

Wenn das Ergebnis weiterhin von deinem Design abweicht, [wende dich an den Support](/de/faq/contact-and-account-help) und schick das exportierte HTML oder ZIP, einen Screenshot, die E-Mail-App und das Gerät sowie die Text- und Hintergrundfarben mit, die erhalten bleiben sollen. Gib auch die Einstellungen an, die du schon ausprobiert hast. Unter [Dark Mode gestalten und testen](/de/emailify/design/dark-mode) findest du den gesamten Workflow und die Einschränkungen.

### Spalten werden in Gmail auf dem Desktop gestapelt

Manche E-Mail-Dienstleister (wie MailChimp) versuchen, das HTML deiner E-Mail vor dem Versand zu verändern. Dadurch können einige Spalten deiner E-Mail in Gmail auf dem Desktop untereinander gestapelt statt nebeneinander angezeigt werden.

Meist verändern diese Plattformen dein HTML, um Stile per „Inlining“ direkt auf deine HTML-Elemente anzuwenden. Emailify setzt aber bereits alle CSS-Stile automatisch inline, damit deine E-Mails produktionsreif sind. Wenn du in den HTML- bzw. Importoptionen deines E-Mail-Dienstleisters eine Einstellung findest, mit der du dieses Inlining oder die Veränderung „deaktivieren“ kannst, sollte das Problem damit gelöst sein.

Wenn du nicht sicher bist, ob dein E-Mail-Dienstleister oder der Code selbst die Ursache ist, schick dir mit einem kostenlosen Dienst wie [htmltest.email](https://htmltest.email/) (der dein HTML nicht verändert) eine Test-E-Mail. Funktioniert der Test über [htmltest.email](https://htmltest.email/), verändert dein E-Mail-Dienstleister dein HTML vor dem Versand.

### Gmail unter iOS erzwingt eine minimale Zeilenhöhe

Wenn du `line-height` auf einen Wert kleiner als die aktuelle `font-size` setzt, ändert Gmail das automatisch in `line-height:normal;`. `line-height:1`, `line-height:1em` und `line-height:100%` funktionieren also wie erwartet, `line-height:0.9`, `line-height:0.9em` und `line-height:99%` werden dagegen alle in `line-height:normal;` umgewandelt.

Dasselbe gilt für px-Werte: `font-size:20px; line-height:19px` funktioniert nicht, `font-size:19px; line-height:19px` dagegen schon.

Um das Problem zu beheben, stell einfach sicher, dass die Zeilenhöhe deiner Textebene gleich groß oder größer als die Schriftgröße ist.

### Die Gmail-App unter iOS rendert keine responsiven Stile für Mobilgeräte

Der Hauptgrund dafür: Wenn eine CSS-Eigenschaft oder ein Stil in der `@media`-Query einen Tippfehler enthält (zum Beispiel `padding-bottm` statt `padding-bottom`) oder mitten in einer Stileigenschaft ein Zeilenumbruch steht (zum Beispiel `padd` _neue Zeile_ `ing-top`), ignoriert die Gmail-App _alle_ anderen Stile und rendert keine responsiven Anpassungen für Mobilgeräte.

Bei Code, der direkt über das Plugin exportiert wurde, sollte das nicht vorkommen. Es kann aber passieren, wenn du den HTML-Code nach dem Export aus Emailify von Hand bearbeitest (oder wenn deine E-Mail-Marketing-Plattform den Code verändert oder Zeilenlängen begrenzt).

### Gmail übersetzt rein englische E-Mails fälschlich in andere Sprachen

Wenn deine E-Mail hauptsächlich aus Bildblöcken ohne Rich Text besteht oder vor dem ersten Rich Text weiter unten viele Bildblöcke enthält, hält Gmail die E-Mail manchmal für eine E-Mail in einer anderen Sprache und bietet an, sie ins Englische zu übersetzen. Das passiert, obwohl Emailify den Tags **html** und **body** automatisch ein Attribut `lang="en"` hinzufügt.

Laut [diesem Beitrag dazu](https://litmus.com/community/discussions/7028-gmail-mis-translating-our-english-only-emails-into-other-languages) im Litmus-Forum:

>Wir haben (empirisch) festgestellt, dass Mails, die vor dem eigentlichen Inhalt viel CSS und HTML enthalten, als Englisch eingestuft werden, obwohl der Inhalt in einer anderen Sprache ist.

>Unser Workaround ist, eine Multipart-E-Mail mit Text und HTML zu senden, wobei die Textversion vor dem HTML-Teil steht. Der Text muss natürlich substanziell sein, nicht nur „Bonjour …“, sonst überwiegen weiterhin die HTML-Tags und das CSS.

>Der Übersetzungsalgorithmus scheint gar nicht zu versuchen, HTML und CSS aus dem Body der Mail zu entfernen. Oder wenn doch, kürzt er die Nachricht vielleicht vor dem Entfernen und hat am Ende nur sehr wenig Inhalt für die Erkennung. (Heutzutage kommt man schnell auf >5000 Zeichen Header und CSS, bevor auch nur eine Zeile Inhalt kommt.)

## GIFs

### Videos in animierte GIFs für deine E-Mails umwandeln

Native **video**-Tags werden in HTML-E-Mails leider [nicht unterstützt](https://www.caniemail.com/features/html-video/). Animierte Bilder oder Videoinhalte bringst du daher am besten als GIFs in deine HTML-E-Mail-Designs – entweder mit einer GIF-Datei aus dem Internet oder mit einer, die du selbst erstellt hast.

Wenn du schon ein Video hast, das du als GIF verwenden möchtest, kannst du mit der kostenlosen App [Gifski](https://gif.ski/) kurze Videodateien in animierte GIF-Dateien für deine E-Mail-Designs umwandeln.

Außerdem gibt es ein [gutes Video-Tutorial](/emailify/tutorials/add-animated-gifs-from-figma-to-html-email-exports), das die verschiedenen Möglichkeiten zeigt, GIFs in deinen Emailify-Designs zu verwenden und in deine HTML-Exporte aufzunehmen.

### Farben und Verläufe in GIFs wirken etwas körnig

GIFs unterscheiden sich etwas von normalen JPG- oder PNG-Bildern, denn sie können höchstens 256 Farben enthalten. Wenn du sehr detailreiche Bilder oder Verläufe mit vielen Farbabstufungen verwendest, ist zu erwarten, dass das GIF wegen dieser Einschränkung des GIF-Formats nicht so scharf aussieht und nicht dieselbe Farbtreue hat wie die Originalbilder, aus denen es erstellt wurde.

### Transparenz wird in GIFs nicht angezeigt

Das GIF-Dateiformat unterstützt entweder 0 % oder 100 % Deckkraft, aber nichts dazwischen. Du kannst also ein animiertes GIF mit vollständig transparentem Hintergrund hinter vollständig deckenden, sichtbaren Elementen haben. Ebenen müssen daher entweder vollständig transparent sein oder gar nicht: Ebenen mit weniger als 50 % Deckkraft werden transparent, Ebenen mit mehr als 50 % Deckkraft deckend.

**Transparente GIFs in Figma kennzeichnen**. Emailify versucht automatisch zu erkennen, ob dein GIF einen transparenten Hintergrund enthält. Wenn dein GIF Transparenz braucht und das Plugin das nicht selbst erkennt, füg das Wort **Transparent** irgendwo in den Namen deiner Figma-Ebene ein (zum Beispiel `My Layer Name - Transparent`), um den Export mit transparentem Hintergrund zu erzwingen.

### Original-GIF beim Export beibehalten (durch Beibehalten des Seitenverhältnisses)

Wenn du dein GIF in Figma ablegst und die Ebene proportional skalierst, sodass das ursprüngliche Seitenverhältnis erhalten bleibt, verwendet Emailify in deinen Exporten automatisch die Original-GIF-Datei.

Änderst du dagegen das Seitenverhältnis deiner Figma-Ebene, sodass es vom Original-GIF abweicht, muss Emailify dein GIF neu erstellen, um den zugeschnittenen Bildbereich zu berücksichtigen. Das kann zu größeren GIF-Dateien und längeren Exportzeiten führen.

### GIF wird in Gmail nicht angezeigt (Limit für die Dateigröße)

Wenn du in deinem Design GIFs verwendet hast, sie aber bei einer Testsendung an ein Gmail-Postfach nicht erscheinen, wird wahrscheinlich das [Limit des Gmail-Bild-Caches](https://stackoverflow.com/questions/49771254/images-in-gmail-not-displaying-due-to-google-image-cache-proxy) erreicht, weshalb sie nicht gerendert werden.

Beim HTML-Export versucht Emailify, große GIFs so zu komprimieren, dass sie unter dem Limit für die Dateigröße bei Gmail liegen. Damit sollte das Problem in fast allen Fällen gelöst sein (außer das GIF ist von vornherein außergewöhnlich lang, sehr groß oder hat eine sehr hohe Bildrate).

## Klaviyo

### Der Vorlagen-Editor von Klaviyo stürzt (manchmal) ab, wenn dein E-Mail-Design GIFs enthält

Es gibt einen sporadischen Fehler in Klaviyo, der einen Error 500 (interner Serverfehler) auslöst. Dabei erscheint eine Seite mit der Meldung **Something is amiss. We're on it.**. Das scheint vor allem dann zu passieren, wenn die Vorlage „Editable“ ist.

Klaviyo kennt diesen Fehler, scheint aber keine Pläne zu haben, ihn kurzfristig zu beheben.

Ein Workaround: Entferne das GIF aus deinem Figma-Design, bevor du das HTML für Klaviyo exportierst, und lade das GIF dann separat in Klaviyo hoch, nachdem der Vorlagen-Editor ohne den oben genannten Fehler geladen hat.

### Zusätzliches Padding um Textblöcke in bearbeitbaren Klaviyo-Vorlagen

Klaviyo hat [seinen Editor aktualisiert](https://help.klaviyo.com/hc/en-us/articles/13160284274459) und verlangt seit dem 6. Juni 2023, dass alle Vorlagen ihn nutzen. Wenn du HTML-E-Mails mit aktiviertem Schalter **Editable Content** in Emailify exportierst, fügt Klaviyo deshalb leider standardmäßig automatisch etwa 18px zusätzliches Padding um jedes Textelement hinzu – als Inline-Attribut `style` an einem neuen **td**-Element, das Klaviyo bei bearbeitbaren Vorlagen in das HTML einfügt.

Wenn du in Emailify den Schalter **Force the padding added by Klaviyo's new editor to be 0px** aktivierst, fügt Emailify automatisch zusätzliches CSS hinzu, das dieses Padding in allen mobilen Clients und in Desktop-Clients außer Outlook (wie Gmail usw.) entfernt. _Outlook_ rendert das Padding aber weiterhin, sofern du nicht beim Bearbeiten der E-Mail für deine Kampagne im Klaviyo-Editor jeden „Padding“-Wert aller bearbeitbaren Textblöcke deiner Vorlage von Hand auf „0“ setzt.

### Der Vorschautext in Klaviyo ist doppelt oder zeigt zusätzlichen Fließtext

Leg den Vorschautext nur an einer Stelle fest. Wenn du in Emailify bereits **Preheader Text** eingegeben hast, lass das Vorschautext-Feld in Klaviyo leer. Wenn du den Vorschautext lieber in Klaviyo verwaltest, lass den Preheader in Emailify für diesen Export leer.

Wenn Klaviyo nach deinem gewünschten Vorschautext immer noch zusätzlichen Fließtext anzeigt, aktiviere in den Exportoptionen von Emailify **Add Whitespace to Preview Text** und exportiere die E-Mail erneut. Dadurch wird nach einem nicht leeren Preheader ein unsichtbarer Kompatibilitäts-Abstandhalter eingefügt. Wie Postfächer damit umgehen, kann sich zwischen Klaviyo und verschiedenen E-Mail-Clients aber trotzdem unterscheiden.

Unter [Betreffzeile und Preheader-Text für deine HTML-E-Mails festlegen](/de/emailify/export/subject-and-preheader) findest du den vollständigen Workflow für den Preheader.

## MailChimp

### Bearbeitbare Bilder verwenden unschärfere @1x-Bilder (statt @2x-Retina)

Mit dem Schalter **Editable Images** kannst du die Bilder in der Vorlage optional in MailChimp bearbeitbar machen. Leider [unterstützt MailChimp keine bearbeitbaren @2x-Retina-Bilder](https://github.com/mailchimp/email-blueprints/issues/37), daher werden stattdessen @1x-Bilder verwendet.

Wenn du lieber @2x-Retina-Bilder möchtest, die nicht bearbeitbar sind, lass diese Option ausgeschaltet.

### MailChimp entfernt das Link-Styling beim Einbetten von <link>-Tags für Typekit-Schriften

MailChimp entfernt Link-Stile, wenn deiner E-Mail ein eigenes **Typekit-Stylesheet** hinzugefügt wird. Genauer gesagt: Wenn du ein Tag wie ``

in den `` einfügst, entfernt MailChimp alle **`style`**-Attribute aus deinen **``**-Tags. Wenn du dieses Tag entfernst, ist das Problem behoben und deine Link-Stile sind wieder da.

Wenn du deine Typekit-Schriften trotzdem verwenden möchtest, geht das über die integrierte Funktion **Web Fonts** des Plugins. Statt das Stylesheet zu verlinken, brauchst du die direkte URL der **`.woff2`**-Schriftdatei aus deiner Typekit-CSS-Datei (zum Beispiel:
`https://use.typekit.net/...`). Füg diese URL im Panel **Configure Fonts** des Plugins ein. Das Plugin erzeugt dann automatisch den passenden `@font-face`-Stil für die Namen deiner Figma-Schriften im HTML. Mehr dazu zeigt das [Schritt-für-Schritt-Video-Tutorial](https://youtu.be/dtTNDXeO3FA).

Eigene Webfonts funktionieren nur in **Apple Mail**. Andere E-Mail-Clients (wie Outlook oder Gmail) unterstützen sie nicht. Wir empfehlen daher, im Plugin eine **websichere Ersatzschrift** festzulegen, um zu steuern, was angezeigt wird. Viele Nutzer finden es am einfachsten, in Figma mit websicheren Schriften zu gestalten. Eigene Webfonts können für Apple-Mail-Nutzer aber trotzdem eine schöne progressive Erweiterung sein.