Treat Hosted Exchange as a legacy service name
If a sending inventory still says Rackspace Hosted Exchange, first establish what now sends the organization's mail. Rackspace's January 5, 2023 incident update states that its Hosted Exchange environment would not be rebuilt as a continuing service. That update identifies Microsoft 365 migration and Rackspace Email as alternatives. It is historical product evidence, not a current offer, price promise or confirmation of your migration.
This guide therefore covers resolving a legacy dependency and verifying the replacement route. It does not provide new Hosted Exchange enrollment steps, a current DKIM switch or reusable DNS values. An old provider label in a DMARC report is a lead to investigate, not proof that a discontinued mailbox service remains your active sender.
Keep the change focused. Reconcile one business route at a time, beginning with a recent ordinary message from a controlled mailbox. Do not remove records merely because they resemble an old support article. The same organization may have moved employee mail while retaining a separate application relay, forwarding arrangement or archiving dependency.
Identify the service that actually sends today
Ask the account owner for the current service name, administrator portal, domain inventory and migration record. Separate who bills for support from which platform emits the message. A Rackspace-managed Microsoft 365 account must be assessed using the actual Microsoft 365 tenant and route. Rackspace Email must be assessed under that product's current instructions. Neither inherits proof from an old Hosted Exchange checklist.
Build a route list covering employee mailboxes, shared addresses, applications, multifunction devices and any externally hosted tools. Record the intended From address, responsible owner, current submission method and a representative message for each. An application configured years ago may still be using a different outbound path than a user's desktop client.
Use both administrative evidence and received messages to resolve disagreements. An invoice can establish the commercial relationship, while a fresh header shows a particular delivery. MX records show where incoming mail is directed; by themselves they do not identify every service allowed to send outbound mail. Mark uncertain routes unresolved rather than forcing them into the nearest familiar product category.
Preserve the DNS baseline before cleanup
Export the relevant zone records and document their exact owners, types, values and TTLs. Include SPF, DKIM selectors, DMARC and any return-path delegations. Record which application or service owns each dependency and where its approved replacement instructions can be found. Keep this baseline with the change request so another administrator can distinguish an intentional migration from accidental deletion.
SPF applies to the SMTP MAIL FROM identity, with a separate HELO evaluation, rather than simply to the address displayed in the message. RFC 7208 also requires correct selection of a single SPF policy and limits DNS-querying mechanisms and modifiers. Review the complete policy at the actual evaluated owner before adding or removing an authorization.
Do not create a second SPF record as a migration shortcut. Do not paste a historical include into a new policy without confirming that the current service needs it. Equally, do not remove an include until all routes depending on it have an approved disposition. A shared authorization can survive a mailbox migration for legitimate reasons, but its business owner and purpose should be explicit.
Obtain configuration for the replacement route
Request the current platform's domain-specific instructions from its authenticated administration surface or verified support channel. The required evidence is the exact record set, supported signing identity, envelope-domain behavior and any activation step for that account. Public documentation can explain the procedure, but it cannot establish that your domain is enrolled or that a displayed example is your assigned value.
If instructions conflict with an existing owner, pause that individual change. Record the conflicting service and ask the relevant providers for a supported resolution. Do not invent a DKIM selector, reuse another customer's public key, or redirect an existing CNAME to make a wizard appear complete. Preserve the organization's existing DMARC policy unless an authorized owner approves a separate policy change.
Define the recovery action before activation. It might be restoring the last approved sender configuration, pausing an affected application or reverting a precisely identified DNS change. Restoring a discontinued Hosted Exchange service is not a valid rollback plan. The recovery route must itself be available and verified for the business function it would replace.
Verify the new identity at the receiver
Send harmless messages through every in-scope route to controlled external mailboxes. Include a separate internal test where internal delivery matters. Record the Message-ID, UTC time, From domain, Return-Path, each DKIM signing domain and selector, and the authentication results stamped by the trusted receiving system. Save enough context to associate the message with the correct application without retaining unnecessary personal content.
A DKIM signature's d= and s= identify the signing domain and selector used to find its key, as defined in RFC 6376. A passing signature from an unrelated provider domain does not alone establish alignment with your visible From. Compare the observed identity rather than the product name shown in a reporting tool.
Under RFC 9989, DMARC can pass when a passing SPF or DKIM identity aligns with the From domain. Apply the alignment mode actually configured; a related subdomain can behave differently under relaxed and strict settings. Record the mechanism that supplied the aligned pass. A green DNS check or successful inbox placement does not substitute for this message-level evidence.
Rackspace legacy route worksheet
Complete a separate row for each mailbox or application path:
- Historical service label and current confirmed service: ____.
- Business owner, administrator and current instruction reference: ____.
- Intended From address and submission route: ____.
- Baseline DNS export and records shared with other services: ____.
- Replacement record owners, values and activation evidence: ____.
- Existing DMARC policy and applicable alignment modes: ____.
- Message-ID, UTC time and controlled receiving mailbox: ____.
- Observed Return-Path, DKIM d= and s=, trusted results: ____.
- Aligned passing mechanism and unresolved exceptions: ____.
- Approved recovery route and retirement owner: ____.
An unknown current service or missing receiver result keeps the route open. Track data recovery, historical mailbox retention and live sending as separate work items; progress in one does not prove completion of the others.
Fictional diagnosis of an obsolete sender label
Fictional example only: Birch Engineering sees a reporting entry labeled Hosted Exchange and proposes restoring an old SPF authorization. Its administrator confirms that employee mail moved to Microsoft 365, while a scanner uses another relay. Controlled tests show aligned authentication for employee mail and an unaligned provider signature on scanner mail.
The team separates the two routes, obtains current relay instructions and corrects the scanner's supported sender configuration. It leaves employee-mail authentication unchanged. After a fresh scanner test proves alignment, it reviews the historical permission against the remaining inventory. No Birch tenant, domain or message was inspected; this example illustrates a diagnostic decision, not a verified incident.
Close the legacy dependency with evidence
Retire an old record only after its owner confirms that no active route relies on it and the replacement has passed controlled tests. Keep the retirement decision, approved rollback and observed results together. Recheck after a mail-platform change, DNS migration or unexpected source in reports. Live tenant access, current account-issued configuration, public DNS and header verification, visual review, human SME approval and publication remain pending.
Keep the historical date attached to the claim
The status page mixes a later archive heading with dated incident entries. The January 5, 2023 entry supplies the no-rebuild statement; it is not a November 2026 migration offer. In the fictional scanner example, an unaligned signature alone would not establish DMARC failure if a different aligned passing mechanism existed. The example leaves the other results unspecified.
Separate message acceptance from policy rollout
A passing aligned SPF result can satisfy a message evaluation, but does not alone justify moving an entire domain to reject. RFC 9989 Section 7.4 requires valid DKIM for domains publishing p=reject and warns about indirect-mail interoperability. Inventory all legitimate senders and indirect routes before the policy owner approves enforcement. No DNS change, tenant operation or received-message test was executed for this article.