Versandschichten verglichen · SMTP-Relay, API, MTA

Versand-Layer verstehen — ESP, MTA, SMTP-Relay, Email API

E-Mail-Versand ist ein gestapelter Stack mit mehreren Layern: ESP (Email Service Provider), MTA (Mail Transfer Agent), SMTP-Relay und Email API. Diese Begriffe werden häufig synonym verwendet — obwohl sie unterschiedliche Funktionen haben. Diese Seite erklärt die strukturellen Unterschiede mit konkreten Architektur-Beispielen und hilft bei der richtigen Layer-Kombination für Ihren Anwendungsfall.

Operator kontaktieren Preise ansehen

Die Versand-Layer — ESP, MTA, Relay, API verstehen

E-Mail-Versand ist ein gestapelter Stack mit mehreren Layern, die häufig miteinander verwechselt oder synonym verwendet werden — obwohl sie unterschiedliche Funktionen haben. ESP (Email Service Provider), MTA (Mail Transfer Agent), SMTP-Relay und Email API beschreiben verschiedene Schichten des gleichen Versand-Prozesses. Diese Seite erklärt die strukturellen Unterschiede und hilft bei der Architektur-Wahl.

Die vier Layer im Überblick

Layer 1 — ESP

Email Service Provider

Eine ESP ist eine vollständige Plattform, die End-to-End-Versand abwickelt — typisch mit Web-Oberfläche für Listen-Verwaltung, Template-Editor, Reporting, Marketing-Automation. Beispiele: Mailchimp, Brevo, Klaviyo, ActiveCampaign. ESPs nutzen intern eigene MTAs oder API-Anbieter, abstrahieren aber diese Komplexität. Zielgruppe: Marketing-Teams, die Workflow-Tools brauchen.

Layer 2 — MTA

Mail Transfer Agent

Ein MTA ist die Software-Komponente, die für die tatsächliche Zustellung an Empfänger-Server verantwortlich ist. Beispiele: Postfix, Exim, KumoMTA, PowerMTA. MTAs implementieren das SMTP-Protokoll, übernehmen Bounce-Verarbeitung, IP-Reputations-Management. Zielgruppe: Engineering-Teams, die Versand-Infrastruktur selbst betreiben oder als gemanagten Service nutzen.

Layer 3 — SMTP-Relay

Standard-SMTP-Schnittstelle zu MTA

SMTP-Relay ist die Standard-Schnittstelle (RFC 5321), über die Anwendungen E-Mails an einen MTA übergeben. Praktisch jede Software seit den 1980er Jahren spricht SMTP. Ein gemanagter SMTP-Relay-Anbieter (wie Authorize Hosting, SMTP2GO) abstrahiert die MTA-Komplexität hinter einem stabilen SMTP-Endpunkt. Zielgruppe: Bestandssysteme mit etablierter SMTP-Integration.

Layer 4 — Email API

HTTP/JSON-Schnittstelle zu MTA

Email API ist eine HTTP-basierte Alternative zu SMTP. Die Anwendung führt POST-Aufrufe mit JSON-Payload aus, die API übergibt intern an einen MTA. Anbieter wie SendGrid, Mailgun, Postmark, Authorize Hosting bieten beide Schnittstellen. Zielgruppe: neu entwickelte Anwendungen mit event-getriebener Architektur und Webhook-Bedarf.

Wie die Layer zusammenarbeiten

Ein typisches Versand-Setup nutzt mehrere Layer in Kombination. Beispiel-Architekturen:

Architektur A — Klassisches Hosting

WordPress (Anwendung)
       ↓ SMTP
Postfix (eigener MTA)
       ↓ SMTP
Empfänger-Server (Gmail, Outlook, etc.)

Einfaches Setup ohne externe Anbieter. Vorteil: voller Kontrolle, keine externen Kosten. Nachteil: eigene IP-Reputation aufbauen, FBL-Handling selbst, Skalierung problematisch.

Architektur B — Bestandssystem mit Relay

SAP Business One (Anwendung)
       ↓ SMTP
Authorize SMTP-Relay (gemanagt)
       ↓ Internal
PowerMTA (gemanagter MTA)
       ↓ SMTP
Empfänger-Server

Bestandssystem nutzt seinen nativen SMTP, der Anbieter abstrahiert die MTA-Komplexität. Vorteil: keine Code-Änderung, professionelle Reputation und Skalierung. Nachteil: keine Webhook-Events.

Architektur C — SaaS mit Email API

SaaS-Produkt (Anwendung)
       ↓ HTTP/JSON
Authorize Email API (gemanagt)
       ↓ Internal
PowerMTA (gemanagter MTA)
       ↓ SMTP
Empfänger-Server
       ↓ Webhook
SaaS-Produkt (Event-Verarbeitung)

Event-getriebene Architektur mit Webhook-Loop. Vorteil: Echtzeit-Tracking, Idempotency, Marketing-Automation-Integration. Nachteil: Code-Anpassung bei Anbieter-Wechsel.

Architektur D — Marketing-Plattform via ESP

Marketing-Team (Nutzer)
       ↓ Web-UI
ESP (Brevo, Mailchimp, etc.)
       ↓ Internal
ESP-eigener MTA oder externes API
       ↓ SMTP
Empfänger-Server

Vollständige Plattform für Marketing-Workflows. Vorteil: kein Engineering-Aufwand, Workflow-Tools für nicht-technisches Personal. Nachteil: höhere Kosten bei Skalierung, Lock-in, weniger Kontrolle über Versand-Details.

Welche Layer-Kombination passt für welchen Anwendungsfall?

Anwendungsfall 01

Mittelständisches B2B-SaaS

Empfohlen: Email API für transactional + Marketing-Plattform via ESP für Sequenzen. Authorize Email API als Versand-Schicht, HubSpot oder ActiveCampaign als Marketing-Plattform. Saubere Trennung zwischen Versand-Infrastruktur und Marketing-Workflow.

Anwendungsfall 02

E-Commerce mit Magento oder Shopware

Empfohlen: SMTP-Relay für transactional aus dem CMS + ESP für Marketing-Newsletter. Authorize SMTP-Relay für Order-Bestätigungen, Brevo oder Mailchimp für Marketing-Kampagnen. Bewährte Architektur ohne Code-Anpassung.

Anwendungsfall 03

Hochvolumen-ESP für Endkunden

Empfohlen: Gemanagter PowerMTA als MTA-Layer + eigene API-Schicht für Endkunden. Authorize PowerMTA-as-a-Service als Versand-Schicht, eigene Plattform für Mandanten-Verwaltung und Reporting.

Anwendungsfall 04

Banking/Healthcare mit Compliance-Anforderungen

Empfohlen: Dedizierte Bare-Metal-Server mit eigenem MTA. Authorize Dedicated-Server-Tier für volle Kontrolle und audit-taugliche Compliance-Dokumentation. Compliance-Anforderungen schließen typisch Multi-Tenant-Lösungen aus.

Häufige Fragen

Brauchen wir einen ESP, wenn wir bereits Email API nutzen?

Hängt vom Workflow-Bedarf ab. Email API ist die Versand-Schicht — es übergibt E-Mails an die Empfänger. Ein ESP fügt Workflow-Funktionen hinzu (Sequenzen, A/B-Tests, Listen-Verwaltung). Wenn Sie diese Workflow-Funktionen brauchen aber bereits Versand-Infrastruktur haben, kann eine Marketing-Plattform wie Klaviyo oder ActiveCampaign mit Ihrer bestehenden API kombiniert werden.

Sind Anbieter wie SendGrid jetzt MTA, ESP oder etwas anderes?

SendGrid ist primär ein API-Layer mit eigenem MTA-Backend. SendGrid hat Marketing Campaigns dazugefügt und nähert sich damit dem ESP-Modell. Die Grenzen verschwimmen — moderne Anbieter sind häufig Hybrid-Konstrukte. Wir spezialisieren uns auf Layer 2-4 (MTA, Relay, API) ohne ESP-Layer; ESP-Funktionen sind Aufgabe spezialisierter Marketing-Plattformen.

Können wir mehrere Layer von verschiedenen Anbietern kombinieren?

Ja, sehr gängig. Typisches Setup: Authorize Hosting für Versand-Layer (API/Relay/MTA), HubSpot oder Klaviyo als ESP für Marketing-Workflows. Diese Trennung gibt Flexibilität — Sie können den ESP wechseln, ohne Versand-Infrastruktur zu ändern, und umgekehrt.

Welcher Layer ist am wichtigsten für Zustellbarkeit?

MTA-Layer und IP-Reputation. ESP-Workflows beeinflussen Zustellbarkeit nur indirekt (über Versand-Hygiene und Listen-Qualität). Die direkten Faktoren sind MTA-Konfiguration (Authentifizierung, Throttling, FBL-Handling) und IP-Reputation. Bei der Anbieter-Wahl ist das MTA-Layer das wichtigste Kriterium für Zustellbarkeit.

Welche Layer-Kombination passt zu Ihrer Architektur?

In einem 45-60-minütigen Gespräch analysieren wir Ihre aktuelle Versand-Architektur und schlagen die passende Layer-Kombination vor. Häufig: Email API für transactional + ESP für Marketing-Workflows. Bei Hochvolumen: gemanagter PowerMTA mit eigener API-Schicht.

Beratungsgespräch vereinbaren Preise ansehen

Für Anwendungen, die bereits Mail senden

Für Versand-Formate mit echtem Eisen

Wofür Software allein nicht reicht

Hamburger E-Commerce, Peak-Saison-Erholung