Unsere Double-Opt-in-Bestätigungen landen im Spam, deshalb bestätigt die Hälfte unserer Anmeldungen nie
Die Willkommensmail kommt an, aber die Double-Opt-in-Bestätigung landet im Spam, viele Anmeldungen bestätigen deshalb nie und der Shop verliert sie. Ursache ist, dass die kontoweite Default From noch eine Adresse eines Gratis-Anbieters ist (eine @gmail.com oder @yahoo.com), die unter den Google-/Yahoo-Regeln von 2024 an der Authentifizierung scheitert, und dass die Bestätigung brandneue, kalte Empfänger trifft.
Die Lösung
Öffne in Klaviyo unten links das Konto-Menü und geh zu Settings > Account > Contact Information > Organization, dann setze Default From / Reply-To auf eine Adresse einer Domain, die dir gehört. Nimm nie eine @gmail.com, @yahoo.com oder eine andere Adresse eines Gratis-Anbieters, denn seit den Google-/Yahoo-Regeln vom Februar 2024 scheitert ein From eines Gratis-Anbieters an der Authentifizierung. Kombiniere das mit einer verifizierten eigenen Versanddomain (Settings > Domains), damit die Bestätigung DMARC-konform ausgerichtet ist, und beachte: Eine Änderung an Default From wirkt nur auf danach erstellte E-Mails, aktualisiere also auch die bestehende Bestätigungsvorlage. Achte darauf, dass diese Vorlage nicht zu textarm ist: ein nacktes „Zum Bestätigen klicken“ ohne echten Inhalt liest sich für Filter wie Phishing.
Unsere eigene Versanddomain stand auf aktiv, fiel dann still auf klaviyomail.com zurück, und die Mails landeten wieder im Spam
Eine eigene Versanddomain verifiziert sich, zeigt Active und trennt sich später von selbst, worauf Klaviyo stillschweigend auf die geteilte Domain klaviyomail.com zurückfällt, sodass die Zustellbarkeit Wochen später ohne erkennbare Ursache einbricht. Der übliche Auslöser ist Cloudflares Proxy (orange Wolke) auf den Klaviyo-Einträgen oder DNS-Drift wie ein fehlender Punkt am Ende eines CNAME-Werts, was die erneute Verifizierung periodisch scheitern lässt.
Die Lösung
Stell in Cloudflare jeden Klaviyo-DNS-Eintrag (die km-CNAME-Selektoren, den Tracking-CNAME und den TXT-Eintrag zur Verifizierung) auf DNS only (graue Wolke), nie auf Proxied, und lass das dauerhaft so, denn Klaviyo verlangt, dass der Proxy auch nach erfolgreicher Verifizierung aus bleibt. Gleiche Host und Wert exakt mit Settings > Domains ab und achte auf einen fehlenden Punkt am Ende eines CNAME-Werts, wegen dem manche Anbieter automatisch deine Root-Domain anhängen. Wenn sich das dynamische Routing (NS) partout nicht propagiert, wechsle ersatzweise auf das statische Setup (CNAME), auch wenn Klaviyo offiziell dynamisches Routing für die beste Leistung empfiehlt. Bestätige die Propagierung mit dnschecker.org oder MXToolbox und prüfe dann an einem echten Versand, dass die d=-Domain im DKIM deine eigene Subdomain ist und nicht klaviyomail.com.
Wir haben diese Liste auf Single-Opt-in umgestellt, dann haben Bots das Formular geflutet und unsere Bounce- und Beschwerderate ruiniert
Shop-Betreiber, die eine Liste auf Single-Opt-in setzen, berichten von Wellen gefälschter und vertippter Adressen, die ihre Anmeldeformulare und den Flow für abgebrochene Warenkörbe überschwemmen und Hard Bounces, Treffer in Spamfallen und Beschwerden auslösen, die die Domain-Reputation ruinieren. Klaviyo-Listen sind standardmäßig Double-Opt-in, deshalb trifft List-Bombing vor allem Listen, die bewusst auf Single-Opt-in stehen, und eingebettete oder selbst programmierte Formulare, bei denen Klaviyos eingebauter Bot-Schutz nicht vollständig greift.
Die Lösung
Aktiviere Double-Opt-in für die betroffene Liste wieder (Lists & segments > die Liste > Settings > Consent > Opt-in Process), damit unbestätigte Bot-Adressen nie angeschrieben werden; das ist die wirksamste Verteidigung, weil nur bestätigte Abonnenten aufgenommen werden. Beachte, dass Klaviyos eigener Schutz nur ein reaktives CAPTCHA für bereits verdächtige IPs ist, also erst nach Beginn eines Angriffs greift und eingebettete oder selbst programmierte Formulare nicht vollständig abdeckt; für proaktiven Schutz musst du Google reCAPTCHA plus ein Honeypot-Feld in das HTML deines eigenen Formulars einbauen. Zum Aufräumen baust du ein Segment aus Profilen, die E-Mail-Marketing empfangen dürfen, in den letzten 180 Tagen 3 oder mehr E-Mails bekommen haben und insgesamt null Öffnungen, null Klicks und null Bestellungen haben, und unterdrückst sie.
Apples falsche Öffnungen halten tote Abonnenten in unserer Liste, und unser Sunset-Flow löst nie aus
Da inzwischen rund die Hälfte aller Öffnungen von Apple Mail Privacy Protection kommt, laden Apples Server Klaviyos Tracking-Pixel schon bei der Zustellung vor und protokollieren eine Öffnung, ob jemand die E-Mail gelesen hat oder nicht. Das zerlegt jede Logik, die auf Öffnungen aufbaut: Segmente aktiver Kontakte füllen sich mit Geistern, Sunset-Flows, die auf „keine Öffnungen in 90 bis 180 Tagen“ hören, greifen bei Apple-Nutzern nie, und Win-back-Flows starten wegen einer Scheinreaktivierung, sodass inaktive Adressen weiter angeschrieben werden.
Die Lösung
Definiere Interaktion nicht mehr über Öffnungen. Klaviyo markiert jede Öffnung mit einer booleschen Eigenschaft namens Apple Privacy Open, die bei MPP-Öffnungen auf True steht, ergänze also jede Bedingung Opened Email um den Filter „where Apple Privacy Open equals False“ und baue Segmente aktiver Kontakte, Sunset-Trigger und Win-back-Flows um Klicks und echtes Kaufverhalten herum neu auf. Klicks kann Apple MPP viel schwerer fälschen, denn MPP lädt Bilder vor, keine Links. Endgültige Entscheidungen über eine Unterdrückung stützt du besser auf serverseitige Verhaltensereignisse (viewed-product, added-to-cart, placed-order), die über Klaviyos Track API laufen, statt auf ein Pixel im Posteingang, denn die sind wirklich immun gegen MPPs Vorabladen.
Ein Zustellbarkeits-Tool meldet deine geteilten Klaviyo-IPs als gelistet, und du hältst deinen Versand für kaputt
Absender lassen GlockApps oder ein ähnliches Tool laufen, sehen eine hohe Spam-Rate und führen sie auf Blacklist-Treffer bei Klaviyos geteilten Versand-IPs zurück, obwohl SPF, DKIM und DMARC alle bestehen und ihre eigene Domain sauber ist. Weil Klaviyo über einen geteilten Pool versendet, trägt fast immer eine dieser IPs einen Treffer von einem lauten Nachbarn, und derselbe Test zeigt bei anderen ESPs dasselbe Bild.
Die Lösung
Sieh nach, um welche Blacklist es geht, bevor du reagierst. Kleine wie Hostkarma oder all.s5h.net wirken sich nicht auf die Platzierung im Posteingang aus, und du kannst das prüfen, indem du deine Bounce-Nachrichten nach Erwähnungen davon durchsuchst. Treffer auf geteilten IPs sind Rauschen, das sich herausmittelt, weil echte Kampagnen über viele IPs laufen, wechsle also nicht auf eine dedizierte IP, solange du nicht dauerhaft deutlich über 50.000 bis 100.000 Mails pro Monat verschickst, denn wenig Volumen auf einer dedizierten IP baut eine schlechtere Reputation auf als ein gesunder geteilter Pool. Über die Platzierung bei Gmail entscheidet die Domain-Reputation, nicht die IP: Wenn deine Authentifizierung ausgerichtet und deine Domain sauber ist, stehst du gut da. Ein ehrliches Bild bekommst du, wenn du während einer echten Kampagne echte Postfächer mit anschreibst, statt dich auf die isolierte Momentaufnahme eines Testtools zu verlassen.