Identify the Rackspace product before following a DKIM guide
Rackspace supplies several services that can appear in the same organization's mail inventory. A Rackspace-hosted DNS zone, a Rackspace Email mailbox, Hosted Exchange, Microsoft 365, and an application running on a cloud server are not interchangeable authentication routes. This guide covers domains supported by the documented Cloud Office Sender Authentication workflow. Confirm the actual product and available domain controls before applying it.
Rackspace's separate Create a DKIM TXT Record article explicitly says its generic Cloud DNS method differs from the setup for Rackspace Email, Hosted Exchange, and Office 365 customers and directs those customers to Cloud Office assistance. Do not use that generic key-generation procedure as evidence that hosted mail will sign with a manually created key. Rackspace DKIM product-scope note
Write down the mailbox product, account administrator, visible From domains, submission endpoints, and any outbound relay. For a website or business application, establish whether it submits through the hosted mailbox service or sends independently. A website being hosted by Rackspace does not establish that its outgoing messages use Cloud Office signing.
This product identification is an acceptance gate. If the requested domain does not expose the documented Sender Authentication control, stop and obtain current product-specific instructions. Do not compensate by creating an arbitrary selector in DNS, changing mailbox MX records, or assuming another Rackspace product's setup applies.
Enable signing in the supported hosted-domain flow
The documented Cloud Office workflow starts in the control panel's Domains section at Sender Authentication (DKIM). Select the domain and enable DKIM. DNS managed through that panel is handled automatically by the documented flow; externally hosted DNS requires publication of the public TXT record instructions. Use Verify TXT Record to check the public record and review any validation error. Rackspace states that new outgoing messages are signed after DKIM is enabled. Rackspace Cloud Office DKIM
Capture the actual generated owner and public value for the selected domain. If the current interface does not show enough information, ask Cloud Office support for the domain's supported instructions rather than guessing a key. The DNS host publishes public information; it does not independently choose a private signing key for a hosted mail service.
Confirm the active authoritative nameservers even when the customer uses Rackspace for some services. A record visible in one control panel may not be the record recipients query. For external DNS, check the fully qualified selector owner after publication and ensure the editor has not appended the zone twice. Preserve the previous record where one exists and resolve a selector collision before overwriting it.
The verification button and a received signature answer different questions. Verification checks a public DNS prerequisite. A controlled outgoing message shows whether the real route used the intended signing domain and selector. Neither step should be silently substituted for the other in the change ticket.
Authorize the real SMTP route with SPF
Rackspace's Cloud Office SPF policy example uses include:emailsrvr.com. Apply that authorization only after identifying the hosted-mail route it is intended to cover. If the organization already has an SPF record, preserve its legitimate senders and merge the necessary mechanism rather than replacing the entire policy with a single-service example. Rackspace SPF policy guidance
The same domain may also send through a CRM, a billing platform, or a separate website service. Record each route and its supported authentication configuration. Do not authorize an unrelated cloud-server address merely because the server and mailboxes share the Rackspace brand. Conversely, enabling hosted mailbox DKIM does not configure a separate application that bypasses the hosted service.
SPF permits one applicable policy at a record owner and limits DNS-dependent evaluation. Use proper mechanisms for the actual authorization; an include references another SPF policy and is not a generic container for an arbitrary IP address. Check the full resulting policy and the identity evaluated on received messages. SPF RFC 7208
Keep any change to the policy's final qualifier in its own reviewed decision. Adding a service is not automatically approval to tighten enforcement for all existing senders. Save the original value and a rollback plan, including who can restore it and how to verify the resulting public answer.
Test mailbox and application messages separately
Send controlled messages from the actual webmail or mail-client route in scope, then from each separately configured application. Retain a safe test identifier, timestamp, receiver, visible From, envelope domain, and the trusted Authentication-Results. Capture each DKIM d= and s= pair and query the matching public record.
DKIM binds the signature to its signing domain; merely finding a public key somewhere under the organization's domain does not prove that the observed message used it. Confirm that the intended signature passed at the receiver. For a failing signature, distinguish a missing key, an incorrect key, and message modification before replacing records. DKIM RFC 6376
DMARC requires a passing SPF or DKIM mechanism aligned with the visible From domain. A provider-domain authentication pass may be unaligned. Preserve the exact alignment mode, domain relationship, and applicable policy in the evidence. Do not require both mechanisms to pass as the definition of DMARC, although maintaining both can improve resilience across different delivery conditions. DMARC RFC 9989
Forwarding should be a separate observation if it is important to the business. Changes in the SMTP path can affect SPF, and changes to signed content can affect DKIM. A direct-mail success is not a guarantee about every forwarding arrangement. Do not weaken the organization's policy merely to make an unexplained forwarded message appear successful.
Maintain separate mail streams after rollout
Rackspace's reputation guidance recommends distinguishing mail by purpose and using separate signing keys for different sending services. Use that principle to keep the hosted employee-mail route distinguishable from marketing or transactional systems. Its example policy choices are not a substitute for an organization-specific enforcement review. Rackspace domain reputation guidance
Maintain a register of domains, services, selectors, SPF authorizations, and owners. When a service is retired, verify that its traffic has ended and arrange an approved removal rather than accumulating permanent unused authorization. When a sender is added, require evidence for the new route before treating it as covered by an earlier mailbox test.
Rackspace acceptance worksheet
Complete this proposed worksheet separately for every product and outbound route. It contains no live customer observations.
- Product scope: Rackspace service, tenant, supported domain, control-panel access, administrator, and any product-specific support confirmation.
- Sending route: mailbox client, webmail, application, submission endpoint, relay, intended From, and envelope identity.
- DKIM setup: enablement state, current generated owner and public value, DNS management location, verification result, and exact error if any.
- DNS evidence: authoritative nameservers, full record owner, published key or supported target, SPF policy, TTLs, and capture time.
- Message evidence: safe test identifier, receiver, timestamp, DKIM domains and selectors, trusted results, and the mechanism supplying alignment.
- Dependencies: other services using the same domain, separate application routes, forwarding cases, and untested products.
- Release decision: product-scope holds, rollback owner, change approval, SME review, and publication status.
Fictional diagnosis of a key in the wrong product
This example is fictional. An administrator follows a general Rackspace Cloud DNS article, creates a public-key record, and expects hosted mailbox messages to use it. The next test is unsigned with that selector, so the administrator considers generating another key.
The proposed investigation first identifies the hosted product and checks its supported Cloud Office signing control. The team obtains the actual hosted-domain instructions, publishes the corresponding public value if required, and tests new mailbox messages. A website hosted on a separate cloud server still needs its own route assessment. Publishing a key alone cannot make an unrelated system possess or use the matching private key. This scenario is a diagnostic illustration, not a completed configuration.
Product scope and release gates
The exact customer product, domain eligibility, tenant-generated values, authoritative DNS, and received authentication results remain unverified. Hosted Exchange, Microsoft 365, and self-managed cloud-server configurations are not asserted to follow this procedure without product-specific confirmation. Human SME review, visual review, live mailbox and application tests, and publication approval remain pending. The candidate must remain unpublished until its scoped evidence is complete.
Keep the hosted-product decision explicit
The fictional case stipulates only that the observed message did not use the manually chosen selector. Its actual DKIM and SPF results remain unspecified. A different valid signature may exist, so inspect all signatures before diagnosing a signing outage. Record the supported mailbox product and control-panel instruction before proposing a replacement key.
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.