Was du vor jeder Kampagne prüfst und wo die E-Mail-Prüfung von Brew warnt: Kürzung ab 102 KB, tote Links, Alternativtext, Client-Kompatibilität, Textlänge.
Eine QA-Checkliste vor dem Versand ist die kurze Liste von Prüfungen, die du bei jeder E-Mail durchgehst, bevor sie rausgeht. Fehlerhafte Kampagnen gehen meist mit einem Button raus, der noch auf # zeigt, mit einem Hero-Bild, das um 18 Uhr gegen ein PNG mit 4 MB getauscht wurde, oder mit einem zweispaltigen Layout, das das klassische Outlook ignoriert. Jeder dieser Fehler ist vor dem Versand in einer Minute gefunden und lässt sich danach nicht mehr beheben.
Wir haben die E-Mail-Prüfung von Brew diesen Monat neu aufgebaut, und zwar genau rund um diese Punkte, jeden mit einem exakten Schwellenwert. Du kannst sie auch von Hand abarbeiten, mit oder ohne Brew.
Befunde nach Schweregrad gruppiert, mit einem einzigen Urteil zur Versandbereitschaft.
Ein kaputter Link macht den Versand wertlos. Stell sicher, dass:
#, example.com oder ein leeres {{url}} zeigthttps verwendetbrew.new/pricing, das woandershin führt, sieht nach Phishing ausKlick jeden Link in einer zugestellten Test-E-Mail an, nicht im Editor. Dein ESP schreibt Links beim Versand für das Klick-Tracking um, deshalb zeigen sich Weiterleitungsketten und kaputte Tracking-Parameter erst dort.
Lass nie ein automatisches Prüftool Abmelde- oder Einstellungslinks aufrufen. Manche Anbieter werten jeden Aufruf dieser URL als Abmeldung. Und wenn ein Prüftool auf eine Bot-Sperre trifft, beweist das nicht, dass der Link tot ist. Klick ihn selbst an.
Gmail kürzt Nachrichten mit mehr als etwa 102 KB HTML und versteckt den Rest hinter dem Link „Gesamte Nachricht anzeigen“. Damit verschwinden Footer, Abmeldelink und Postanschrift, und eine gekürzte Marketing-E-Mail wird unbemerkt zum Compliance-Problem.
Unsere Schwellenwerte:
Wir warnen schon bei 80 KB, weil Klick-Tracking kurze Links durch längere Weiterleitungs-URLs ersetzt und manche ESPs zusätzliches Markup einfügen. Aus 98 KB in deinem Editor können beim Empfänger 105 KB werden.
Typischer Ballast: Inline-Styles, die sich an jedem Element wiederholen, übrig gebliebene Kommentare des Builders, versteckte doppelte Abschnitte für Mobil und Desktop und eingebettete Base64-Bilder.
Jedes Bild sollte:
alt-Text haben, oder alt="", wenn es rein dekorativ istwidth und height haben, damit das Layout hält, während Bilder laden oder wenn sie blockiert werdenEin großes Bild über einer Zeile Text ist bei deaktivierten Bildern unlesbar, für Screenreader nicht erfassbar und für manche Filter ein Spam-Signal. Setz Headline und Angebot als echten Text.
Flexbox, Grid, position, Hintergrundbilder und Inline-SVG funktionieren jeweils in mindestens einem großen Client nicht. Can I email erfasst die Unterstützung pro Funktion und Client und ist die beste einzelne Referenz.
Am genauesten solltest du auf Outlook achten. Gmail und Apple Mail verschlechtern die Darstellung meist unauffällig. Das klassische Outlook unter Windows rendert mit der Layout-Engine von Word, ignoriert viele CSS-Breiten, lässt Hintergrundbilder weg und entfernt den Innenabstand von Buttons, die als gestaltete Links gebaut sind.
Wir markieren eine Funktion für eine Client-Familie wie Gmail oder Outlook nur, wenn mindestens zwei ihrer Clients sie nicht unterstützen. Eine Warnung gibt es nur, wenn die Funktion in Outlook ohne Fallback nicht funktioniert. Alles andere ist Info. Sonst bekäme jede E-Mail zwanzig Client-Warnungen, und alle würden sie ignorieren.
Die schnellen Prüfungen:
lang auf <html>, damit Screenreader alles richtig aussprechen<title>h1 zu h4Die Referenz ist WCAG 2.2. Die meisten Probleme in E-Mails lassen sich ihren Kriterien zu Textalternativen, Kontrast, Sprache der Seite und Überschriften zuordnen.
Halte Betreffzeilen unter etwa 60 Zeichen und 9 Wörtern, sonst schneiden Smartphones sie ab. Verzichte auf DURCHGEHENDE GROSSBUCHSTABEN, auf „RE:“ oder „FWD:“ bei E-Mails, die keine Antwort sind, und auf Reihen von Ausrufezeichen.
Halte den Vorschautext unter etwa 90 Zeichen und wiederhole darin nicht den Betreff. Lässt du ihn leer, zeigen viele Clients stattdessen „Im Browser anzeigen“ an.
Ein Merge-Tag ohne Fallback schickt „Hallo ,“ an alle, deren Vorname fehlt. Das merken sich die Leser.
Für jede Zahl sollte es eine Quelle geben, auf die du verweisen kannst, besonders in ersten KI-Entwürfen, die schnell mit selbstbewussten Zahlen bei der Hand sind. Mehr zur Formulierung findest du im Leitfaden zum Schreiben von Marketing-E-Mails und im Leitfaden zu Betreffzeilen.
Kommerzielle E-Mails brauchen nach CAN-SPAM einen funktionierenden Abmeldelink und eine gültige Postanschrift. Bulk-Sender, die an Gmail und Yahoo senden, brauchen außerdem Header für die One-Click-Abmeldung. Mehr dazu in Was weiterhin gilt, wenn ein Agent deine E-Mails versendet.
Für Transaktions-E-Mails entfallen einige Marketingregeln, diese Checkliste aber nicht. Ein Beleg mit totem Link wird trotzdem zum Support-Ticket.
Entferne, was E-Mail-Clients herausfiltern oder blockieren:
<script>-, <form>- und <iframe>-Elementedata:-URIsbackground-color als Fallback, damit der Text lesbar bleibt, wenn das Bild nicht lädtBeginne mit einem Doctype. Ohne ihn rendern manche Clients im Quirks-Modus, und Abstände verschieben sich.
Die E-Mail-Prüfung von Brew arbeitet diese Liste an folgenden Stellen ab:
POST /v1/emails/audit oder dem Tool audit_emailAlle Felder findest du in der Dokumentation zur Prüfung und in der API-Referenz.
Kostenlose Sofortprüfungen laufen automatisch für jede Regel, die nur das HTML braucht: Platzhalter, Größe, fehlende Alternativtexte und Bildmaße, Reihenfolge der Überschriften, lang und <title>, Länge von Betreff und Vorschautext, Merge-Tags ohne Fallback und blockiertes Markup.
Prüfung starten ergänzt die Prüfungen, die Netzwerkzugriff oder Urteilsvermögen brauchen:
Jede KI-Einschätzung ist so abgestimmt, dass ein gemeldeter Befund bei unseren eigenen E-Mails in mindestens 95 % der Fälle stimmt. Ein KI-Prüfer, der ständig falschen Alarm schlägt, ist schlimmer als gar keiner.
Eine vollständige Prüfung kostet 5 Credits. Ist eine erforderliche Prüfung nicht verfügbar, bekommst du eine kostenlose Teilprüfung ohne Score, denn ein Score, bei dem Prüfungen fehlen, wäre irreführend.
Jede Prüfung liefert einen Score von 0 bis 100 und einen Status: „bereit“, „Überprüfung nötig“ oder „nicht bereit“ (in der App „Bereit zum Versand“, „Überprüfung nötig“ und „Probleme gefunden“). Jeder Befund hat einen Schweregrad (Kritisch, Fehler, Warnung oder Info) und einen Beleg, etwa den HTTP-Status eines toten Links.
Der Score beginnt bei 100. Jeder kritische Befund kostet 20 Punkte, jeder Fehler 10, jede Warnung 3 und Info nichts. Pro Regel zählen nur die ersten drei Treffer.
Ein Beispiel: ein Button, der auf # verlinkt, ein Footer-Link, der 404 zurückgibt, zwei Bilder ohne Alternativtext, ein Betreff mit 68 Zeichen und Flexbox, die zwei Yahoo-Clients ignorieren.
| Befund | Schweregrad | Punkte |
|---|---|---|
| Button-Link ist ein Platzhalter | Kritisch | −20 |
| Footer-Link gibt 404 zurück | Fehler | −10 |
| Bild ohne Alternativtext (×2) | Warnung | −6 |
| Betreff über 60 Zeichen | Warnung | −3 |
| Flexbox von 2 Yahoo-Clients ignoriert | Info | 0 |
| Score | 61 |
Jeder kritische Befund und jeder Fehler bedeutet „nicht bereit“, Warnungen allein „Überprüfung nötig“. Behebst du die beiden Links, kommt diese E-Mail auf 91 Punkte, Status „Überprüfung nötig“. Ehrlich gesagt: Sie ließe sich problemlos versenden, und der Rest ist eine Minute wert.
Im Chat beheben übergibt Warnungen und alles Schwerwiegendere an den Brew-Agenten und führt danach die kostenlosen Sofortprüfungen für die Korrektur erneut aus.
Sie blockiert keine Versände. Bei kritischen Befunden verlangt der Versanddialog ein Trotzdem senden und protokolliert, dass die Prüfung übergangen wurde. Versände per API, MCP und Automatisierung melden die Befunde und laufen weiter. Das ist die richtige Voreinstellung. Manche E-Mails, die der Prüfung nicht gefallen, sollten trotzdem rausgehen, und ein QA-Tool, das Versände als Geiseln nimmt, wird abgeschaltet.
Sie schreibt dein HTML nicht um. Korrekturen sind ein separater Schritt, den du selbst anstößt.
Sie testet kein Inbox-Placement, erstellt keine Darstellungs-Screenshots und prüft nicht den Dunkelmodus. Für den Dunkelmodus öffne eine Test-E-Mail auf deinem Smartphone mit eingeschaltetem Dunkelmodus. So fällt dir das Logo auf, das auf Schwarz verschwindet.
Im Versanddialog 15 Minuten. Danach, oder wenn sich die E-Mail ändert, fordert dich der Bereich auf, sie erneut zu starten. Per MCP kannst du einen gespeicherten Bericht 7 Tage lang kostenlos erneut abrufen.
Nein. Die Prüfung bewertet nur die E-Mail selbst. Wo sie landet, hängt außerdem von der Reputation der Domain, der Authentifizierung und der Beschwerderate ab, wie der Leitfaden zur Zustellbarkeit erklärt.
Ja, über die API oder MCP. Sende emailHtml oder emailJsx statt einer Brew-E-Mail-ID und erhalte denselben Bericht, bevor die E-Mail in deinen ESP geht. Wenn du eine Vorlage aus der Galerie remixt und in deinen ESP exportierst, prüfe sie in Brew vor dem Export.
Alle mit Zugriff auf die Marke: Admins der Organisation und die Mitglieder, die der Marke hinzugefügt wurden. Eine Rolle mit reinem Lesezugriff gibt es in Brew nicht.
