Att byta e-postleverantör ändrar mottagningsvärdnamn, certifikatägande och ibland reservbeteende. MTA-STS kan avslöja en osäker migreringsorder: DNS börjar marknadsföra en ny leverantör medan vissa avsändare fortfarande tillämpar en policy som endast tillåter den gamla.
Inventera båda sidor av migrationen
Referenser: RFC 8461 §4, RFC 8461 §8.2.
Registrera gamla och föreslagna MX namn, prioriteringar, adresser, STARTTLS beteende och certifikatidentiteter. Skaffa den nya leverantörens nuvarande routing- och MTA-STS -vägledning, verifiera sedan de exakta namnen i din egen planerade DNS ändring. En leverantörs varumärke eller ett gissat jokertecken är inte ett auktoritativt värdnamnsinventering.
Granska om policyn för HTTPS-värd eller upptäckts- DNS också är kopplad till den avgående leverantören. Om du flyttar mottagande e-post samtidigt som du av misstag avbryter policyvärden skapas ett andra misslyckande. Håll policypublicering, certifikatförnyelse och rapporteringsdestinationer uttryckligen ägda genom flytten.
Publicera en kompatibilitetspolicy först
Referenser: RFC 8461 §3.2, RFC 8461 §4, RFC 8461 §8.1.
Förbered en policy som tillåter nödvändiga gamla och nya mottagande värdar utan att ändra e-postdirigering ännu. Testa att båda grupperna matchar och att den nya gruppen klarar SMTP certifikat och STARTTLS kontroller. Publicera HTTPS-kroppen innan du ändrar upptäckts-id.
Tillåt ett övergångsintervall baserat på den tidigare publicerade policyn max_age, DNS TTL och observerat uppdateringsbeteende. Att sänka max_age vid migreringsögonblicket förkortar inte en policy som hämtats tidigare. Om möjligt, behåll en fungerande gammal rutt som uppfyller gamla cachade policyer medan den nya policyn distribueras. Lova inte att ändra id omedelbart uppdaterar alla avsändare.
Repetera de tre politiska staterna
Referenser: RFC 8461 §4.1.
Använd två syntetiska namn, mx.old.example och mx.new.example . Policy A tillåter endast gamla; policy B tillåter båda; policy C tillåter endast nya. Den förväntade kompatibilitetsmatrisen är A: gammal sant, nytt falskt; B: båda sanna; C: gammalt falskt, nytt sant. Den medföljande bounded offline fixturen kördes om för denna recension och registrerar dessa namnjämförelser, inte leverans.
Denna matris bevisar endast den namngivna policymedlemskapsrelationen. En realistisk repetition kräver också DNS svar, giltiga certifikat, STARTTLS , mottagarens acceptans och faktisk leverans av testmeddelanden. Dessa livemigreringstest utfördes inte för den här artikeln. Bevara deras framtida resultat separat istället för att behandla den lokala matrisen som en framgångsrik leverantörsövergång.
Flytta routing och gå i pension medvetet
Referenser: RFC 8461 §5.1, RFC 8461 §8.1.
Efter kompatibilitetsstadiet byter du MX routing genom den godkända ändringsprocessen. Observera leverans hos både leverantörer, avsändarfel, köer och TLS rapporter. Bekräfta företagsmottagare och återställningsvägar, inklusive lågvolymadresser som ett enda inkorgstest skulle missa. Håll den gamla tjänsten tillgänglig för den planerade överlappningen.
Först då begränsa policyn till den avsedda nya uppsättningen och meddela ett annat id. Bevara den tidigare texten och fundera över hur återställning skulle fungera med avsändare som cachelagrade policyn för endast ny. Om du lägger till den gamla MX bara i DNS återställs kanske inte leveransen för den kohorten. Stäng migreringen när rutt, policy och operativa bevis stöder pensionering, inte bara när DNS redigeraren visar den nya leverantören.
Bevarade historiska bevis och kvarvarande omfattning
Följande beskriver bevarade observationer från 7 november 2026, inte ett nätverksexperiment som återupptas för denna recension. Nyligen utförda offlinekontroller registreras separat.
Den utökade repetitionen kopplar medlemsmatrisen till publicering och livstidsstatus. A1 tillåter endast gammal och kan förbli giltig till logisk tid 1086700 när dess senaste modellerade hämtning beaktas. B2 tillåter båda leverantörerna; dess kropp hämtas via labbens HTTPS-slutpunkt efter att DNS id ändras. C3 tillåter endast ny. De modellerade B2- och C3-utgångstiderna, 1004200 och 1004500, inträffar före den äldre A1-bunden eftersom A1 använde en längre livslängd. Enbart marknadsföring av C3 eller byte av DNS vid B2-publiceringstillfället är alltså inte ett bevis på att alla gamla avsändare är redo. Spårningen visar faktisk lokal DNS /HTTPS plus explicit policy-state-aritmetik. Det testar inte leverantörens mottagares acceptans, offentliga DNS cachar, postleverans eller företagsadresstäckning; dessa förblir skärporten.