Postfach übertragen: sichere DNS-Umstellung für E-Mail

Postfach zu einem neuen E-Mail-Anbieter übertragen: Anleitung zur DNS-Umstellung

Ob ein Anbieterwechsel reibungslos verläuft oder 48 Stunden Ausfall verursacht, hängt maßgeblich von Ihrer DNS-Strategie ab. Eine falsch konfigurierte TTL oder ein vergessenes SPF-include kann zu endgültigen Unzustellbarkeitsmeldungen und Geschäftsausfällen führen.

Hier ist kein Improvisieren gefragt, sondern eine genaue Abfolge technischer Schritte. Dieser Leitfaden zeigt, wie Sie Postfachinhalte sicher übertragen, Verbreitungszeiten berücksichtigen, SPF, DKIM und DMARC zusammenführen und Nachrichten ohne vermeidbare Verluste zum neuen Anbieter leiten.

Die eigentliche Datenmigration wird ausführlich im Leitfaden zur IMAP-Synchronisierung erklärt.

Warum die DNS-Verbreitung bei einer Postfachübertragung nicht sofort erfolgt

DNS ist ein verteiltes Cache-System. Nach einer Änderung sind Sie darauf angewiesen, dass alle rekursiven Resolver, darunter DNS-Server von Internetanbietern, Googles 8.8.8.8 und lokale Router, Ihren Time-to-Live-Wert (TTL) beachten.

Steht die TTL auf dem üblichen Wert von 86,400 Sekunden (24 Stunden), kann die Umstellung einen Tag lang zu geteilter Zustellung führen. Manche Nachrichten landen im neuen, andere im alten Postfach.

Nachzügler und negatives Caching

Zwei wenig sichtbare Faktoren verursachen bei Postfachübertragungen regelmäßig Probleme:

• Nachzügler: Selbst bei niedriger TTL ignorieren etwa 1 bis 5% der weltweiten Resolver Werte unter 60 Minuten. Rechnen Sie deshalb nach der Umstellung ungefähr eine Stunde lang mit Restverkehr zum alten Anbieter.
• Negatives Caching (SOA): Wird ein Eintrag abgefragt, bevor er existiert, etwa ein neuer DKIM-Selektor zu früh, wird die NXDOMAIN-Antwort anhand der minimalen TTL des SOA-Eintrags zwischengespeichert, oft für 1 Stunde. Der gültige Eintrag kann dadurch auch nach seiner Veröffentlichung vorübergehend unsichtbar bleiben.

Phase 1: 48 Stunden vor der Umstellung

Ändern Sie die MX-Einträge noch nicht. Bereiten Sie zuerst die Umgebung auf den Wechsel vor.

Schritt 1: TTL-Werte senken (48 Stunden vorher)

Suchen Sie Ihre MX-, SPF- (TXT) und DMARC-Einträge. Senken Sie deren TTL auf 300 Sekunden (5 Minuten).

Dadurch wird das mögliche Verbreitungsfenster verkürzt. Viele Resolver übernehmen die Änderung schneller als bei einer TTL von 24 Stunden, aber eine weltweite Aktualisierung innerhalb von 5 Minuten ist nicht garantiert.

Schritt 2: SPF zusammenführen (24 Stunden vorher)

SPF (RFC 7208) legt fest, welche IP-Adressen in Ihrem Namen senden dürfen. Während des Übergangs müssen beide Anbieter gleichzeitig autorisiert sein.

Die Falle: SPF erlaubt höchstens 10 DNS-Abfragen. Zwei Anbieter zusammenzuführen, etwa Google Workspace und TrekMail, kann diese Grenze überschreiten.

Die Lösung: Vereinfachen Sie den Eintrag nur mit einem unterstützten Verfahren, das IP-Änderungen laufend nachführt. Wer verschachtelte include:-Anweisungen lediglich durch direkte ip4:-Mechanismen ersetzt, riskiert veraltete Adressen.

Beispiel für einen Übergangseintrag:

Wenn Sie TrekMail mit eigenem SMTP verwenden, etwa Amazon SES oder SendGrid, nehmen Sie stattdessen deren SPF-Einträge auf.

Schritt 3: DKIM vorab veröffentlichen

DKIM verwendet Selektoren wie google._domainkey. Erstellen Sie beim neuen Anbieter Schlüssel mit einem eindeutigen Selektor, etwa tm1._domainkey. Verwenden Sie einen Selektornamen nie erneut. Neue Selektoren lassen sich Tage im Voraus veröffentlichen, ohne mit dem alten Anbieter in Konflikt zu geraten.

Schritt 4: DMARC vorübergehend lockern

Wenn Ihre DMARC-Richtlinie p=reject oder p=quarantine lautet, ändern Sie sie mindestens 24 Stunden vorher in p=none. In den ersten Stunden können bei einer noch unvollständigen Konfiguration Authentifizierungsfehler auftreten. Mit p=none werden Fehler in RUA-Berichten erfasst, ohne allein durch diese DMARC-Richtlinie abgewiesen zu werden. Der Google-Leitfaden zur DMARC-Einrichtung erläutert die richtige Konfiguration.

Phase 2: Durchführung der Umstellung

Die TTL-Werte sind niedrig und die Authentifizierungseinträge zusammengeführt. Jetzt kann das Routing zum neuen Host wechseln.

Schritt 1: Autoritative und rekursive Abfrage vergleichen

Prüfen Sie neue Einträge zuerst beim autoritativen Nameserver und erst danach über öffentliche Resolver:

Schritt 2: MX-Einträge aktualisieren

Fügen Sie die neuen MX-Einträge nach Möglichkeit zuerst hinzu und prüfen Sie sie, bevor Sie die alten löschen, oder führen Sie die Änderung atomar aus. Für TrekMail:

Lassen Sie die TTL vorerst bei 300 Sekunden.

Schritt 3: Cache leeren und prüfen

Leeren Sie den lokalen DNS-Cache, unter Windows mit ipconfig /flushdns, unter macOS mit sudo dscacheutil -flushcache. Führen Sie dig erneut aus. Dadurch wird nur der lokale Cache geleert; ob neue MX-Einträge sichtbar sind, hängt weiterhin vom abgefragten Resolver ab.

Phase 3: Stabilisierung nach der Umstellung

Fehler bei der Mandantenzuordnung beachten (550 5.7.64)

Dieser Fehler tritt bei einem Wechsel zu Microsoft 365 oder ähnlichen Paketen häufig auf. Ist Ihre Domain im internen Verzeichnis des Ziels noch nicht vollständig eingerichtet, kann der Dienst Nachrichten mit „Relay Access Denied“ ablehnen. Vergewissern Sie sich vor der MX-Änderung, dass der Domainstatus beim neuen Anbieter „Verified“ oder „Healthy“ lautet.

DMARC-Berichte überwachen (72 Stunden)

Beobachten Sie die RUA-Berichte drei Tage lang:

• Erfolg: Verkehr von den IP-Adressen des neuen Anbieters besteht SPF- und DKIM-Prüfungen.
• Fehler: Legitime Absender wie Abrechnungs- oder Marketingdienste bestehen die Authentifizierung nicht. Korrigieren Sie deren SPF- oder DKIM-Konfiguration zeitnah.

Aufräumen (72 Stunden danach)

Sobald sich der Verkehr stabilisiert hat:

1. Entfernen Sie das include: des alten Anbieters erst aus dem SPF-Eintrag, wenn dieser keine Nachrichten mehr sendet.
2. Entfernen Sie alte DKIM-CNAME- und TXT-Einträge erst nach einem ausreichenden Zeitfenster für zuvor signierte Nachrichten.
3. Erhöhen Sie die TTL wieder auf 3,600s (1 Stunde) oder 86,400s (24 Stunden).
4. Aktivieren Sie die DMARC-Durchsetzung mit p=quarantine oder p=reject, nachdem die Berichte keine legitimen Fehlklassifizierungen mehr zeigen.

Die Checkliste zur Postfachübertragung im Überblick

TrekMail vereinfacht die Postfachübertragung

Manuelle DNS-Verwaltung ist fehleranfällig. Schon ein Syntaxfehler in einem TXT-Eintrag kann die gesamte SPF-Richtlinie ungültig machen.

Für kleine Unternehmen

TrekMail bietet eine DNS-Zustandsprüfung in Echtzeit. Statt den Abschluss der Verbreitung zu erraten, fragt das Dashboard Ihre autoritativen Nameserver ab und prüft MX, SPF sowie DKIM-Einträge gegen die erforderlichen Vorgaben. Erkennbare Syntaxfehler werden markiert, sodass sie vor der Umstellung behoben werden können.

Mehr dazu erfahren Sie unter E-Mail für die eigene Domain einrichten.

Für Agenturen

Bei mehr als 50 Domains ist Standardisierung unerlässlich. Mit TrekMail können Sie eine einheitliche DNS-Vorlage auf alle Kundenbereiche anwenden. In den Tarifen Starter und Agency übernimmt Managed SMTP IP-Reputation und Zustellheader. Komplexe SPF-Vereinfachung und eigene IP-Warm-up-Pläne sind dafür in der Regel nicht erforderlich.

Erfahren Sie, wie E-Mail-Hosting für mehrere Domains Agenturen unterstützt.

Alle kostenpflichtigen Tarife enthalten eine 14-tägige kostenlose Testphase, für die eine Karte erforderlich ist. Für den Nano-Tarif ist keine Karte nötig.

Fazit

Bei der Übertragung eines Postfachs liegt das größte Risiko in der DNS-Umstellung. Senken Sie die TTL frühzeitig, führen Sie die Authentifizierungseinträge zusammen, ändern Sie MX in einem Wartungsfenster und beobachten Sie die DMARC-Berichte 72 Stunden lang. Das ist der grundlegende Ablauf.

Wenn Sie die manuelle DNS-Koordination vermeiden möchten, können Sie TrekMail kostenlos testen und die Einträge über das Dashboard prüfen lassen.