Inxmail for TYPO3

Inxmail ist die Enterprise-Newsletter-Plattform, die TYPO3-Redaktionen nativ anbindet

Unternehmen mit mehr als 50.000 Newsletter-Empfängern, strengen Compliance-Anforderungen und einem bestehenden TYPO3-Webauftritt stehen vor einer konkreten Entscheidung: Mailchimp mit US-Datenverarbeitung und GDPR (UK: UK GDPR)-Risiko oder eine deutsche Lösung, die sich direkt in die bestehende Content-Infrastruktur integriert. Inxmail Professional ist diese Lösung. Server in Deutschland, zertifizierte Datenverarbeitung, und eine TYPO3-Extension, die Subscriber-Listen, Templates und Kampagnen direkt aus dem CMS heraus steuert.

Die TYPO3-Extension synchronisiert Anmeldungen bidirektional: Neue Subscriber aus TYPO3-Formularen landen automatisch in Inxmail-Listen, Abmeldungen in Inxmail werden zurück nach TYPO3 gespiegelt. Für Marketing-Teams bedeutet das: Eine Datenquelle, keine manuellen Exporte, kein Risiko veralteter Listen. In der Praxis eliminiert das den häufigsten Fehler bei Newsletter-Versand: den Versand an eine veraltete Empfängerliste, die bereits abgemeldete Kontakte enthält.

Typical use cases decken B2B-Newsletter, Transaktionsmails und Event-Kommunikation ab

Das Hauptszenario ist der klassische B2B-Newsletter für Unternehmen mit 10.000 bis 500.000 Empfängern. Die Redaktion pflegt Inhalte in TYPO3, die Extension überträgt Teaser und Links automatisch in Inxmail-Templates. Marketing-Verantwortliche segmentieren die Empfänger nach Branche, Region oder Interesse und versenden zielgruppenspezifische Varianten. Öffnungsraten und Klickdaten fliessen über die API zurück ins TYPO3-Backend, sodass die Redaktion die Performance einzelner Beiträge sehen kann.

Zweites Szenario: Transaktionsmails, die durch Nutzeraktionen auf der Website ausgelöst werden. Eine Registrierungsbestätigung, ein Download-Link oder eine Bestellbestätigung wird nicht über den lokalen Mailserver verschickt, sondern über die Inxmail-Infrastruktur mit garantierter Zustellrate. SPF, DKIM und DMARC sind in Inxmail vorkonfiguriert, was die Zustellbarkeit gegenüber einem Standard-PHP-Mailer deutlich verbessert.

Drittes Szenario: Event-Kommunikation für Unternehmen, die regelmässig Messen, Webinare oder Konferenzen veranstalten. Die Einladung, Reminder und Follow-up-Mails werden als Trigger-basierte Kampagnen in Inxmail konfiguriert und durch Events in TYPO3 ausgelöst, etwa durch eine Anmeldung über ein powermail-Formular. Die Trigger-Logik erlaubt auch komplexere Sequenzen: Einladung vier Wochen vorher, Erinnerung eine Woche vorher, Teilnahmebestätigung am Vortag und Feedback-Anfrage zwei Tage danach.

Technical architecture connects TYPO3-Frontend-Formulare mit der Inxmail-REST-API

Die Extension nutzt die Inxmail REST-API für die Kommunikation zwischen TYPO3 und Inxmail Professional. Im Kern besteht die Integration aus drei Modulen: einem Subscriber-Sync-Service, einem Template-Sync-Modul und einem Kampagnen-Trigger.

Der Subscriber-Sync läuft über einen Scheduler-Task, der in konfigurierbaren Intervallen (typisch: alle 5 bis 15 Minuten) neue Anmeldungen, Änderungen und Abmeldungen zwischen TYPO3 und Inxmail abgleicht. Die Sync-Richtung ist konfigurierbar: unidirektional (TYPO3 zu Inxmail) oder bidirektional. Bei bidirektionalem Sync werden Konflikte über Timestamps gelöst, wobei der neuere Datensatz gewinnt.

Das Template-Sync-Modul überträgt TYPO3-Seitenbereiche als Newsletter-Inhalte. Redakteure markieren Content-Elemente im TYPO3-Backend als “Newsletter-fähig”, und die Extension rendert diese Elemente in ein Inxmail-kompatibles HTML-Template. Das erspart die doppelte Pflege von Website-Content und Newsletter-Content.

Die Authentifizierung erfolgt über API-Keys, die im TYPO3-Extension-Manager konfiguriert werden. Alle API-Calls laufen über HTTPS, und die Extension loggt jeden Sync-Vorgang in eine dedizierte Log-Tabelle, was für Compliance-Audits relevant ist. Die Log-Daten enthalten Zeitstempel, Anzahl synchronisierter Records, Fehler und Warnungen, sodass bei einem Audit nachgewiesen werden kann, wann welche Daten übertragen wurden.

Common problems involve Sync-Konflikte, Template-Rendering und API-Rate-Limits

Das dominierende Supportthema ist der Sync-Konflikt bei bidirektionaler Synchronisation. Wenn ein Subscriber sowohl in TYPO3 als auch in Inxmail gleichzeitig geändert wird, kann es zu Dateninkonsistenzen kommen. Die Lösung: Klare Sync-Richtung definieren. In 90% der Fälle ist TYPO3 die führende Quelle für Stammdaten, Inxmail die führende Quelle für Engagement-Daten (Öffnungen, Klicks, Bounces).

Zweites Problem: HTML-Rendering-Unterschiede zwischen TYPO3-Frontend und E-Mail-Client. Ein Content-Element, das auf der Website korrekt dargestellt wird, kann in Outlook oder Gmail anders aussehen. Die Extension übersetzt zwar TYPO3-HTML in Inline-CSS für E-Mail-Kompatibilität, aber komplexe Layouts mit Flexbox oder Grid müssen für E-Mail-Clients vereinfacht werden. Wir empfehlen, Newsletter-Templates separat zu testen, idealerweise mit einem Tool wie Litmus oder Email on Acid.

Drittes Problem: API-Rate-Limits bei grossen Sync-Vorgängen. Wer 100.000 Subscriber auf einmal synchronisiert, kann das API-Limit von Inxmail erreichen. Die Lösung: Batch-basierter Sync mit konfigurierbarer Paketgrösse (empfohlen: 500 Records pro API-Call) und exponentielles Backoff bei Rate-Limit-Responses.

TYPO3 v12 wird über die offizielle Extension unterstützt, v13 requires Prüfung

Inxmail pflegt die TYPO3-Extension aktiv, da der TYPO3-Markt ein relevanter Vertriebskanal für Inxmail Professional ist. Die aktuelle Version unterstützt TYPO3 v11 und v12. Beim Upgrade von v10 auf v12 müssen vor allem die Scheduler-Task-Konfigurationen angepasst werden, da TYPO3 v12 die Scheduler-API geändert hat. Die API-Authentifizierung und der Subscriber-Sync bleiben stabil.

Für TYPO3 v13 liegt noch kein offizielles Release vor. Unternehmen, die ein v13-Upgrade planen, sollten die Verfügbarkeit frühzeitig mit Inxmail abstimmen, da Enterprise-Newsletter-Integrationen zu den kritischsten Abhängigkeiten bei einem CMS-Upgrade gehören. Als Zwischenlösung kann die Integration über einen Custom Middleware-Layer realisiert werden, der die Inxmail-API direkt anspricht, ohne die Extension zu verwenden. Gosign hat diese Lösung für Kunden umgesetzt, die auf v13 migrieren wollten, bevor die offizielle Extension verfügbar war. Der Custom-Layer ist zudem wartungsärmer, weil er nur die tatsächlich genutzten API-Endpoints anspricht und keine ungenutzten Features mitschleppt.