Site and e-mail do not have to live in the same house. You can keep the mailboxes with us and put the site with another provider, or the other way round. It is common, it works well, and it is where people delete their own e-mail most often.
|
The mistake that costs. When changing provider, the temptation is to move all the nameservers at once. That drags the e-mail along with the site — and messages start being delivered to a server where the mailboxes do not exist. Senders get an error; recipients never learn they lost mail.
|
First decide who owns the DNS
One question comes before all the others: where will the domain’s DNS zone live? The records have to be edited there, and only there.
| If the nameservers point at… |
Edit the records… |
| Us |
In Meu Interweb, in the domain’s DNS management — or in cPanel’s Zone Editor |
| The other provider |
In their panel. Editing here achieves nothing: the world does not read this zone |
| Cloudflare or similar |
In that service’s panel, which now owns the zone |
Case A: e-mail with us, site elsewhere
Here you change only what points the site and leave everything else alone.
| 1 |
Ask the other provider for the IP of the server the site will live on.
|
|
| 2 |
In the DNS zone, change the domain’s A record to that IP. Do the same for www, or set it as a CNAME pointing at the domain.
|
|
| 3 |
Do not touch the MX record, nor mail, nor webmail, nor the TXT records for SPF and DKIM. Those are what hold the e-mail in place.
|
|
| Record |
Touch it or not |
| A (the domain) and www |
CHANGE — these are what send the site to the new server |
| MX |
LEAVE ALONE — it is what tells the world where to deliver your mail |
| mail and webmail (A records) |
LEAVE ALONE — that is how Outlook and your phone connect |
| SPF and DKIM TXT records |
LEAVE ALONE — without them your mail starts landing in other people’s spam |
|
If the zone ends up at the other provider. Then it is the reverse: you have to recreate the e-mail records there, which existed here on their own. There are four: the MX with priority 0 pointing at mail.yourdomain.ao, an A record for mail, an A record for webmail, both with your hosting IP here, and the TXT for SPF. Ask us for the exact values — they differ from client to client, and copying them out of any old article goes wrong.
|
Case B: site with us, e-mail elsewhere
Common with Google Workspace and Microsoft 365. The site stays, the mail leaves.
| 1 |
Get the other provider’s MX records, and the verification TXT if they ask for one.
|
|
| 2 |
In the DNS zone, delete our MX records and add theirs. Leave the site’s A record as it is.
|
|
| 4 |
And do the step nearly everyone forgets — routing, right below.
|
|
The trap: cPanel’s e-mail routing
|
Changing the MX is not enough while the site stays with us. cPanel keeps a setting of its own saying whether that domain’s mail is delivered inside this server or out there. While it says “inside”, an e-mail sent from your own site — or from another account on the same server — never leaves: it is delivered locally, to a mailbox that is no longer the real one. The classic symptom is “mail from outside arrives, mine does not”, or an unknown user error.
|
| 1 |
Open cPanel and find Email Routing.
|
|
| 3 |
Select Remote Mail Exchanger and save.
|
|
|
The same applies in reverse. If you brought the e-mail back here and it still goes to the old provider, set it to Local Mail Exchanger. This setting is independent of the MX record and is the most common cause of mail that vanishes with no error at all.
|
Before changing anything
| 1 |
Write down the current zone. Open DNS management and keep a snapshot of every record. If something goes wrong, this saves your day.
|
|
| 2 |
Lower the TTL a few days ahead if you can. A short TTL makes the change land quickly; a long one keeps you tied to the old value — see DNS records explained.
|
|
| 3 |
Do not delete the old mailboxes until you have confirmed the new ones receive. During propagation, mail lands on both sides.
|
|
After the change: how to confirm
Do not trust “looks fine”. Confirm it:
| 2 |
Send a message from outside — from a Gmail account, say — and confirm it arrives.
|
|
| 3 |
Send from the mailbox and confirm it leaves. And send from another account on the same server, which is the test that catches wrong routing.
|
|
Give propagation time before concluding it is broken — see how long propagation takes. And if mail still fails after all this, see why your e-mail is not sending or receiving.
RECOMMENDED PRODUCT Professional e-mail on your domain Mailboxes in your company name, no adverts, with spam filtering. from $9.99/mo See plans |
Português
English
