Rackspace SMTP settings, and what changes when an agent sends through them

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.

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 synchronized 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.

What changes when an AI agent sends through Rackspace

When a coding agent wires app or alert email into code, a Rackspace mailbox is often the credential closest to hand. The mail then runs unattended, retries on its own and lives in a config file, and three parts of these settings start to matter more.

• The app signs in as one member of staff. The username is that person's full email address and the password is their mailbox password, with no app-specific credential required, so the app inherits a personal login.
• One hostname serves every protocol. secure.emailsrvr.com takes SMTP on 465, IMAP on 993 and POP3 on 995, so an agent filling in a config from a copied mail client setup can carry an incoming port into the outgoing setting.
• The mailbox's sending limits now apply to the app. Hosted mailbox sending is sized for a person, and Rackspace does not publish a figure for third-party submission in its settings documentation, so an agent that loops or retries finds the limit only by reaching it.

Nitrosend has no SMTP host. The path an agent can run end to end is an API or an MCP server on a verified sending domain, so moving mail off Rackspace changes the code path to the transactional email API or the Nitrosend MCP server rather than swapping one SMTP hostname for another.

Sending email from an LLM covers the same choice for chat assistants, and the SMTP ports guide covers the hosts that do take SMTP.

Rackspace SMTP authentication uses the full email address and mailbox password

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, unlike Gmail's app passwords.

Authentication is required for outgoing mail. Rackspace does not accept unauthenticated submission on the secure hostname, so a client configured without credentials is rejected. SMTP authentication covers how that login works at the protocol level.

How to set up a mail client with Rackspace settings

Rackspace publishes an Email Help Tool 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 from the table above: host secure.emailsrvr.com, port 465, SSL/TLS encryption 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 Rackspace SMTP settings do not cover

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

Any Rackspace sending limit quoted elsewhere is unverified, since the settings documentation publishes none.

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.

Worked example: an agent moves order alerts off a Rackspace mailbox

The prompt, in the shop owner's words: Our store sends order alerts through the orders@ mailbox on Rackspace with its password in .env. Move them to our own domain without changing what customers get.

Before: left unguided, the agent keeps secure.emailsrvr.com on port 465 in the config, copies the mailbox password into a second environment file and resends an alert whenever the SMTP call times out.

With Nitrosend connected over MCP, the sequence is gated:

1. nitro_get_status reads the account's readiness and sender identity, so the agent knows whether a sending domain is ready before it touches the alert code.
2. nitro_manage_domains adds and verifies a sending subdomain of the store's domain, which becomes the From identity the orders@ mailbox used to provide.
3. nitro_manage_template creates the order alert as a reusable template, carrying over the subject line and order fields the Rackspace mailbox was sending.
4. nitro_review_delivery checks that new alert template without sending it, returning validation, spam analysis and a preview of the order alert.
5. nitro_send_test_message sends one real order alert from the template to the account's test recipient, the address held in nitro_configure_account, and to nobody else.
6. A person opens that test alert and checks the order number, the From address and the links before the app changes.
7. The app's order handler then sends each alert with nitro_send_message, one message per call. Each order gets its own idempotency_key, reused only when that exact alert is retried.
8. nitro_get_insights reports on the order alerts after the first days of sending, with trends and recommendations.

After: the Rackspace password is out of the app's config, a timed-out alert is retried without a second copy reaching the customer, and orders@ goes back to being an inbox a person reads.

Application mail against a hosted mailbox

There is no per-message status an app can query. Bounce notices come back to the mailbox as mail, not as delivery events the application can read.

Reputation is shared. Mail leaves through the provider's outbound servers alongside other tenants' mail, so the sending IPs are not the sender's alone.

The alternative is sending from a verified sending domain of your own rather than a personal or hosted mailbox account. Inbox providers like Gmail expect mail to be sent from a dedicated subdomain, so the sending identity belongs to the domain and not to one member of staff. Setting that up is covered under email authentication protocols and the transactional email API.

Where it goes wrong when an agent uses a Rackspace mailbox

• Port 993 in the SMTP field. Because secure.emailsrvr.com is also the IMAP host, an agent that copies the incoming settings points the sender at 993, and the connection fails because that port speaks IMAP, not SMTP.
• A staff password in the repo. Once the mailbox password sits in a .env file, a commit or a log, a routine reset of that person's password breaks every alert the app sends, and the old value stays in the history. The SMTP password guide covers where these credentials should live.
• A retry loop against the mailbox limit. An agent that resends on every timeout, with no idempotency_key, sends duplicate alerts and pushes the mailbox toward whatever sending limit Rackspace applies to it, a limit the person who reads that mailbox shares.
• The staff member leaves. When the mailbox is suspended or deleted at offboarding, the app's credential goes with it, and the alerts stop with no error that anyone is watching.
• Port 587 from a forum answer. An agent that picks 587 with STARTTLS is using a port that is not in Rackspace's published settings, so when it fails there is nothing official to check the config against.

Moving the alerts to a verified domain over the email API, with delivery events from email webhooks, removes the shared login and gives each message its own status.

Rackspace SMTP settings questions

What are the Rackspace SMTP server and port? The outgoing server is secure.emailsrvr.com on port 465 with SSL. Sign in with the full email address, domain included, as the username and the mailbox password as the password. Authentication is required, so a client set up without credentials is rejected by the server.

What are the Rackspace IMAP settings? Incoming mail over IMAP uses the same host, secure.emailsrvr.com, on port 993 over a secure connection. The username and password are the same as for SMTP. Rackspace recommends IMAP over POP because IMAP leaves messages on the server and keeps their state synchronized across devices.

What are the Rackspace POP settings? POP3 uses secure.emailsrvr.com on port 995 over a secure connection, with the full email address and the mailbox password. It is supported, but Rackspace recommends IMAP instead, since IMAP keeps messages on the server and their state synchronized across a phone, a laptop and webmail.

Does Rackspace support SMTP port 587? Port 587 with STARTTLS is widely accepted by mail hosts and often quoted for Rackspace, but it is not in Rackspace's published settings, which list 465 for outgoing mail. Use 465 with SSL so that, if a connection fails, the config can be checked against a documented value.

Go deeper