Rackspace SMTP settings

The published server settings

Rackspace publishes one hostname for all protocols on a secure connection: secure.emailsrvr.com. The port distinguishes the service rather than the hostname.

Outgoing mail over SMTP uses port 465, which carries an implicitly encrypted connection. Rackspace's settings table lists this as the SSL port number for outgoing mail.

Incoming mail uses the same host on a different port, 993 for IMAP and 995 for POP3. Rackspace recommends IMAP over POP for the incoming connection, because IMAP leaves messages on the server and keeps their state synchronised across devices.

Port 587 is widely accepted by mail hosts for submission with STARTTLS and is frequently quoted for Rackspace, but it does not appear in Rackspace's own published settings. Treat it as unverified rather than documented.

Authentication

The username is the full email address including the domain, not the local part alone. This is the usual convention for hosted mail, where one server serves many domains and the local part is not unique.

The password is the mailbox password. Rackspace Email does not require an application-specific password for standard client access, which distinguishes it from Google and Yahoo, where a generated credential is mandatory for third-party clients.

Authentication is required for outgoing mail. Rackspace does not accept unauthenticated submission on the secure hostname, so a client configured without credentials is rejected.

Setting up a client

An Email Help Tool is published for setup, automating configuration for supported clients and generating manual instructions for the rest. It is the shortest path for a desktop or mobile client and removes the chance of mistyping a hostname.

Manual configuration needs four values: the hostname, the port, the encryption type and the full email address as the username. Matching the encryption type to the port matters, since selecting STARTTLS against port 465 fails because that port expects TLS before any command is sent.

Test the connection through the client's own verification step before relying on it. A configuration that authenticates successfully has proven the credential and the transport, which is the part a settings page can guarantee.

What these settings do not cover

A mailbox password authenticates a client to the submission server. It does not authorise mail for a domain, which is what SPF, DKIM and DMARC do through DNS records evaluated by the receiving server.

Domain health is measurable once those records exist. We track it as a reputation score, and a healthy domain shows a score of 1.0, so degradation is a number moving rather than a guess. A recurring failure mode we see is mail going out from a sending subdomain like send.name.com while the sender wants the From address to be the apex name.com, which Chong, on our team, has traced as the shared root cause behind a whole class of tickets. And not everything resolves at the DNS layer. One stuck sender we helped debug turned out to be a platform-level sender-identity issue that no DNS record alone would fix.

Hosted mailbox sending is sized for a person. Rackspace does not publish a rate limit for third-party SMTP submission in this settings documentation, so any specific figure quoted elsewhere is unverified, and application volume is outside what a mailbox is provisioned for.

The protocol reports acceptance, not delivery. A message accepted at the SMTP conversation can still bounce afterwards or be filtered into a spam folder, and neither outcome is visible to the submitting client.

Application mail against a hosted mailbox

Sending application mail through a mailbox credential ties the application to one person's account. A password change, a mailbox suspension or a staff departure stops the application, because the credential and the person are the same thing.

There is no per-message status. Diagnosing a specific undelivered message means asking the recipient, since the mailbox provides no queryable record of what happened after acceptance.

Reputation is shared and not controllable. Mail leaving a shared hosting platform carries that platform's sending reputation, so a sender neither benefits from their own domain history nor can repair a problem caused by another tenant.

The alternative is sending from your own verified domain rather than a personal or hosted mailbox account, and verification takes about a minute. George, our CEO, is direct about why: that is what keeps deliverability strong for client work. You can operate without domain verification at first, but inbox delivery needs it. And the pipe itself should be locked down. On our relay, TCP 2525 is firewall-restricted to our API host, TLS and exact SMTP authentication are mandatory, and every one-recipient route and MX snapshot is HMAC-signed, with unsigned or replayed requests rejected.

Go deeper