Rackspace SMTP, IMAP & POP3 Settings (2026): Port 465 Only

Rackspace publishes one hostname and one port per protocol: secure.emailsrvr.com with IMAP 993, POP3 995 and SMTP 465, all SSL. Port 587 is not among them, which is why most Rackspace email setups fail on the outgoing server.
Alaa
By Alaa
SMTPedia documents email infrastructure end to end: SMTP standards from the RFC archive, delivera...
11 min read Aug 28, 2026 15 views

Reading time: 9 min · Last verified: August 2026 · SMTPedia editorial team

The Rackspace email settings are unusually short. One hostname answers every protocol, encryption is not optional, and each protocol has exactly one published port. That simplicity is also where most setups go wrong: the port that fails is the one your mail client suggests by default. Rackspace publishes port 465 for outgoing mail and nothing else, while the wider web keeps repeating 587 with STARTTLS. If your Rackspace email setup ends in an authentication or encryption error, the port is the first thing to check.

READ THIS FIRST SSL ONLY, PORT 465

Rackspace publishes one outgoing port: 465 with SSL. Its own settings documentation lists three rows and three ports: POP3 995, IMAP 993, SMTP 465, all on secure.emailsrvr.com, all encrypted. There is no plaintext hostname and no port 587 anywhere on those pages. A mail API vendor documents the consequence bluntly in a support note titled “Rackspace Required SMTP STARTTLS not supported”, stating that “Rackspace have stopped supporting NON-SSL port 587” and telling customers to re-authenticate on 465. If your client filled in 587 for you, change it before you change anything else.

Quick Reference: Rackspace Email Server Settings

These are the values Rackspace publishes for Rackspace Email, read in August 2026 from two of its own documentation pages that agree with each other row for row. Every connection uses SSL, and the username is always the full email address rather than the local part.

ProtocolServerPortEncryptionUsername
IMAP (incoming)secure.emailsrvr.com993SSLFull email address
POP3 (incoming)secure.emailsrvr.com995SSLFull email address
SMTP (outgoing)secure.emailsrvr.com465SSLFull email address
Not published by Rackspace: any plaintext hostname, any port 587 entry, and any app-specific password for Rackspace Email. Values you find elsewhere for those fields did not come from Rackspace.

One hostname for all three protocols is rare, and it is worth understanding why it works: secure.emailsrvr.com is a service endpoint, not a per-protocol machine, so the port alone decides which service answers. If you are new to how those numbers map to services, the reference on email protocols and their standard ports covers the full set.

Which Rackspace Mailbox Do You Have?

Rackspace sells more than one hosted mailbox, and the settings above apply to only one of them. The address tells you nothing, since both can be you@yourdomain.com. Check which product your account is on before entering a Rackspace mail server value anywhere.

THIS PAGE
Rackspace Email

The Cloud Office mailbox. Webmail sits at apps.rackspace.com. IMAP, POP3 and SMTP all answer on secure.emailsrvr.com. The table above describes this product.

DIFFERENT SERVERS
Exchange online through Rackspace

Rackspace also resells Microsoft hosting. Its own guide for that product gives outlook.office365.com for IMAP and POP, and smtp.office365.com on 587 for outgoing. Nothing on emailsrvr.com applies.

TELL THEM APART
The webmail test

Log in to webmail. A Rackspace-branded interface at apps.rackspace.com means Rackspace Email. Outlook on the web means the Microsoft product, and its settings live elsewhere.

The 587 confusion partly starts here. Rackspace genuinely does publish port 587, but only for the Microsoft product it resells, where STARTTLS is the correct method. Copy that port onto a Rackspace Email account and the connection fails on a server that never offered it. If your mailbox turns out to be the Microsoft one, our Microsoft 365 server settings breakdown is the page you want instead.

Why the Rackspace SMTP Server Rejects Port 587

Ports 465 and 587 are not two doors to the same room. They implement encryption in two different orders, and a server that offers one does not automatically offer the other.

USE THIS
Port 465, implicit TLS

The TLS handshake happens first, before a single SMTP command is spoken. In client settings this appears as “SSL/TLS” rather than “STARTTLS”. This is what Rackspace publishes.

FAILS HERE
Port 587, STARTTLS

The session opens in plaintext and upgrades on command. It is the modern default in most clients and libraries, which is exactly why it gets filled in automatically on a server that does not publish it.

The failure is rarely a clear message. Depending on the client you may see a timeout, a certificate complaint, or an authentication error that sends you hunting for a password problem you do not have. Our guide to SSL and TLS for email walks through the difference between implicit TLS and an upgrade negotiation, and the reference page on the 550 Must Issue STARTTLS rejection covers the mirror image of this problem, where a server demands the upgrade you never sent.

Practical rule for the Rackspace outgoing mail server: set the port to 465, set encryption to SSL/TLS, and never leave the encryption field on “automatic” or “none”. If your client insists on offering only STARTTLS, look for a separate SSL option rather than a different port.

Rackspace IMAP Settings

Rackspace recommends IMAP over POP3 for incoming mail, and for a hosted business mailbox that recommendation is sound: IMAP keeps the mailbox on the server, so folders, read state and sent items stay identical across a laptop, a phone and webmail.

Incoming serversecure.emailsrvr.com
Port993
EncryptionSSL
UsernameYour full email address
PasswordYour mailbox password, the same one used for webmail

Two details catch people out. The first is the username: a bare local part is rejected, and the domain is never entered in a separate field. The second is folder mapping. Rackspace serves standard IMAP folders, but a client that was previously configured for POP3 on the same address will often keep its local Sent and Trash folders instead of subscribing to the server ones, which looks like missing mail and is not. The IMAP configuration reference covers folder mapping and subscription behaviour in detail.

Rackspace POP Settings

POP3 is supported and published, on the same host as everything else. Use it only when you have a reason to: a single machine that must hold a local archive, or a legacy client that cannot do IMAP properly.

Incoming serversecure.emailsrvr.com
Port995
EncryptionSSL
UsernameYour full email address

The risk with POP3 on a 25 GB mailbox is the leave-on-server toggle. Set to delete, it moves your only copy onto one device. Set to leave, it downloads the same messages again on every other device you configure. Neither is what most people expect. The POP3 configuration guide explains the retention settings and how they interact with multiple clients on one account.

Rackspace SMTP Settings and Sending Limits

The Rackspace SMTP settings are one line: secure.emailsrvr.com, port 465, SSL, authenticated with the full email address and mailbox password. Authentication is not optional, and there is no unauthenticated relay to fall back on. A server that refuses to relay for you without credentials produces the family of errors described on our page about servers that require authentication for non-local addresses.

PUBLISHED LIMITS

10,000 recipients per 24 hours, per email address. Rackspace counts recipients, not messages, so one send to 200 people costs 200. The window runs from 00:00:00 to 23:59:59 Eastern time, not from your first send.
25 GB maximum mailbox size.
50 MB maximum attachment size in the Rackspace environment.
Server to server, Rackspace uses opportunistic TLS in both directions: it attempts an encrypted transaction and falls back to plaintext if the other side cannot negotiate one.

That last point is worth reading twice if you assumed a business mailbox encrypts everything end to end. Opportunistic TLS protects the hop when the far side supports it and silently does not when it cannot, which is the normal behaviour across the public mail system rather than a Rackspace shortcoming.

A recipient cap of that size is generous for human correspondence and wrong for anything automated. Application mail, notifications and bulk sending belong on a relay built for them, with per-message telemetry and a reputation you control. The general SMTP setup guide covers authentication, port choice and TLS for any client or application, and our breakdown of what business email hosting plans actually allow compares mailbox sending caps across providers.

When the Rackspace Email Setup Fails

Four causes account for most failures, in this order.

1
Port 587 instead of 465.

By far the most common. Fix the port and set encryption to SSL/TLS, not STARTTLS.

2
Username entered without the domain.

The login is the whole address. This surfaces as an authentication failure that looks like a wrong password.

3
Wrong product.

An Exchange online mailbox billed by Rackspace will never authenticate against secure.emailsrvr.com, no matter which port you try.

4
A value copied from a third-party page.

Plaintext hostnames and app passwords circulate widely for this provider. Rackspace publishes neither for Rackspace Email.

If you would rather not guess, Rackspace runs a setup assistant at emailhelp.rackspace.com that reads the configuration attached to your own mailbox and returns the values for your specific client. It is the one source that cannot be out of date for your account, and it is the right answer when a domain was moved between Rackspace products at some point in its history.

Sending From an Application Through the Rackspace Mail Server

Contact forms, order confirmations and WordPress plugins can authenticate against secure.emailsrvr.com using the same host, port and credentials a mail client uses. Whether they should is a different question, and three properties of a mailbox make it a poor relay.

The first is the port. Most mail libraries default to 587 with STARTTLS, and many expose that as the only obvious choice, so the integration has to be pointed explicitly at 465 with implicit SSL before it will connect at all. The second is the recipient cap: 10,000 recipients per address per day sounds ample until an automated system loops, at which point the mailbox that also carries your human correspondence is the one that stops sending. The third is visibility. A mailbox gives you no per-message delivery telemetry, so a rejected or deferred message leaves no trace you can query, and the first symptom of a problem is a customer saying they never received anything.

If you keep application mail on the mailbox anyway, log what the server returns rather than only whether the send succeeded. Response codes are the only diagnostic you get, and our SMTP error code directory maps them to causes so a deferral is not mistaken for a delivery.

Frequently Asked Questions

What is the SMTP server for Rackspace Email?

The Rackspace SMTP server is secure.emailsrvr.com on port 465 with SSL, authenticated with your full email address and mailbox password. Rackspace publishes no other outgoing host and no other port for this product.

What are the settings for Outlook on Rackspace?

Identical to every other client: incoming secure.emailsrvr.com on 993 for IMAP or 995 for POP3, outgoing secure.emailsrvr.com on 465, SSL on all three, username as the full address. The only Outlook-specific step is to open the advanced settings and set the outgoing encryption explicitly, since Outlook will otherwise attempt its own negotiation and can land on the wrong method.

Are the Rackspace email settings different on iPhone or Android?

No. Hostname, ports and encryption are the same on every platform, and a page offering special Rackspace email settings for iPhone or Android is describing an interface, not a protocol. On iOS, add the account as “Other” rather than letting Mail guess the provider, and fill in the outgoing password even though the field is labelled optional.

Does Rackspace support port 587?

Not for Rackspace Email. Its published settings list 465 and nothing else, and a mail API vendor documents that “Rackspace have stopped supporting NON-SSL port 587”, with re-authentication on 465 as the fix. Rackspace does publish 587, but for the Microsoft hosting it resells, which is a different product on different servers.

Where do I log in to Rackspace webmail?

Rackspace Email webmail is at apps.rackspace.com, with the same credentials your mail client uses. A successful webmail login is also the fastest confirmation that a client failure is a settings problem and not a password problem.

How can I find my own IMAP server settings if I am not sure?

Use the Rackspace setup assistant at emailhelp.rackspace.com, which returns the server settings tied to your actual mailbox rather than a generic table. Administrators can also read them from the Client Setup area of the Cloud Office control panel. Both beat guessing when an account has changed products.

Settings for other business mailbox platforms:

Microsoft 365 Email Settings · Google Workspace Email Settings · Titan Email Settings · Namecheap Private Email Settings

About This Guide

These values were verified on August 28, 2026 against Rackspace’s own documentation: its two Rackspace Email settings pages, which publish identical server tables, its Rackspace Email FAQ for the 25 GB mailbox limit, the 50 MB attachment limit and the opportunistic TLS behaviour, its daily sending limit article for the 10,000 recipient cap, and its Exchange online setup guide for the resold Microsoft product. Fields Rackspace does not publish, including any plaintext hostname and any app-specific password, are deliberately absent rather than filled in from third-party pages. SMTPedia re-verifies provider settings quarterly. If Rackspace publishes a value that contradicts this page, the provider is right and we want to hear about it.


About the Author

Alaa - SMTPedia author

Alaa · LinkedIn

Email infrastructure specialist with 8+ years of hands-on experience in SMTP, deliverability, and email verification. I’ve configured and troubleshot mail systems across Postfix, Exchange, and cloud relays, managed IP reputation and warmup campaigns, and built verification pipelines processing millions of addresses. My work spans DNS authentication (SPF, DKIM, DMARC, BIMI), bounce handling, blocklist monitoring, and compliance frameworks including CAN-SPAM and GDPR. I write every article on SMTPedia to give email professionals, developers, and marketers the accurate, RFC-grounded reference they need.


About SMTPedia

SMTPedia is an independent email industry reference covering SMTP, IMAP, POP3, email deliverability, marketing platforms, DNS authentication, and email verification. Every article is researched from official provider documentation, IETF RFCs, and industry best practices. Settings and configurations are verified quarterly.

We are cited as a source by ChatGPT, Microsoft Copilot, and thousands of email professionals worldwide. Learn more about our editorial process.