Migrating Email-Only Accounts to iWebVault

Some accounts exist purely for email — no website, just mailboxes for a domain. Migrating one of these to iWebVault follows the same engine as a full account, but the things that matter are different: it’s all about the mailboxes and the MX records, not web files. This guide focuses on exactly that.

What moves and what controls delivery

Two separate things are at play. The mailboxes — the accounts themselves, their passwords, and the messages stored in them — migrate as part of the cPanel backup and restore. Where new mail is delivered, however, is decided entirely by your domain’s MX records. Until you point those at iWebVault, new mail keeps arriving at your old host.

Step by step

1. Run a single-account migration with your old cPanel credentials, exactly as for a website
2. Confirm your mailboxes and their messages are present in the new cPanel
3. Plan your MX cutover for a quiet time, with a lowered DNS TTL the day before
4. Switch your MX records (or nameservers) to iWebVault
5. Check both old and new mailboxes during propagation so nothing is missed

The propagation window for mail

During DNS propagation, some sending servers will deliver to your old host and some to iWebVault, depending on whose cache has refreshed. Keep the old account live and watch both inboxes for a day or two so no message slips through. This split is normal and temporary.

If you use external email

Why email-only accounts exist

Plenty of domains are used purely for professional email — a business that runs its website elsewhere (or has no website yet) but wants addresses on its own domain. The hosting account for such a domain holds mailboxes and little else. Migrating it is about moving those mailboxes cleanly and switching mail delivery without dropping a message.

Verifying an email-only migration

Without a website to preview, your verification centres on the mail itself. After the migration completes, log into the new mailboxes (webmail is the quickest way), confirm the stored messages are present, and send a test message in and out. That confirms both that the mailboxes restored and that sending and receiving work on iWebVault before you switch delivery over.

1. Log into each migrated mailbox via webmail on iWebVault
2. Confirm folders and stored messages are intact
3. Send a test email out and confirm it leaves
4. Send a test email in and confirm it arrives

Switching delivery without a gap

Mail delivery follows your MX records. Lower your DNS TTL the day before, switch MX (or nameservers) at a quiet time, and then watch both old and new mailboxes through propagation. Because some senders will briefly still deliver to the old host, checking both ensures you capture every message until the new MX is universal.

Deliverability matters here too

Since the whole point of the account is email, deliverability is doubly important after the move. Update your SPF record to authorise iWebVault’s sending server and confirm DKIM is signing your mail. A dedicated guide covers SPF, DKIM, and PTR in detail — well worth following for an email-focused account.

What’s next

• Keeping Email Flowing During a Migration
• Email Deliverability After a Migration
• Pointing Your Domain to iWebVault

Still stuck? Our team can run or finish the migration for you — open a support ticket and we’ll take it from there.

Key takeaways

Migrating an email-only account moves the mailboxes and their stored messages; where new mail is delivered is controlled by your MX records. Run the standard single-account migration, verify mailboxes via webmail, then switch MX (or nameservers) at a quiet time and watch both servers through propagation. Update SPF and confirm DKIM for the new server so mail stays out of spam.

Will my old emails be in the new mailboxes?

Yes — the migration brings your stored messages across as part of the account backup, so your inbox history is on iWebVault before you switch delivery. New mail follows the MX records once you cut over, which is why you check both servers briefly during propagation.

Common mistakes to avoid

• Entering your website admin login instead of the old cPanel login in the source fields
• Switching MX before confirming the mailboxes restored on iWebVault
• Cancelling the old account before propagation completes, losing trailing messages
• Forgetting to update SPF, so mail from the new server lands in spam

Treat an email-only move as carefully as a website move — the data (your messages) is just as valuable, and the MX cutover is the moment that needs the most attention. Verify mailboxes first, switch MX at a quiet time, watch both servers, and keep the old account live until you’re sure every message is arriving on iWebVault.

When to let us handle it

If your email setup is at all unusual — many mailboxes, large stored archives, a mix of cPanel mail and an external provider, or strict uptime needs for business mail — you don’t have to manage the MX cutover alone. Open a ticket and we’ll coordinate the mailbox migration and the delivery switch with you, timing the MX change so no message is dropped and confirming SPF and DKIM are right on the new server. Email is the one area where a missed message is genuinely costly, so when in doubt it’s worth having us oversee the cutover rather than risk a gap during propagation.