Protect email during a website DNS change: find shared dependencies

Define what “website only” means

Write down the intended website hostnames, the actual DNS authority and the proposed record delta. Keep the DNS provider, delegation, mailbox location, mail provider and authentication design outside this change. A builder asking to replace a zone or connect an email service is proposing a wider change. Give that proposal its own review rather than treating it as part of a website move.

Preserve complete current values and relevant TTL, preference, alias, proxy or routing metadata in dated references. Identify the mail and DNS owners who can explain each dependency. A record type alone does not determine ownership: an address used for a website may also be a mail target or a sender-policy input.

Start with a blank preservation register

Cover: website hostnames ____; DNS authority/provider ____; mail scope/provider ____; dated evidence ____; mail/DNS owners ____; exact proposed delta reference ____; exclusions ____. Keep credentials, private keys and personal mail addresses out of shared copies. Repeat the first card for each record and the dependency fields for each relevant consumer.

An unknown classification is work still to assign. This starter is not a complete mail model: actual configuration determines the additional records and consumers that matter. Count candidate + protected + shared + unknown rows so a missing classification remains visible.

Trace inbound mail beyond the MX string

RFC 5321 Section 5.1 describes how an MX target leads to address records such as A or AAAA for the mail server. The preservation inference is simple: if that target uses an address in the website proposal, unchanged MX text does not establish unchanged routing. Record the edge from the mail consumer to the shared address and hold that proposed change for its owners.[2]

The same section distinguishes an empty MX result from present but unusable MX records. Its implicit-MX behavior applies when there are no MX entries; it does not turn unusable existing MX into an absent-MX case. A lookup error is not proof of absence either. Record any applicability question rather than inventing a fallback or deleting a record to create one.[2]

This is a bounded reading of the October 2008 document, not an actual-domain diagnosis or a complete current mail specification. Do not assume every address or alias arrangement is a supported mail-target configuration.

Read authentication dependencies as well as TXT text

RFC 7208 Sections 5.3 and 5.4 describe SPF a and mx mechanisms. The a mechanism compares the connecting sender’s IP address with the target’s connection-appropriate A or AAAA data; mx uses addresses of the returned MX hosts. A dependent address change can therefore change evaluation while the SPF TXT string stays the same. This is a potential dependency, not a complete policy or delivery result.[3]

SPF mx does not inherit SMTP’s implicit-MX fallback when no MX record exists. Keep that distinction in the register. The April 2014 document’s mechanisms are the scoped evidence here; includes, macros, processing limits and the rest of a real policy still need their own review. No new SPF value is prescribed.[3]

Microsoft’s selected guide discusses SPF, DKIM and DMARC. Use that as a reason to inventory the existing applicable authentication and provider-specific selector, policy and discovery records. Obtain actual types and values from the relevant provider’s current evidence; this guide supplies no universal selector, key, authentication recipe or assurance.[1]

Inspect what an automated flow would actually change

The Microsoft 365 Domain Connect page, updated April 23, 2026, describes email connection: changing MX sends new inbound mail to Microsoft 365, while existing messages remain at the previous host unless migrated. It also warns that, depending on the registrar, Domain Connect may offer to remove the existing MX automatically. These are boundaries of that email workflow, not steps for a website-only move or behavior promised for every wizard.[1]

Review the exact additions, replacements and deletions against the preserved register. A protected-row overwrite, mail-service addition or whole-zone import expands the proposal. Return it for separate scope and authorization. Do not retarget MX or rewrite SPF merely to make an unapproved shared website address change fit.

Fictional Amber Lantern Workshop: unchanged text, shared address

The incomplete SPF annotation is not a valid full record. Selector/policy names, types and values are placeholders with no keys. Two coupling edges matter in the story: M1 MX target address → W2, and M2 SPF a target address → W2. There is an explicit MX, so SMTP absent-MX fallback is not invoked; no SPF implicit fallback is assumed.

The count is 1 candidate + 4 protected + 1 shared + 0 unknown = 6 rows. Decision: HOLD W2 despite unchanged MX/TXT text. W1 remains only a conditional planned candidate, with recipient, sender and application acceptance review pending. Neither record has been changed and no delivery is established.

Hand over a permitted delta and the unresolved mail questions

Give the cutover plan the candidate IDs and evidence, protected record set and dependent addresses, held shared/unknown changes, exact automation delta and the next owner for every gap. Keep sequencing, timing and reversal in that separate plan; a preservation classification alone does not approve publication.

Assign later recipient, sender and application-mail acceptance evidence to the relevant service owners through their approved workflows. Unchanged DNS strings cannot establish successful delivery or authentication, and this worksheet performs neither. For the fictional case, the next useful step is resolving W2’s shared dependency while keeping W1 conditional.