SMTP-Relay-Migration für wachsende DACH-Teams planen

SMTP-Relay-Migrationen bei wachsenden DACH-Teams sind häufig — vom geteilten Hosting-SMTP zu spezialisierter Infrastruktur, vom alten Anbieter zu einem moderneren. Schlecht geplante Migrationen führen zu Versand-Ausfällen oder Reputations-Verlust.

Wann eine SMTP-Migration ansteht

• Wachstum: aktuelle Infrastruktur kann steigendes Volumen nicht handhaben
• Anbieter-Probleme: Reputations-Probleme, Pricing-Änderungen, Feature-Lücken
• Compliance-Anforderungen: DSGVO, Schrems II, branchenspezifisch
• Cost-Optimierung: bei wachsendem Volumen attraktivere Tarif-Modelle
• Strategische Konsolidierung: mehrere Anbieter auf einen reduzieren
• M&A: nach Akquisition Konsolidierung der Versand-Infrastrukturen

Pre-Migration-Audit

1. Versand-Quellen identifizieren. ERP, CRM, Marketing-Plattform, E-Commerce, eigene Anwendungen, Hosting-Plattform-Mails, Monitoring-Tools, Buchhaltungs-Software, externe Dienstleister.

2. Volumen pro Quelle messen. Über 30-90 Tage messen.

3. Versand-Patterns dokumentieren. Konstant oder bursty? Tageszeit-abhängig?

4. Empfänger-Profile. B2B vs B2C, EU vs international, Gmail vs Microsoft.

5. Aktuelle DNS-Konfiguration. SPF, DKIM, DMARC, MX.

6. Aktuelle Reputations-Lage. Gmail Postmaster, Microsoft SNDS, Blacklists.

7. Compliance-Status. AVV mit aktuellem Anbieter, Verarbeitungsverzeichnis.

Migrations-Strategie wählen

Strategie A: Big Bang Cutover

An einem Stichtag alle Anwendungen umstellen. Vorteile: schnell. Nachteile: hohes Risiko. Nur bei sehr kleinen Setups.

Strategie B: Phased Rollout

Anwendungen schrittweise migrieren. Standard-Ansatz für mittelständische Migrations.

Strategie C: Parallel Run

Beide Anbieter parallel mit kontrollierter Lastverteilung. Niedrigstes Risiko, aufwendigste Logistik.

Standard 5-Phasen-Plan für Phased Rollout

Phase 1 (Wochen 1-2): Vorbereitung. Audit, neuer Anbieter ausgewählt, Test-Account, DNS vorbereitet (TTL niedrig, neue DKIM-Schlüssel).

Phase 2 (Wochen 3-5): IP-Warming und Pilot. Warming startet, Pilot-Migration einer niedrig-volumigen Anwendung.

Phase 3 (Wochen 6-8): Schrittweise Migration. Nicht-kritische Anwendungen migriert, pro Anwendung 2-3 Tage Monitoring.

Phase 4 (Wochen 9-11): Kritische Anwendungen. transactional, Billing, Account-Lifecycle. Alte Infrastruktur als Backup-Pfad.

Phase 5 (Wochen 12-14): Stabilisierung und Cleanup. 2 Wochen Stabilisierung, SPF bereinigt, DKIM-Schlüssel des alten Anbieters entfernt nach 4 Wochen, Anbieter-Vertrag gekündigt.

DNS-Strategie während der Migration

Niedrige TTL vor Migrations-Start

2-4 Wochen vor Migration TTL auf 300 Sekunden reduzieren.

SPF mit beiden Anbietern

# Während Migration
ihr-unternehmen.de. IN TXT "v=spf1 include:_spf.alter-anbieter.com include:_spf.authorizehosting.com -all"

# Nach Migration
ihr-unternehmen.de. IN TXT "v=spf1 include:_spf.authorizehosting.com -all"

DKIM-Schlüssel parallel

Beide DKIM-Selektoren publiziert während Migration. Mails aus altem System haben alten Selektor, neue aus neuem System haben neuen Selektor.

DMARC nicht ändern während Migration

Wenn aktuell p=quarantine oder p=reject, während Migration nicht zu p=none wechseln.

Häufige Migrations-Fehler

Fehler 1: Unvollständiger Audit. Versand-Quelle übersehen, sendet weiter über alten Anbieter.

Fehler 2: Zu schnelle Migration. Alle Anwendungen in einer Woche umstellen.

Fehler 3: IP-Warming übersprungen. Reputation-Probleme garantiert.

Fehler 4: SPF zu früh bereinigt. Anwendung sendet noch über alten Anbieter, Mails scheitern.

Fehler 5: Kein Rollback-Plan.

Fehler 6: Verträge zu früh gekündigt.

Was bei Authorize Hosting automatisiert ist

• Migrations-Audit als Bestandteil des Onboardings (kostenfrei)
• IP-Warming geführt mit kontrollierter Volumen-Erhöhung
• DKIM-Schlüssel-Setup und DNS-Konfigurations-Empfehlung
• Konfigurations-Beispiele für DACH-Anwendungen
• Begleitung während Phased Rollout
• Post-Mortem-Dokumentation für Compliance-Audits

Standard-Migrations-Dauer: 8-14 Wochen für mittelständische Setups, 16-20 Wochen bei sehr komplexen.