SMTP-Relay-Dienst — gemanagter SMTP für jede Anwendung
Ein gemanagtes SMTP-Relay, das mit jeder Anwendung funktioniert, die Standard-SMTP spricht. Statt Code-Änderungen reicht eine Konfiguration. Ideal für mittelständische Unternehmen mit etablierten ERP-, CMS- oder Legacy-Systemen, die zuverlässige Zustellbarkeit ohne Refactoring benötigen.
Was ist ein gemanagtes SMTP-Relay?
Ein SMTP-Relay ist ein Vermittlungs-Server, der E-Mails von Ihren Anwendungen entgegennimmt und an die Inboxen der Empfänger zustellt. Statt jede einzelne Anwendung mit eigener Versand-Infrastruktur, eigenen IPs und eigener Reputations-Verwaltung auszustatten, sprechen alle Ihre Systeme — ERP, WHMCS, Magento, SAP, Odoo, Java-Anwendungen, Legacy-Software — mit einem zentralen Relay-Server, der die operative Komplexität übernimmt: IP-Reputation, Authentifizierung (SPF/DKIM/DMARC), Bounce-Verarbeitung, FBL-Handling, Rate-Limiting nach Empfänger.
Unser SMTP-Relay-Dienst funktioniert mit jeder Anwendung, die Standard-SMTP nach RFC 5321 spricht — also praktisch jeder kommerziellen oder Open-Source-Software der letzten 25 Jahre. Die Migration besteht aus einer Konfigurationsänderung (SMTP-Server-Adresse, Port, Authentifizierungsdaten) statt einem Code-Refactoring.
Für wen ist SMTP-Relay die richtige Wahl?
Mittelständische Unternehmen mit etablierten Systemen
Sie betreiben SAP Business One, Microsoft Dynamics, Odoo oder eine andere ERP-Lösung, die SMTP-Versand nativ unterstützt. Statt Code-Änderungen reicht eine Konfiguration, um zuverlässige Zustellbarkeit zu erreichen — ohne Anpassungen an der Geschäftslogik.
Hosting-Provider und Webagenturen mit WHMCS/Plesk/cPanel
Der eingebaute SMTP von WHMCS, Plesk oder cPanel skaliert nicht für Hochvolumen-Versand. Ein externes Relay löst das Problem ohne komplette Infrastruktur-Umstellung — nur die SMTP-Konfiguration im Hosting-Panel ändern.
E-Commerce-Plattformen mit Magento, WooCommerce, Shopware
Magento, Shopware oder WooCommerce haben native SMTP-Unterstützung über Plugins (WP Mail SMTP, Magento SMTP, Shopware Mailer). Order-Bestätigungen, Versand-Updates und Rechnungen werden zuverlässig zugestellt, ohne dass Entwickler Email-Code anpassen müssen.
Java-/Spring- und PHP-Anwendungen mit JavaMail oder PHPMailer
Bestehende Anwendungen, die JavaMail, Spring Mail oder PHPMailer nutzen, müssen nur ihre SMTP-Konfiguration anpassen. Unsere Relay-Endpunkte unterstützen alle Standard-Authentifizierungs-Methoden (PLAIN, LOGIN, CRAM-MD5) und TLS 1.2/1.3.
Legacy-Systeme mit fixen SMTP-Konfigurationen
Legacy-Systeme aus den 2000er Jahren — alte ERP-Installationen, Healthcare-Software, Behörden-Anwendungen — haben oft hartcodierte SMTP-Konfigurationen ohne API-Möglichkeit. SMTP-Relay ist hier die einzige praktikable Modernisierungs-Option ohne Software-Umbau.
Operative Benachrichtigungen aus Monitoring-Systemen
Nagios, Zabbix, Prometheus AlertManager, Grafana — alle senden Alerts via SMTP. Statt diese kritischen Benachrichtigungen über die geteilte Hosting-IP zu schicken (mit dem Risiko von Spam-Filterung), ein dediziertes Relay mit guter Reputation.
Was unser Relay technisch leistet
Standard-SMTP nach RFC 5321
Vollständige Kompatibilität mit dem Standard. Funktioniert mit jeder Anwendung, die SMTP spricht.
TLS 1.2 und 1.3
Verschlüsselte Übertragung in beiden Richtungen. STARTTLS und implizites TLS unterstützt.
SMTP-AUTH-Methoden
PLAIN, LOGIN, CRAM-MD5 — kompatibel mit jeder gängigen Anwendung.
Custom DKIM
Signiert mit der Domain Ihres Unternehmens für korrektes DMARC-Alignment.
Per-Receiver-Throttling
Respektiert die Rate-Limits von Gmail, Microsoft, Yahoo und weiteren großen Empfängern.
FBL-Handling automatisiert
Verarbeitet Beschwerden via Feedback Loops von Microsoft, Yahoo und weiteren automatisch.
Konfigurationsbeispiele für gängige Systeme
WordPress mit WP Mail SMTP Plugin
SMTP-Host: smtp.authorizehosting.com
SMTP-Port: 587 (mit STARTTLS) oder 465 (implizites TLS)
Verschlüsselung: TLS
Authentifizierung: aktiviert
Benutzername: [Ihr Authorize-Username]
Passwort: [Ihr SMTP-Passwort]
Absender-Name: [Ihr Firmenname]
Absender-Email: noreply@ihre-domain.deMagento 2 mit SMTP-Erweiterung (Mageplaza, Mailgun-Replacement)
Stores → Configuration → Sales → Sales Emails → SMTP Configuration
Host: smtp.authorizehosting.com
Port: 587
Auth Type: Login
Username: [SMTP-Username]
Password: [SMTP-Passwort]
SSL Type: TLSJava mit JavaMail / Spring
spring.mail.host=smtp.authorizehosting.com
spring.mail.port=587
spring.mail.username=[SMTP-Username]
spring.mail.password=[SMTP-Passwort]
spring.mail.properties.mail.smtp.auth=true
spring.mail.properties.mail.smtp.starttls.enable=true
spring.mail.properties.mail.smtp.starttls.required=trueWHMCS
Setup → System Settings → General Settings → Mail Tab
Mail Type: SMTP
Host: smtp.authorizehosting.com
Port: 587
Username: [SMTP-Username]
Password: [SMTP-Passwort]
SMTP SSL Type: TLSMigration von Ihrem aktuellen Anbieter
Migration vom bestehenden SMTP-Anbieter (Mailgun, SendGrid, Amazon SES, oder dem geteilten SMTP Ihres Hosters) folgt einem standardisierten 5-Phasen-Prozess, der parallel zum Bestandsbetrieb läuft. Während der Migration sendet Ihr Unternehmen weiterhin über den alten Anbieter — wir bauen die neue Infrastruktur parallel auf, validieren sie mit Test-Versand, und schalten erst dann um, wenn vollständige Funktionsfähigkeit bestätigt ist.
Audit und DNS-Vorbereitung
Audit der aktuellen DNS-Konfiguration (SPF, DKIM, DMARC). Custom DKIM für die neue Infrastruktur generieren und in DNS publizieren. Custom Return-Path-CNAME setzen, falls zutreffend.
IP-Warming neue Infrastruktur
Geführtes Warming der dedizierten IPs mit kontrolliertem Volumen. Während dieser Phase sendet Ihre Produktion weiterhin über den alten Anbieter; nur Test-Volumen läuft über die neuen IPs.
Parallel-Versand-Test
Ein Teil des Produktions-Versands wird über die neuen IPs geleitet (10-20%) während der Großteil weiter über den alten Anbieter läuft. Vergleich der Zustellbarkeits-Metriken in beiden Pfaden.
Hauptmigration
Schrittweiser Übergang zu 50% / 75% / 100% des Volumens auf die neue Infrastruktur. Bei jedem Schritt 24-48h Validierung der Metriken bevor der nächste Schritt erfolgt.
Stabilisierung und Cleanup
Vollständiger Versand über die neue Infrastruktur. Alter Anbieter wird gekündigt nach 2 Wochen Stabilität. SPF wird angepasst um die alten IPs zu entfernen.
Rollback-Plan dokumentiert
Bei jedem Schritt ist der Rollback dokumentiert. Falls Probleme auftreten, kann jederzeit auf den alten Anbieter zurückgewechselt werden mit minimaler operativer Auswirkung.
Häufige Fragen zum SMTP-Relay-Dienst
Bereit, Ihren Versand auf eine zuverlässige Basis zu stellen?
Ein technisches Gespräch von 30-45 Minuten reicht meist aus, um die Migration aus Ihrer aktuellen Versand-Infrastruktur zu planen. Wir prüfen Ihre DNS-Konfiguration, identifizieren die migrationsrelevanten Systeme und schlagen einen konkreten 5-Phasen-Plan vor.