Verify routing before closure

Video transcript

1. 0:00–0:06

   Confirm destination readiness • Recipients, access and required senders must work. • Recipients + licences • Access + delegation • Required sending paths • Unanswered blocking check? Postpone the switch.

   Before changing incoming routing, verify destination recipients, aliases, shared-address mapping and required licences. Observe user access, delegation and required staff, website and application sending paths. Record DNS authority, current values, authorised editor, approver, fallback contact and recovery owner. A blocking row with no evidence postpones the switch. Keep support instructions available through an agreed channel that still works if email is unavailable.

2. 0:06–0:12

   Record the DNS change • A shorter TTL does not erase earlier cached answers. • New DNS answer • Earlier cached answer • Actual delivery • Verify both • Earlier answers can remain • Observe actual delivery

   The approved diagram keeps a new DNS answer and an earlier cached answer on separate observed delivery paths. Lowering TTL does not erase an answer cached under an earlier value. Record the old TTL, preparatory change and MX update time, then inspect authoritative and relevant external answers and actual mail behaviour. One lookup and one delivered message do not prove universal convergence. Do not invent fallback MX values or combine unrelated website and nameserver changes.

3. 0:12–0:18

   Test the real mail paths • Check both directions and shared replies. • External sender • Observe employee inbox • Employee sender • Observe external receipt • Authorised delegate • Check shared reply

   Test external-to-employee delivery, employee-to-external delivery and an authorised shared-address reply separately. Save the actual observed destination, time, sender, recipient and relevant result using harmless agreed test content. Also cover aliases, website or application notices, normal clients and late source mail where required. A sent-message screenshot is not receipt evidence. Incoming MX does not fix outbound identity; failed required paths remain distinct from non-blocking preferences.

4. 0:18–0:24

   Reconcile both histories • The example has arrivals at 09:07 and 09:12. • 09:00 MX change • 09:07 old source • 09:12 destination • Account for both • Illustrative times only • Two different messages

   This is the article hypothetical chronology: at 09:00 MX changes, at 09:07 one message reaches the old source, and at 09:12 a different message reaches the destination. The arrows mean temporal order, not copying of the source message. Preserve both histories and reconcile meaningful items through the selected supported method. These are illustrative times, not a measured incident, a propagation schedule or a waiting-period promise. Counts alone can hide duplicates, moved items and unsupported changes.

5. 0:24–0:30

   Separate closure from routing • Restoring MX does not merge stored messages. • ← New mail • Source messages stay • Destination messages stay • Closure waits for acceptance + reconciliation

   In a recovery decision, only the new-incoming routing token moves back toward the source; stored source and destination messages stay in their separate histories. Restoring MX does not merge messages, sent items or user changes already created at the destination. Keep the source open while unresolved delivery is investigated. Follow the selected method synchronisation and completion sequence, obtain acceptance and reconciliation approval, document exports, exceptions and retention, then separately authorise temporary-access removal and any subscription cancellation.