A hospital merger does not move every email dependency when the directory or public website changes. An inherited laboratory service may still sign with its former domain, a patient portal may use a separate tenant, and referral messages may arrive at addresses the new branding team considers obsolete. Start with continuity of these services, not a single target policy for the combined brand.
Build a merger route ledger
List each acquired domain with its legal controller, DNS administrator, application owner, sending purpose and receiving purpose. Then map the patient portal, laboratory notice, billing notice and legacy referral service separately. Include the old return path, signing selector, report destination and the team allowed to change each one. A person able to administer the new hospital tenant may have no authority over the laboratory's vendor tenant.
Use test patients and invented appointment references. A message saying that a result is ready can validate the route without including clinical content. Ask the laboratory integration lead to explain where the message is created, which relay signs it and whether a gateway modifies it. Have referral operations confirm that old inbound addresses still work before retiring any receiving infrastructure.
Distinguish rebranding from authentication
The worked estate gives laboratory notices a visible From of lab.care.test but a signer of legacy-lab.test. Its signature is stipulated to pass but has an unrelated signing domain; this is a written premise, not a verification result. Changing only a display name would not fix that mismatch. Select an approved sending identity supported by the service, configure the relevant signing domain, and test the new route before changing recipient-facing branding.
Move report ownership explicitly. Inventory who currently receives aggregate reports, who can access the processing service and whether the merged organisation is authorised to receive the old entity's data. Verify external report-destination authorisation where applicable. Preserve a dated baseline so changes in reporting participation are not confused with changes in patient communication volume.
Retire legacy domains cautiously
A domain can stop sending while still receiving referrals or replies. RFC 7505 defines Null MX, which announces that the domain accepts no mail; it is not an anti-spoofing switch and is inappropriate for a still-needed inbound route. Keep sender restrictions and receiving decisions separate. Ask each accountable owner to approve retirement, and retain a documented path for restoring the last approved configuration if a critical service was missed.
Do not treat a merger inventory as evidence of healthcare compliance. The privacy, contracting and retention rules governing each entity and its processors require qualified review. This exercise uses fictional domains and no patient data; it makes no determination about HIPAA, local health law or the legal consequences of transferring a reporting service.
Inspect the written route ledger
All rows use reserved fictional domains, proposed owners and stipulated DKIM results. Selector demo1 is an illustrative label, not an installed key. SPF results, other signatures, DNS policy discovery, actual receipt and application success are unknown. No keys, signed messages, test execution or delivery evidence are supplied.
- Patient portal: From portal.care.test; MAIL FROM portal.care.test; DKIM d=portal.care.test, selector demo1, assumed pass; proposed owner Clinical applications lead. Next action: Verify the exact portal tenant and approved controlled message.
- Laboratory notice: From lab.care.test; MAIL FROM legacy-lab.test; DKIM d=legacy-lab.test, selector demo1, assumed pass; proposed owner Laboratory integration lead. Next action: Confirm supported aligned signing; changing the display name is insufficient.
- Billing notice: From billing.care.test; MAIL FROM billing.care.test; DKIM d=billing.care.test, selector demo1, assumed pass; proposed owner Revenue cycle lead. Next action: Test the independent billing route.
- Legacy referral: From legacy-care.test; MAIL FROM legacy-care.test; DKIM d=legacy-care.test, selector demo1, assumed pass; proposed owner Referral operations lead. Next action: Verify ongoing inbound referrals before retiring MX or receiving infrastructure.
An assumed passing signature whose d= exactly matches From supplies a strictly aligned path for that hypothetical message. An unrelated d= supplies no aligned path from that signature. Unknown SPF or other signatures prevent an overall failure verdict for the latter case. These written premises establish no live configuration or inbox placement.
Make two separate retirement decisions
For fictional merger M-01, assume old-domain outbound notices have moved but referral operations still requires inbound messages at legacy-care.test. Keep its necessary receiving service; do not publish Null MX merely because outbound migration finished. Separately, moving reports to reports.new-care.test needs the applicable RFC 9990 Section 4 DNS authorization and organizational permission to share the old entity’s data. DNS authorization is not legal or business approval. With either permission unverified, leave report migration pending while continuing permitted inventory work. No domain, mailbox or report destination was changed.
Keep the evidence boundaries explicit
RFC 9989 Sections 4.4 and 5.3.5 distinguish authentication and alignment; Section 5.4 leaves message handling to receiver policy. Section 7.4 requires valid DKIM rather than SPF alone for domains publishing p=reject and warns against reject for domains whose users post to Internet mailing lists. Covered canonicalized bytes determine DKIM integrity under RFC 6376 Sections 3.4–3.7 and 6.1. Neither mechanism validates clinical, educational or legal authority. Collect authorized current evidence for an actual deployment; the operational checklists here are recommendations, not a jurisdiction-specific compliance assessment.