SPF, DKIM & DMARC for Rackspace Email.
Rackspace Email is the hosted-mailbox side of Rackspace Cloud Office (you'll also see it called Rackspace Hosted Email), and you authenticate it with three DNS records plus one switch inside the Cloud Office Control Panel: an SPF TXT record that adds Rackspace's shared include (include:emailsrvr.com), a DKIM key you turn on in the control panel and publish as a TXT record, and a DMARC policy you add yourself. The Rackspace-specific catch that shapes the whole setup: its SPF can raw-pass but cannot align to your domain, so DKIM is the only mechanism that makes DMARC pass. On Rackspace, enabling DKIM isn't a nice-to-have — it's the load-bearing step.
Why authenticate Rackspace Email?
Authenticating a Rackspace Email domain decides whether your mail reaches the inbox, and Rackspace has one structural quirk that quietly breaks DMARC if you stop at SPF. Since February 2024 Gmail and Yahoo require every bulk sender (roughly 5,000+ messages a day) to pass SPF, DKIM, and DMARC with alignment, Microsoft began enforcing the same on high-volume mail into Outlook/Hotmail/Live in 2025, and even low-volume senders are increasingly graded on having valid authentication. The Rackspace-specific problem: Rackspace sends your outbound mail with the envelope sender (Return-Path / bounce address) on one of its own domains, and it gives you no way to set a custom Return-Path or bounce domain. That means include:emailsrvr.com can make the raw SPF check pass, but SPF never aligns with your From domain — so DMARC gets nothing from SPF. The only aligned mechanism left is DKIM signed as your domain. Turn DKIM on and DMARC passes on DKIM alignment; the sending reputation you build accrues to your own domain instead of being pooled with every unauthenticated Rackspace sender. Skip it and you have no aligned authentication at all.
The SPF reality for Rackspace Email
Rackspace is a genuine "include" provider: you add one shared mechanism, include:emailsrvr.com, to the single SPF TXT record on your root domain — the full record is v=spf1 include:emailsrvr.com ~all, and Rackspace recommends the ~all (softfail) qualifier. It's a real, well-behaved include: the live emailsrvr.com SPF record is a single flat list of ip4: ranges terminated by ~all, with no nested sub-includes, so it costs exactly ONE of your 10 SPF DNS lookups. But here's the part almost every Rackspace tutorial skips: publishing this include does NOT make DMARC pass. Rackspace sends every message with the envelope sender / Return-Path on one of its own domains (not yours), and it offers no custom Return-Path or bounce-domain option. SPF is always evaluated against that envelope domain, so include:emailsrvr.com may raw-"pass," but it can never ALIGN with your organizational From domain — and DMARC only counts SPF when it aligns. So you should still publish include:emailsrvr.com (it authorizes Rackspace's sending IPs and satisfies receivers that check a raw SPF pass), but treat it as necessary, not sufficient: DKIM signed as d=yourdomain.com is the one and only mechanism that carries your DMARC pass here. And keep exactly one SPF record — if you also send via Google Workspace, Microsoft 365, or an ESP, merge every mechanism into that single v=spf1 line rather than publishing a second SPF TXT (two SPF records is a PermError).
Step by step
- 1
Log in to the Cloud Office Control Panel
Sign in to the Rackspace Cloud Office Control Panel (cp.rackspace.com, reached from rackspace.com/login) as an admin. This is where you turn on DKIM; the SPF and DMARC records are added at whatever DNS host holds your domain's zone — which may or may not be Rackspace.
- 2
Publish or merge the SPF record
At your DNS host, add ONE TXT record on the root (host @ or blank) with v=spf1 include:emailsrvr.com ~all. If a v=spf1 record already exists (Google Workspace, Microsoft 365, a marketing tool, etc.), don't create a second one — merge include:emailsrvr.com into that single record. Rackspace recommends ending with ~all rather than -all.
- 3
Open Sender Authentication (DKIM)
On the Cloud Office Control Panel Home page, in the Domains section, click the Sender Authentication (DKIM) link. This is the Rackspace-Email-specific DKIM flow — don't confuse it with Rackspace's generic Cloud DNS 'create a DKIM TXT record' article, where you pick your own selector.
- 4
Enable DKIM for your domain
Select the domain you want to authenticate and click Enable DKIM. Rackspace generates a DKIM key pair (holding the private key on its side) and produces the public-key DNS record you'll publish. It assigns the selector for you and shows it as part of the record name — you don't invent one as you would in the generic Cloud DNS flow.
- 5
Copy the TXT Record Key and Value (or let Rackspace auto-publish)
If your domain's DNS is hosted at Rackspace, DKIM is published automatically — you can skip the manual DNS step. If your DNS lives elsewhere, Rackspace displays a TXT Record Key (the host, in the form <selector>._domainkey.yourdomain.com) and a TXT Record Value (v=DKIM1; k=rsa; p=<public key>). Copy both exactly.
- 6
Add the DKIM TXT record
At your DNS host, create a TXT record: host = the TXT Record Key Rackspace gave you (<selector>._domainkey), value = the TXT Record Value (v=DKIM1; k=rsa; p=…). Keep it as a TXT record — Rackspace hands you the public key inline, not a CNAME delegation. If your registrar auto-appends the domain, enter just the <selector>._domainkey label so it isn't doubled.
- 7
Click Verify TXT Record
Back on the Sender Authentication (DKIM) page, wait for the record to propagate (usually minutes, up to 24–48 hours), then click Verify TXT Record. Rackspace checks the published record and only then starts signing your outbound mail with d=yourdomain.com. A generated-but-unverified key does nothing.
- 8
Add the DMARC record
Rackspace doesn't create DMARC for you. Add a TXT record at host _dmarc with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. Start at p=none (monitor-only) so nothing is affected while you confirm DKIM is aligning — critical here, because SPF can't rescue Rackspace mail if you tighten too early.
- 9
Send a test and read the headers
From a Rackspace mailbox on the domain, email yourself at Gmail, open the message and choose ⋮ → Show original. You want DKIM: PASS with d=yourdomain.com and DMARC: PASS. SPF may show pass-but-not-aligned (envelope on an emailsrvr/Rackspace domain) — that's expected on Rackspace; DKIM alignment is what carries the DMARC pass.
Records to add
Rackspace Email generates the exact values in its setup wizard — these show the shape of what you'll add at your DNS host.
| Type | Host | Value |
|---|---|---|
| TXT | @ | v=spf1 include:emailsrvr.com ~allRoot SPF — keep exactly ONE SPF record; merge this include if you already have a v=spf1 line. include:emailsrvr.com costs 1 DNS lookup (a flat ip4 record). Note: this authorizes Rackspace's IPs but does NOT align — DKIM carries DMARC. |
| TXT | <selector>._domainkey | v=DKIM1; k=rsa; p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQ…(public key from the Control Panel)Illustrative — Rackspace generates the exact selector and public key when you click Enable DKIM. Published as a TXT record (not a CNAME). This is the only mechanism that DMARC-aligns for Rackspace. Auto-added if Rackspace hosts your DNS. |
| TXT | _dmarc | v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.comYou add this yourself — Rackspace never creates it. One per domain; start at p=none and don't tighten until DKIM is enabled and verified. |
| MX | @ | mx1.emailsrvr.com (priority 10), mx2.emailsrvr.com (priority 20)Illustrative — routes inbound mail to Rackspace. Receiving records, not authentication, but part of a full Rackspace Email setup. |
Keep exactly one SPF (v=spf1) TXT record on your root domain — merge every sender into it. Two SPF records is itself an error.
The 10-lookup budget
SPF is capped at a hard 10 DNS lookups — go over and it returns a permerror and stops validating everywhere. Here's what Rackspace Email's setup costs against that budget.
Rackspace Email adds 1 of your 10 lookups; ip4: and ip6: mechanisms are free.
DKIM
DKIM is the whole ballgame on Rackspace, because it's the only mechanism that can align with your domain (SPF can't — see the SPF reality above). You enable it in the Cloud Office Control Panel, not at your DNS host: Home page → Domains → Sender Authentication (DKIM) → select your domain → Enable DKIM. Rackspace then generates a DKIM key pair, keeps the private key on its side, assigns a selector, and produces the public-key record for you to publish. Two paths from there. If your domain's DNS is hosted at Rackspace, the record is published automatically and you're done once you verify. If your DNS is elsewhere (a registrar, Cloudflare, etc.), Rackspace shows a 'TXT Record Key' (the host, in the form <selector>._domainkey.yourdomain.com) and a 'TXT Record Value' (v=DKIM1; k=rsa; p=<your public key>); you add that as a TXT record at your DNS host, then return to the panel and click Verify TXT Record so Rackspace confirms it's live and starts signing. Two things make Rackspace DKIM different from the big CNAME-delegation providers. First, it's a static TXT record with the public key inline — unlike Microsoft 365 or most ESPs (SendGrid, Mailchimp, and similar), which hand you CNAMEs that let them silently rotate keys behind the scenes, Rackspace gives you the actual key value, so if you ever regenerate it in the panel you must re-publish the new TXT. (Google Workspace also uses a TXT key like Rackspace, so it's the CNAME providers that behave differently.) Second, publishing the record is not enough: signing only begins after you click Verify TXT Record. Keys have historically been 1024-bit; whatever the panel generates, publish it exactly as shown.
DMARC
DMARC is a separate policy TXT record you publish yourself — Rackspace doesn't create it. Add it at _dmarc.yourdomain.com starting with v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com. p=none is monitor-only: it changes nothing about delivery while you watch the aggregate (rua) reports to confirm your Rackspace mail is passing DKIM aligned to your domain. This matters more on Rackspace than on most providers because of the one-legged authentication: SPF can't align here, so DMARC rides entirely on DKIM. That has a hard consequence — do NOT move past p=none until DKIM is enabled and verified in the Control Panel. If you tighten to p=quarantine or p=reject while DKIM is off (or unverified), your own legitimate Rackspace mail has no aligned mechanism at all and will be quarantined or rejected, because SPF's raw pass can't rescue it. Once Show original confirms DKIM: PASS with d=yourdomain.com on real Rackspace mail, watch the reports for a week or two, then ramp to p=quarantine and eventually p=reject. Keep exactly one _dmarc record for the whole organizational domain; subdomains inherit it (override a specific one with its own _dmarc record or the sp= tag).
Check it actually worked
Don't trust the Control Panel's DKIM 'verified' badge alone — confirm it on a real message. Send yourself a test from a Rackspace mailbox on the domain, open it in Gmail, and choose ⋮ → Show original. You want DKIM: PASS with d=yourdomain.com and DMARC: PASS. Expect SPF to show a pass that is NOT aligned (the envelope/Return-Path sits on a Rackspace-owned domain) — that's normal on Rackspace and is exactly why DKIM has to carry the DMARC pass; the tell-tale success is DMARC: PASS attributed to DKIM. In the Control Panel, Sender Authentication (DKIM) should show the domain as enabled and the TXT record verified. Then run your domain through Qualisend's domain health check to confirm the SPF, the DKIM selector TXT, and the DMARC record all resolve cleanly and the SPF stays under the 10-lookup limit, and once DMARC aggregate reports start arriving, drop one into the DMARC report analyzer — Rackspace / emailsrvr.com should appear as a source passing on DKIM alignment.
Common gotchas
- Coverage
The #1 Rackspace trap: SPF can NEVER align. Rackspace puts the Return-Path/envelope on its own domain and offers no custom bounce domain, so include:emailsrvr.com raw-passes but gives DMARC nothing. DKIM signed as d=yourdomain.com is the only aligned mechanism — enabling it is mandatory, not optional.
- DNS setup
Enabling DKIM is two actions, not one: click Enable DKIM to generate the key, publish the TXT record, THEN click Verify TXT Record. Rackspace only starts signing after verification — a generated-but-unverified (or unpublished) key still fails every check.
- DNS setup
If Rackspace hosts your DNS (your nameservers point at Rackspace), the panel publishes the DKIM record for you — don't also add it manually or you'll create a duplicate/conflict. If your DNS is elsewhere, you must copy the TXT Record Key/Value into your own zone yourself.
- Coverage
Don't tighten DMARC past p=none until DKIM is verified. Because SPF can't align on Rackspace, a p=quarantine or p=reject policy with DKIM still off will quarantine or reject your own legitimate mail.
- DNS setup
Rackspace DKIM is a static TXT record with the public key inline — not a CNAME delegated to Rackspace the way Microsoft 365 and most ESPs (SendGrid, Mailchimp, etc.) work. Rackspace can't silently rotate it, so if you ever regenerate the key in the panel you must re-publish the new TXT value.
- Breaks auth
Keep exactly ONE SPF TXT record on the domain. If you also send via Google Workspace, Microsoft 365, or an ESP, merge include:emailsrvr.com into that single v=spf1 line — two SPF records is itself a PermError.
- Coverage
Use ~all, not -all — Rackspace's own recommendation — because you may also send legitimately through other tools. Only move to -all once every sender is listed in your single SPF record.
- DNS setup
Don't follow Rackspace's generic Cloud DNS 'create a DKIM TXT record' article (where you invent your own selector) for a mailbox — Cloud Office/Rackspace Email users use the Control Panel's Sender Authentication (DKIM) → Enable DKIM flow, which generates the selector and key for you.
Build your SPF record
Rackspace Email is pre-selected below. Add any other platforms you send through, then publish the single merged record.
This domain's own servers
Authorize the domain itself, if it sends mail directly (not through a platform above).
Other senders & IPs
Anything not in the list — another provider's SPF host, or specific IP addresses.
We add the include: prefix — enter the hostname your provider documents.
Policy for everyone else
What receivers should do with mail from any server not listed above (the all mechanism).
- Publish it as a TXT record at your root domain — host @ (the bare domain), value the full string above.
- Keep only one SPF record per domain. Merge every sending source into this single line — a second TXT record starting v=spf1 makes both invalid.
- Stay at or under 10 DNS lookups. Each include:, a and mx counts, and an include can trigger more lookups inside itself — ip4: and ip6: are free.
Authentication published? The next step is sending to a clean, verified list.
Verify a listRackspace Email SPF — FAQ
Related reading
Once it's published, confirm everything resolves with the domain health check, then read who's sending as you with the DMARC report analyzer. Browse all sending sources in the generator. Authentication is only half of deliverability, though — a listed sending IP or domain still lands you in spam no matter how clean your SPF is, so it's worth watching the blacklists with blacklist monitoring.
Authenticated — now keep the list clean
Passing SPF, DKIM, and DMARC gets you to the inbox; a clean list keeps you there. Verify yours — start free with 100 credits, no card required.