Bei der Migration eines E-Mail-Anbieters können zwei legitime Versandsysteme gleichzeitig aktiv bleiben. Das Sicherste SPF Der Plan beginnt mit den Nachrichten und Identitäten, die während dieser Überschneidung vorhanden sein werden. Das Hinzufügen des neuen Anbieters ist nur ein Schritt; Wenn man das alte zu früh entfernt oder es auf unbestimmte Zeit behält, entstehen unterschiedliche Probleme.
Inventarisieren Sie die Migrationsgrenze
Listen Sie Mitarbeiter-Mails, Bewerbungsbenachrichtigungen, Abrechnungen, automatisierte Antworten und Geräte auf, die über die alte Plattform weitergeleitet werden. Erfassen Sie für jeden Fluss die tatsächliche Umschlagdomäne und die ausgehende Route. Die sichtbare Absenderadresse ist nicht unbedingt die SPF Identität. Benutzen Sie die E-Mail-Identitätskette um diese Felder getrennt zu halten.
Fragen Sie den neuen Anbieter nach den aktuellen Anweisungen für Ihren Mandanten und Ihre Konfiguration. Einige Dienste verwenden ihre eigene Umschlagdomäne, sofern kein benutzerdefinierter Rückpfad konfiguriert ist. Durch das Hinzufügen eines Include zu Ihrer Stammdomäne wird diese Identität nicht automatisch geändert. Erfinden Sie keine Anbieterwerte und verwenden Sie die Einrichtung eines anderen Mandanten nicht wieder.
Entwerfen Sie die Überschneidungsrichtlinie
Bewahren Sie ein zutreffendes auf SPF Eintrag bei jedem ausgewerteten Eigentümernamen. Veröffentlichen Sie die alten und neuen Richtlinien nicht als separate konkurrierende SPF Einträge. RFC 7208 §3.2 Und RFC 7208 §4.5 Definieren Sie die Auswahlbeschränkung.
Erstellen Sie einen Kandidaten, der die noch erforderlichen Berechtigungen enthält. Bewerten Sie den kombinierten Abhängigkeitsbaum, da zwei einzeln akzeptable Konfigurationen einen problematischen kombinierten Pfad ergeben können. Testen Sie die tatsächlich verwendeten Umschlagdomänen und IP-Familien. Vermeiden Sie es, lediglich Top-Level-Includes zu zählen oder davon auszugehen, dass ein Anbietername im DNS die richtige Konfiguration beweist.
Notieren Sie das beabsichtigte nicht übereinstimmende Endergebnis und stellen Sie sicher, dass es sich nicht versehentlich geändert hat. Eine Migration ist kein Grund für die Erteilung einer Allgemeinerlaubnis. Halten DKIM Einrichtung und DMARC Ausrichtung Überprüfung im Plan als separate Arbeitsabläufe.
Üben Sie den Cutover
Bei dieser beispielhaften Migration wird die Post der Mitarbeiter am Montag verschoben, während eine Rechnungsanwendung bis Freitag auf dem alten Relay verbleibt. Eine Aufhebung der alten Genehmigung am Montag würde den Bewerbungsplan außer Acht lassen. Umgekehrt würde eine endgültige Beibehaltung aufgrund der einmal verwendeten Rechnungen die Stilllegungsentscheidung vermeiden. Der Plan benötigt einen separaten Besitzer und ein Ausstiegskriterium für diesen Fluss.
Behalten Sie vor der Produktion den alten DNS Wert, den vorgeschlagenen Überlappungswert und die Wiederherstellungsentscheidung bei. Überprüfen Sie frühere TTLs und das erwartete Caching-Verhalten, ohne zu versprechen, dass sich alle Empfänger gleichzeitig ändern. Testen Sie den neuen Weg mit gewöhnlichen Nachrichten und wichtigen automatisierten Varianten, nicht nur mit dem internen Verifizierungsbildschirm eines Anbieters.
Überprüfen Sie die Beweise des Empfängers
Sammeln Sie eine Empfangsprobe von jeder relevanten Route und überprüfen Sie das Authentifizierungsergebnis des vertrauenswürdigen Empfängers, die ausgewertete Umschlagidentität und die sichtbare Absenderdomäne. RFC 8601 erklärt die Vertrauensgrenze für Authentication-Results; Ein außerhalb dieser Grenze eingefügter Header ist kein unabhängiger Beweis.
Ein reiner SPF Durchgang stellt keine DMARC Ausrichtung her. RFC 9989 Abschnitt 4.4 verknüpft authentifizierte Identitäten mit der Autorendomäne. Bestätigen Sie die ausgerichtete Authentifizierung der neuen Route, anstatt eine erfolgreiche DNS Suche als Abschluss zu betrachten. Die Zustellung kann weiterhin von anderen Empfängerrichtlinien abhängen.
Entfernen Sie die alte Autorität absichtlich
Nutzen Sie die Bestätigung des Anwendungseigentümers, das Senden von Protokollen und repräsentative Beobachtungen, um zu entscheiden, wann die alte Route nicht mehr benötigt wird. Berücksichtigen Sie Wiederholungsversuche in der Warteschlange und ungewöhnliche geplante Jobs. Es gibt keine einheitliche Wartezeit, die beweist, dass jede Organisation die Nutzung eines Anbieters eingestellt hat.
Bereiten Sie eine zweite Richtlinienänderung vor und genehmigen Sie sie, durch die nur der veraltete Bereich entfernt wird. Wiederholen Sie positive und negative Bewertungen und überprüfen Sie die verbleibenden Flüsse. Behalten Sie einen Rollback-Plan bei, der berücksichtigt, ob der alte Dienst noch vorhanden ist. Ein gespeicherter DNS Eintrag kann ein gekündigtes Sendekonto nicht wiederherstellen.
Schließen Sie die Migration ab, wenn Inventar, DNS , Tests empfangener Nachrichten und Eigentumseinträge übereinstimmen. Bewahren Sie den Rücktrittsnachweis auf, damit der nächste Administrator weiß, warum der alte Anbieter entfernt wurde, anstatt ihn als Reaktion auf einen nicht damit zusammenhängenden Fehler erneut hinzuzufügen.
DNS -Hintergrund: RFC 1035 Abschnitt 3.2.1 definiert die TTL für Ressourcendatensätze; RFC 2308 §5 deckt negatives Caching ab; RFC 8767 §4 Aktualisiert die TTL-Semantik und ermöglicht veraltete Verwendung, wenn die autorisierende Aktualisierung fehlschlägt. Diese beschreiben ausnahmsweise DNS Verhalten und keine universelle Abschlusszeit.
Notieren Sie die nächste Entscheidung
Verfolgen Sie Mitarbeiter und Rechnungen als separate Zeilen: Eigentümer, aktuelle Route, tatsächliche Umschlagdomäne, Überlappungsanforderung, Nachweis für neue Route und Ruhestandsbedingung. Der Personalabbau berechtigt nicht zum Entfernen der Rechnungsabhängigkeit. Wenn das alte Konto gekündigt wird, markieren Sie Routing-Rollback als nicht verfügbar, auch wenn ein alter DNS Wert gespeichert ist. Hierbei handelt es sich um einen vorgeschlagenen Abnahmedatensatz, nicht um eine durchgeführte Migration.