Website hosting and email sending can have different owners
Identify the sending service from the store’s actual mail configuration and the account owner’s records, then map it separately from the website host, DNS administrator and support mailbox. The visible From address does not identify who transports the message, and Reply-to identifies a different part of the conversation. Repeat the map for order notifications and support replies if they use different services. A host move is ready for its mail handoff only when each continuing dependency has an owner and any required change is explicit.
For: A research-only merchant preparing a vendor change while order notifications and customer support must retain named owners.
List the message types the business actually uses: customer order notifications, shop notifications to staff and replies from the support team. Record the system that initiates each one and the service configured to send it. The same provider may serve several roles, but that should be a finding from the configuration or contract rather than an assumption from the website’s hosting invoice.
For store-generated mail, inspect the mail connection configuration with an authorized administrator and identify the connected service account without copying its credentials. For support replies, identify the mailbox or support service staff actually use. Where available, use the service’s existing send records to connect a real message type and timestamp to that route. Keep message bodies and customer addresses in the original authorized systems.
If the configuration names a service but nobody can identify its business owner or support contact, record that gap before the vendor leaves. A working message today does not tell the next operator who renews the service, changes the connection or answers a failure report.
Separate From, Reply-to and notification recipients
WooCommerce’s email settings distinguish the From name and address that recipients see, an optional Reply-to, and recipient settings for shop notifications such as New order. Changing Reply-to does not change From. A staff notification recipient and the customer receiving an order email are also different destinations.
The notification has its own trigger. WooCommerce documents Processing order after payment and Completed order when the order is marked completed, and individual notifications can be enabled or disabled. Retain these settings during the ownership handoff so a missing notification is not automatically blamed on the new host when the message was disabled or its trigger never occurred.
Record which team monitors the intended reply destination, including who covers it after the handoff. A branded From address is not evidence that someone reads replies. Likewise, the fact that an order notification reached a customer does not establish that the merchant’s support mailbox remains accessible.
Assign authentication to the actual sending arrangement
WooCommerce recommends a From address on the store’s domain. Its authentication guidance places SPF, DKIM and DMARC configuration with the host or mail service that actually sends for the site. Replacing website hosting alone does not establish those arrangements for a new sender, nor does it prove that an existing external sender must change.
Name the service owner who can obtain the applicable authentication instructions and the authorized DNS administrator who can inspect or change the domain’s records. They may be different people or vendors. The responsibility map should connect the sending domain to both of them; it should not contain passwords, private keys or instructions copied from a different mail service.
Classify the planned change precisely. If the sender stays the same, document the continuing service, domain and account access. If the sender changes, record the new service’s requirements and the owner responsible for the transition. If DNS administration moves, explicitly identify the existing mail records that must be accounted for by the receiving administrator. A new website loading successfully does not resolve an unknown mail dependency.
Make the handoff outcome observable
For each message path, record whether it stays, changes or remains unresolved. Attach the responsible business role, vendor support route and any dependency on the departing vendor’s account or service. Retiring a host that also supplies mail requires a decision about that mail service; retiring a host that never supplied it does not by itself transfer the separate account.
After the authorized change, compare the actual configuration with the map and inspect evidence from genuine messages as they occur: the expected notification, the sending service’s result and the receiving team’s observation. Keep a delivery problem separate from an ownership gap. Evidence for one order notification cannot establish that every message type or support reply route works.
For a scoped Prism checkout-review consultation, provide the website, research-only product context, platform, planned vendor change and the mail role whose ownership is unresolved. Any mail investigation or implementation scope, responsibilities, fees and terms need confirmation before work. The public form excludes credentials and customer records; email follow-up is not an appointment, purchase or processing application.
Mail responsibility map
Complete a separate map for each actual message path, such as a customer order notification or a support reply. Name roles and service records, not credentials or customer message contents. A blank owner or change dependency remains an open handoff item.
Worksheet entries are not submitted by Prism’s worksheet and are not saved by the site. Use record types, availability, anonymized observations, or match/mismatch results. Do not enter government identifiers, customer names or addresses, customer messages, receipt-access links, card or bank details, passwords, or keys. Send sensitive documents only through the provider’s verified secure channel.
Mail responsibility map. The last column is for temporary notes.
Responsibility
Evidence to identify it
Handoff decision
Your owner or record
Message path and trigger
Evidence to identify itNotification type, originating system and applicable enabled setting or staff workflow.
Handoff decisionIdentify what starts this message before assigning a sending failure to a host.
Sending service
Evidence to identify itActual configured mail connection and the business owner of the service account.
Handoff decisionRecord whether the same service and account remain after the vendor change.
From domain
Evidence to identify itConfigured From identity and the domain used by this message path.
Handoff decisionKeep the displayed identity separate from transport and reply handling.
DNS owner
Evidence to identify itAuthorized DNS administrator and the record location for the sending domain.
Handoff decisionName who will preserve or change authentication records using the actual service’s instructions.
Authentication responsibility
Evidence to identify itHost or mail-service contact responsible for SPF, DKIM and DMARC instructions.
Handoff decisionConnect that contact to the DNS owner; website availability alone does not establish authentication.
Operational mailbox owner
Evidence to identify itConfigured Reply-to or reply destination, shop-notification recipients and responsible staff role.
Handoff decisionConfirm who receives and monitors replies and staff alerts after the handoff.
Support and account custody
Evidence to identify itMerchant’s service ownership record and the contracted support route.
Handoff decisionResolve dependence on a departing vendor’s account before access or service ends.
Change dependency
Evidence to identify itStays, changes or unresolved for sender, domain configuration and reply mailbox, with assigned owners.
Handoff decisionClose each dependency with actual configuration and genuine message evidence; do not infer all paths from one message.
These are temporary notes. Leaving or reloading this page may clear them. Worksheet entries are not sent automatically. If you copy notes into the consultation message and submit the form, Prism receives them as part of your request.
Limits
WooCommerce settings describe WooCommerce notifications. Separate support systems and mail vendors require their own configuration records.
Authentication configuration and a service send result do not guarantee inbox delivery. This map supplies no DNS values or delivery promise.
Keep mailbox passwords, API secrets, private keys and customer message contents out of the worksheet and public inquiry.
WooCommerce email authentication — checked 2026-09-21. WooCommerce recommends a From address on the store domain and places SPF, DKIM and DMARC configuration with the actual sending host or mail service. A website move alone does not establish those settings.
WooCommerce email settings — checked 2026-09-21. From identity, optional Reply-to and shop notification recipients are distinct. Processing and completed notifications have different triggers, and notifications can be enabled or disabled.
Prism solutions — checked 2026-09-21. Published assistance includes storefront review, processing preparation and provider website questions. Specific requested work, scope, fees and terms are confirmed before work.
Prism contact — checked 2026-09-21. The form asks for the website, products and question while excluding passwords, payment data and customer records. Follow-up is by email; an inquiry is not a booking, purchase or processing application.