Rackspace SPF, DKIM and DMARC setup, step by step

For supported Rackspace Email hosted domains, merge include:emailsrvr.com into the domain's existing SPF policy, then enable DKIM through Cloud Office → Domains → Sender Authentication (DKIM). Publish the exact public TXT record issued for your domain when DNS is hosted elsewhere, complete Verify TXT Record, and check a newly delivered message for your intended aligned DKIM signature and dmarc=pass. A generic Rackspace Cloud DNS key does not activate hosted mailbox signing. Rackspace SPF instructions, hosted-domain DKIM instructions.

On this page: Scope and prerequisites · SPF · DKIM · DNS checks · DMARC · Message acceptance · Troubleshooting · FAQs · Documentation review and testing boundary

Scope and prerequisites

Use this procedure for a Rackspace-hosted mail domain that supports the documented Sender Authentication controls. It does not configure retired Hosted Exchange, Microsoft 365, a self-managed mail server, or a website merely hosted on Rackspace infrastructure. Rackspace's general Cloud DNS DKIM article explicitly distinguishes hosted-mail products from its manual key-generation method. Product boundary.

If the account is Microsoft 365, follow the Microsoft 365 authentication guide instead. For a web application, establish whether it submits through Rackspace Email or sends independently. Website hosting, incoming MX records and a familiar brand name do not identify the outbound signer.

Before editing anything, assemble:

• Cloud Office administrator access and confirmation that the domain supports hosted-domain DKIM.
• The domain's current DNS administrator, active authoritative nameservers and any delegated subdomain owners.
• Intended visible From addresses, SMTP submission routes, forwarding services and downstream gateways.
• A baseline of existing SPF, DKIM and DMARC records, complete owner names, TTLs and affected senders.
• A change owner, an approved controlled recipient and a recovery plan for the specific records being changed.

Treat a missing Sender Authentication control as a product or permission question for Cloud Office support. Do not create a random selector to compensate. No MX replacement, nameserver migration, inbound filtering bypass or domain-wide policy downgrade is part of this authentication task.

Configure SPF for the actual envelope domain

SPF checks the SMTP MAIL FROM domain. The delivered Return-Path usually reflects that envelope address; a receiver's smtp.mailfrom result identifies what it evaluated. The visible From address, Reply-To and display name are different fields. Confirm the real envelope for each sending route before deciding which DNS owner needs SPF.

Rackspace documents this standalone TXT example for a domain using its mail service. Use it only when the relevant owner has no existing SPF policy and the sender inventory justifies that scope. @ means the apex of the DNS zone currently being edited. Rackspace SPF policy.

Type: TXT
Owner: the actual sending domain, represented by @ only in its own zone
Value: v=spf1 include:emailsrvr.com ~all
Documented TTL: 3600 seconds

If there is already a policy, edit that one SPF TXT record. Add the needed mechanism before its final all, preserving other legitimate senders and the approved qualifier. Do not append a second record. This fictional merge preserves a separately approved static sender and the existing hard-fail ending; the reserved address is not a Rackspace server or a value to deploy:

Before: v=spf1 ip4:192.0.2.25 -all
After: v=spf1 ip4:192.0.2.25 include:emailsrvr.com -all

An include references another SPF policy, not an arbitrary server name or IP address. Direct addresses use ip4 or ip6; select mechanisms according to their actual meaning. A policy ending in redirect= needs separate evaluation rather than blind string insertion. See merging multiple SPF records safely.

If the existing SPF policy uses redirect=, do not blindly append an all mechanism or a complete canned policy: any all mechanism makes redirect ignored. Preserve the redirect-authorized senders and approved final semantics through a reviewed policy design. SPF redirect semantics.

The SPF budget is 10 evaluated DNS-lookup-causing terms, including nested include and redirect evaluations. The terms are include, a, mx, ptr, exists and redirect; ip4, ip6 and all do not consume this term budget. This is not a limit of 10 DNS packets or 10 visible includes. Additional address-query limits apply to mx and ptr; implementations should limit void lookups to two. Evaluate the combined policy, including less common sending paths. RFC 7208, section 4.6.4.

SPF does not inherit from a parent domain. If a message uses bounces.mail.example.com, an edit at example.com does not automatically authorize that envelope. If the envelope is provider-controlled, a root-domain change cannot make it align. This guide does not assert that Rackspace offers a custom Return-Path control for every account.

Enable Rackspace hosted-domain DKIM

Use the hosted-mail control panel, not the general Cloud DNS key generator:

1. Open the Cloud Office Control Panel and select Domains → Sender Authentication (DKIM).
2. Select the supported domain and enable DKIM.
3. For DNS managed through that panel, the documented enablement is automatic. For external DNS, obtain the domain-specific public TXT owner and value from the supported workflow.
4. Publish that TXT record at the authoritative DNS host, then use Verify TXT Record and resolve any displayed error.

Rackspace states that new outgoing messages are signed after enablement. Do not use an old sent message to judge the change. Official activation sequence.

Publish a TXT public key, not a CNAME containing key text. Preserve the generated selector and full value. Do not use a screenshot's key, another customer's selector, a private key or a separately generated key pair. If the screen does not expose a complete owner and public value, request them through Cloud Office support before continuing.

A DKIM public-key record belongs at SELECTOR._domainkey.SIGNING_DOMAIN. The selector and signing domain must come from the issued setup and later match the message's s= and d=. Long TXT values may be represented as multiple quoted character strings within one DNS record; they are concatenated without extra spaces. Do not create several separate TXT records for one selector. DKIM DNS binding.

Map the full owner into the correct zone

For the fictional full owner rskey._domainkey.mail.example.com:

These names illustrate DNS placement, not Rackspace-issued values. Some editors accept a full name; others append their zone automatically. Inspect the resulting full owner so it does not become rskey._domainkey.mail.example.com.example.com. If the child zone is delegated, changes in an inactive parent-zone copy will not serve recipients.

If _domainkey.mail.example.com itself is already delegated, the same illustrative full owner belongs at relative name rskey in that delegated zone, not in an inactive parent copy. Preserve that namespace’s NS delegation and other active selectors, and publish only the exact provider-issued type and value at its authoritative operator. The selector shown remains an example, not an issued account value. Relative DNS names, DKIM key lookup.

Before replacing an existing value, identify its owner and active sender. A selector collision requires a supported resolution, not deletion of another service's key. Keep unrelated TXT verification records intact. See DKIM selector collisions.

Verify the authoritative DNS answers

The following commands are reader-run checks, not results observed for a customer. Replace every uppercase variable with confirmed values. ZONE is the authoritative zone containing the record, which may be a parent zone or a delegated child. AUTH_NS is one of its authoritative nameservers.

ZONE='example.com'
AUTH_NS='ns1.dns-host.example'
MAIL_FROM_DOMAIN='example.com'
DKIM_OWNER='ISSUED_SELECTOR._domainkey.example.com'
FROM_DOMAIN='example.com'

dig +short NS "$ZONE"
dig @"$AUTH_NS" "$MAIL_FROM_DOMAIN" TXT +norecurse
dig @"$AUTH_NS" "$DKIM_OWNER" TXT +norecurse
dig "$DKIM_OWNER" TXT
dig "$MAIL_FROM_DOMAIN" TXT
dig "_dmarc.$FROM_DOMAIN" TXT

Confirm the zone and delegation first. An empty NS answer for a subdomain does not by itself prove that it lacks DNS service; its records may be in the parent zone. The DNS administrator can identify the closest enclosing authority using delegation and SOA evidence. Query each authoritative server if answers disagree.

Expected observations:

• Exactly one v=spf1 policy at the actual envelope owner, containing the approved Rackspace authorization without losing other senders.
• One usable DKIM public-key TXT record at the exact issued owner, matching the complete issued value.
• Authoritative responses with the expected data and an authoritative-answer flag; then consistent recursive responses after relevant positive or negative caches expire.
• The applicable DMARC policy, including inherited policy when the From domain has no direct record.

A blank short answer cannot distinguish a nonexistent name from the absence of that record type. Use full output to inspect NXDOMAIN, NOERROR with no matching answer, or SERVFAIL. Do not treat every failure as propagation. DNSSEC problems, wrong delegation and a misspelled owner need a diagnosis, not a fixed waiting period.

This Rackspace procedure uses TXT. If you encounter an existing CNAME at the proposed owner, stop: CNAMEs cannot coexist with ordinary TXT data at the same name. Do not remove the alias until its dependency is understood. For a separately supported CNAME-based service, preserve the actual alias and use DNS-only records without flattening that hides it. Cloudflare's CNAME verification safeguards.

Retain the right DMARC policy and reporting

DMARC compares the visible From domain with authenticated SPF and DKIM identities. One passing aligned mechanism is enough for a message-level DMARC pass. Relaxed alignment allows the applicable organizational-domain match; strict alignment requires an exact domain match. adkim controls DKIM alignment and aspf controls SPF alignment, with relaxed behavior when omitted. A provider-domain pass may remain unaligned. RFC 9989 alignment.

Retain existing policy and reporting addresses. Check _dmarc at the exact From domain and any applicable organizational/parent policy before proposing a new record. Do not assume an empty direct lookup means no policy applies. RFC 9989 uses DNS-tree-walk discovery and obsoletes RFC 7489; it removed pct, so do not plan percentage-based enforcement from old examples.

Publish a first policy only when none applies

Only after checking that neither a direct nor an inherited DMARC policy applies, the policy owner can approve this initial TXT record. It requests no DMARC-based change to mail handling; it does not guarantee delivery. Inventory legitimate senders and arrange reporting before relying on it as a monitored rollout.

Type: TXT
Full owner: _dmarc.example.com
Value: v=DMARC1; p=none

Replace the example domain with the actual From domain. Map the full owner into the authoritative DNS zone:

If a policy already exists, review and edit that record when authorized, rather than adding a duplicate or overriding inherited protection. Never replace established quarantine or reject with none as a Rackspace troubleshooting shortcut. For p=reject, RFC 9989 section 7.4 requires valid DKIM rather than relying solely on SPF and highlights mailing-list interoperability risks.

To request aggregate reports, append ; rua=mailto:YOUR_ACTUAL_AUTHORIZED_REPORT_ADDRESS to the value only after replacing the placeholder with a real, approved destination. The bare policy above does not request reports. External recipients must authorize reporting as described below. External reporting requirements.

If aggregate reports go to an external processor, obtain its actual rua address and confirm reporting authorization in the recipient's DNS. For the fictional policy domain example.com and destination reports@collector.example.net, the authorization lookup is:

dig TXT example.com._report._dmarc.collector.example.net

The external destination publishes the required authorization, potentially through a supported wildcard. Do not create guessed records in your sending zone or copy a sample mailbox. Review report access and retention with the organization; failure reports can disclose message information and should not be enabled casually. RFC 9990 external destinations.

Compare the Organizational Domain of the aggregate report URI’s host with the Organizational Domain of the domain where the DMARC policy was found, not necessarily the visible From domain. If they differ, the report-generating receiver must check DNS authorization. A destination within the same Organizational Domain as that policy domain is excepted; a different hostname alone does not make it external. This protocol check is separate from the domain owner’s approval to share report data with that recipient. RFC 9990 section 4.

Verify mailbox and application messages separately

After the account and DNS checks, the mail owner should send a harmless, approved message through each actual route: webmail, the configured mail client and any application using the hosted service. Use an external receiver that performs authentication checks, not only an internal mailbox that may bypass them. This article has not sent those tests.

Open the received original. Record the From domain, actual envelope identity, every DKIM d= and s=, timestamp and message reference. Use Authentication-Results added by the trusted receiving system, correlating its authserv-id with that receiver's documented boundary and Received trace. A sender can insert lookalike headers; the first or most favorable result is not automatically trustworthy. RFC 8601 trust boundary, EmailAuth header interpretation.

Establish which result fields were generated inside the receiving service’s known processing boundary and how it removes or distinguishes externally supplied Authentication-Results. Use its documented handling or ask the receiving administrator if the boundary is unclear. A familiar authserv-id string or header position alone is not proof; reject attacker-supplied or otherwise untrusted fields. Operational result-field trust.

Accept the hosted-domain signing setup only when:

1. The intended Rackspace-generated signature is present and the receiver reports dkim=pass for that signature.
2. Its d= aligns with the visible From under the effective adkim mode.
3. The receiver reports dmarc=pass for that From domain.
4. SPF's actual result, evaluated envelope and connecting-IP explanation have been recorded and any unexpected error has been resolved or explicitly escalated.

An SPF-only DMARC pass does not prove the DKIM setup succeeded. A second valid provider signature does not substitute for the intended branded one. Conversely, one failing unrelated signature does not invalidate a different passing aligned signature.

Test forwarding separately if relevant: the connecting IP can change, and intermediaries can modify signed content. A successful direct message is not evidence for every forwarded path. Authentication also does not guarantee inbox placement, delivery speed or that a recipient read the message.

Troubleshooting and recovery

For regression recovery, restore only the affected known-good record or supported signing state after checking shared dependencies. Keep original values and TTLs available to the change owner. DNS reversion does not flush caches immediately. Do not delete verification keys needed by mail already in transit, unless incident response requires revocation. After recovery, repeat both DNS and message checks.

Keep a route register with service owner, domain, selector, activation date and test evidence. Rackspace's domain-reputation guidance recommends separating mail purposes and keys between services; apply that principle without treating its example policy settings as universal instructions. Rackspace domain reputation.

Documentation review and testing boundary

This guide combines current public Rackspace instructions with standards-based verification advice. No customer account was accessed, DNS changed, message sent, production implementation validated or website publication performed. The generated selector, actual envelope identity, active signing and delivered-message results must be checked in your own environment.