Moving to RunCloud or Cloudways? What Happens to Your Email

The site moves fine. The site always moves fine. Two days later somebody notices that nobody has emailed them since Tuesday, and the contact form has been failing the whole time. That is the most common way a move from cPanel to RunCloud or Cloudways goes wrong.

RunCloud and Cloudways are application and stack managers, not hosting panels. Neither gives you a mail server. Cloudways has no built-in email hosting: it sells a paid Rackspace Email add-on, a third-party mailbox service bought through their dashboard, not mail on your application server. RunCloud manages Nginx, PHP, databases and deployments on a VPS you own, and does not install a mail server either.

Moving a cPanel or DirectAdmin site to either platform does not migrate your mail. It deletes your mail server without replacing it. Repoint DNS at the new host without thinking about MX and incoming mail stops. It does not sit in a bounce queue you can chase later. It gets handed to a server that no longer hosts the domain, or refused at the door.

Audit what mail you actually have

On a cPanel source, as root, per domain:

DOM=example.com
CPUSER=$(/scripts/whoowns "$DOM")

# 1. Mailboxes and their sizes
uapi --user="$CPUSER" --output=jsonpretty Email list_pops_with_disk

# 2. Forwarders and the catch-all (the "*:" line)
cat "/etc/valiases/$DOM"

# 3. Autoresponders (pipes into /usr/local/cpanel/bin/autorespond)
grep -l autorespond /etc/valiases/* ; ls -la "/home/$CPUSER/.autorespond/" 2>/dev/null

# 4. Server-side filters
cat "/etc/vfilters/$DOM"

# 5. Mailing lists
ls -1 /usr/local/cpanel/3rdparty/mailman/lists/ 2>/dev/null | grep "$DOM"

Five categories, and people routinely forget four. Mailboxes are obvious. Forwarders are not, and a sales@ that quietly feeds three people is exactly the address a business cannot lose. The catch-all matters too. If *: :fail: becomes *: :blackhole:, or the reverse, users notice.

Then the category that does the most damage, because it is invisible: mail the application itself sends. Order confirmations, password resets, contact form submissions, cron notifications. On cPanel that leaves through local Exim on the server’s own IP and works without anyone configuring anything. Find out how much of it there is:

# Which document roots are injecting mail into Exim, and how much
grep ' <= ' /var/log/exim_mainlog | grep -o 'cwd=[^ ]*' \
  | sort | uniq -c | sort -rn | head -20

# What the site is already configured to do
grep -rniE "smtp_host|SMTP_HOST|MAIL_MAILER|mailer|smtp" \
  /home/$CPUSER/public_html/wp-config.php \
  /home/$CPUSER/public_html/.env 2>/dev/null

If the second command finds nothing, the site is using PHP mail() and local Exim, and it stops working the moment you move. That is your most important finding.

The four destinations for mail

Pick one before you touch DNS.

Destination	Effort	Best for	The catch
Keep mail on the old server	Lowest, initially	Buying time during a phased move	You maintain a whole server for mail. Licence, patching and backups still apply.
Google Workspace / Microsoft 365	Moderate	Businesses with staff, calendars, shared drives, compliance needs	Per-user pricing punishes low-use aliases. Convert single-purpose mailboxes to free aliases or groups first.
Dedicated mail host (Rackspace, Zoho, Fastmail, Migadu)	Low	Most small business and hosting-client migrations	Fewer collaboration features. Cloudways’ Rackspace add-on is this category.
Self-host a separate mail server	Highest by a distance	Operators with sysadmin capacity and many domains	You own deliverability forever: PTR records, blocklists, SPF/DKIM/DMARC, spam filtering.

My default for a business moving one site to a managed stack is a dedicated mail host. It is cheap and the migration is an IMAP sync. Google Workspace or Microsoft 365 when the client already lives in those ecosystems, and self-hosting only for people who already run mail servers.

The option I push back on is “keep it on the old server indefinitely”. It sounds free. It is not. You have kept every cost of the old box and removed the only reason you were paying attention to it. Six months later it is unpatched, the disk is full, and the certificate for mail.example.com expired.

DNS: the records that must move independently

Moving a website is an A record change. Moving mail is a separate set of records, decided separately.

Record	Points at	Move with the site?
A / AAAA for @ and www	New application host	Yes. This is the site move.
MX	Mail provider	No. Only when mail actually moves.
A for the MX hostname (e.g. mail.example.com)	Mail server	No. Leave it on the mail server.
TXT SPF (v=spf1 ...)	Everything allowed to send as you	Update to include the new sender, do not replace blindly.
TXT DKIM (default._domainkey, selector varies)	Mail provider’s signing key	Only when mail moves, and take the new provider’s key.
TXT _dmarc	Your policy	Keep it. Relax to p=none during the transition if you are unsure.
CNAME autodiscover / autoconfig, SRV _autodiscover._tcp	Mail provider (Outlook, Thunderbird, M365)	With mail.
A/CNAME webmail, cpanel, smtp, imap, pop	Old panel	Delete or repoint deliberately.

The classic failure has two variants, and I see both constantly.

Variant one: rebuilding the zone. Someone moves nameservers to the new provider or to Cloudflare and retypes the zone from what they see in the new dashboard. The A records get recreated, because the site is visibly broken without them. MX, DKIM and autodiscover do not. Export the full zone from the old server first and keep it. It is the only complete record of what existed.

cat /var/named/example.com.db          # cPanel
# or
dig +noall +answer @old.example.net example.com AXFR

Variant two: the MX hostname. MX points at mail.example.com, which is an A record in your zone. You leave MX alone, congratulate yourself, then update mail.example.com to the new server IP along with everything else. MX is technically unchanged and now points at a box with no mail server. Mail stops. Check explicitly:

dig +short MX example.com
dig +short A "$(dig +short MX example.com | awk '{print $2}' | head -1 | sed 's/\.$//')"

If the second command returns the IP you are about to change, you have found your outage before it happened.

Application mail from the new stack

Once the site is on RunCloud or Cloudways, stop using local sendmail. These platforms run on general-purpose cloud instances (DigitalOcean, Vultr, Linode, AWS) whose IPs carry no mail reputation, and several of those providers block outbound port 25 by default, so direct delivery often does not work at all. When it does, the mail lands in spam.

Use an authenticated SMTP relay on port 587: SES, Postmark, Mailgun, SendGrid, Brevo, or the SMTP endpoint of whichever mailbox provider you chose. For WordPress that is a plugin such as WP Mail SMTP or FluentSMTP. For Laravel it is environment configuration:

# /home/runcloud/webapps/example/.env
MAIL_MAILER=smtp
MAIL_HOST=smtp.example-relay.com
MAIL_PORT=587
MAIL_USERNAME=apikey
MAIL_PASSWORD=<relay-credential>
MAIL_ENCRYPTION=tls
MAIL_FROM_ADDRESS=no-reply@example.com
MAIL_FROM_NAME="Example Ltd"

Two things people get wrong. First, the relay must be authorised in your SPF record and its DKIM records must exist in your zone, or your own transactional mail fails DMARC. Second, if the new server has Postfix installed with your domain in mydestination, mail the application sends to an address at your own domain gets delivered locally into a mailbox nobody reads. Your domain should not appear in the output of:

postconf -n mydestination

The order that avoids losing mail

1. Write down every mailbox, forwarder, autoresponder, filter, list, and every place the application sends mail from.
2. Choose the mail destination and create the mailboxes there before anything moves.
3. Lower TTLs to 300 on the A, MX and MX-hostname records, at least 24 hours ahead.
4. Sync the mailboxes with imapsync while the old server is still the live MX and still receiving. Full detail in the imapsync runbook.
5. Move the site and test it on the platform’s staging URL or via a local hosts entry. Do not change DNS yet.
6. Configure the SMTP relay and send real test mail from the application, including a password reset and a contact form submission. Check it lands in an inbox rather than spam.
7. Change only the A/AAAA records. Leave MX, the MX hostname, DKIM and autodiscover on the old mail setup. The site is live on the new platform and mail is untouched.
8. Let that settle for a day or two and confirm mail still flows.
9. Cut mail over. Change MX, DKIM, autodiscover/autoconfig, and update SPF to cover the new mail host and the relay.
10. Run delta imapsync passes for 72 hours after the MX change, to sweep up mail that landed on the old server during propagation.
11. Decommission the old server after two weeks, not two days. It is your only rollback and your only copy of whatever the audit missed.

Splitting steps 7 and 9 is the whole trick. Move the website and the mail on separate days and you always know which change caused a problem.

FAQ

Does Cloudways host email?

No. Cloudways has no built-in email hosting. It resells a Rackspace Email add-on as a paid extra, which is a separate mailbox service rather than mail on your application server. Anything you already have on cPanel needs a destination picked before you migrate.

Can I run a mail server on my RunCloud VPS?

Technically yes, since it is your own server and RunCloud only manages the web stack. Practically it is a poor idea unless you run mail servers already. RunCloud will not manage it, and the provider’s IP range needs reputation work before anything you send arrives.

If I only change the A record, does my email keep working?

Yes, as long as the MX record and the hostname it points at are both untouched and you have not moved nameservers and rebuilt the zone. That is exactly why I move the site and the mail on different days.

What happens to my contact form and order emails?

They break silently unless you configure an SMTP relay. On cPanel they went out through local Exim with no configuration; on these platforms there is no equivalent. Test a real password reset before calling the migration finished.

Where this fits

Splitting a hosting account into a web half and a mail half is a routine part of server migration work. If you are going the other direction and consolidating back onto a panel, the Cloudways to cPanel migration guide covers that path, and the imapsync runbook covers the mailbox move itself.