The one thing most guides leave out. Every company moving to a new mail provider already has records from the old one. Adding the new records beside the old ones does not switch anything over — and the failure is silent. Step 2 exists for that reason.

1. Copy the existing mail first

Copy before you switch, so a mistake costs time and not messages.

While the old provider is still receiving, copy the mailboxes across over IMAP. Copying reads from the old server; it does not delete anything there. If something is missing you can simply run it again.

Do this before touching DNS. Once the MX record changes, new mail arrives at the new server while old mail sits at the old one, and reconciling the two is tedious.

2. Remove the old provider's records

Old MX, SPF and DMARC records must go, not sit alongside the new ones.

Three specific leftovers cause most failed migrations:

The old MX record. MX priority is a preference number and smaller wins. An old 0 mail.oldhost.com beside a new 10 mx.newhost.com means every incoming message still goes to the old server. The new mailbox looks empty and nothing reports an error.
A second SPF record. A domain is allowed exactly one. With two, receivers treat SPF as permanently broken and ignore both — worse than having none at all.
A second DMARC record. Same result: the policy is discarded, so whatever you wrote in the new one has no effect.

DKIM is the exception. Several DKIM records can coexist, because each one lives at its own selector name. Leaving the old provider's DKIM record in place is harmless.

3. Point the MX record at the new server

One MX record, and nothing else with a smaller number.

Type	Host	Priority	Value
MX	`@`	10	`mx.mailora.io`

The priority number itself does not matter — 10 is conventional. What matters is that no other MX record has a smaller one.

4. SPF, DKIM and DMARC

These three decide whether your mail is believed or filtered.

Incoming mail needs only the MX record. These three are about outgoing mail: they let Gmail and Outlook tell your messages apart from someone forging your domain.

SPF — who is allowed to send as you

Type	Host	Value
TXT	`@`	`v=spf1 mx ~all`

mx means "the servers listed in my MX record may send for me". If you also send from a newsletter tool or a website form, that service must be added to the same record — not put in a second one.

DKIM — a signature on every message

DKIM records are unique to your domain, so there is no generic value to copy. Mailora generates a pair of keys when the domain is added and shows both records in the admin console under Domains → DNS setup.

Copy them exactly. A DKIM key is a long string, and a single wrong character is worse than no record at all: mail is signed, the signature fails to verify, and receivers treat it as a forgery attempt.

DMARC — what to do when a check fails

Type	Host	Value
TXT	`_dmarc`	`v=DMARC1; p=none; rua=mailto:you@yourdomain.com`

Start at p=none. It changes nothing about delivery but asks receivers to send you daily reports, so you can see who is sending as your domain before you tighten the policy to quarantine or reject. Tightening first and looking later is how companies block their own invoices.

5. Verify before you trust it

Check against live DNS, not against what you typed.

DNS changes take from a few minutes to about an hour to spread. Once they have, check the records as the internet sees them — not as they look in your DNS provider's editor, which shows what you saved rather than what is being served.

In Mailora, Domains → DNS setup → Verify records reads live DNS and reports three things most checkers miss: an MX record that outranks ours, duplicate SPF, and duplicate DMARC. It names the exact record to delete.

6. Connect Outlook, Thunderbird and phones

The same settings everywhere; the full address is the username.

	Incoming (IMAP)	Outgoing (SMTP)
Server	`mx.mailora.io`	`mx.mailora.io`
Port	993	587 (or 465)
Security	SSL/TLS	STARTTLS (SSL/TLS on 465)
Username	Your full address — `you@yourdomain.com`
Password	Your mailbox password

The two mistakes that account for nearly every failed setup:

Entering only the part before the @ as the username. Use the whole address.
Choosing "No authentication" for outgoing mail. Sending needs the password too, or the server refuses to relay.

POP3 is deliberately not offered. It downloads mail and removes it from the server, which breaks the moment someone opens the same mailbox on a second device.

When it goes wrong

Mail sent to my domain never arrives

Look at the MX records first, and at the priority numbers rather than the names. An old record with a smaller number takes everything, silently.

My mail lands in the recipient's spam folder

Open one of the messages in Gmail, choose Show original, and read the Authentication-Results line at the top. It states plainly whether SPF, DKIM and DMARC passed. If all three pass and mail is still filtered, the cause is reputation rather than configuration, and it improves with normal sending over days.

I fixed the records but nothing changed

DNS answers are cached for as long as the record's TTL. If the TTL was set to a day, a day is how long the old answer can persist somewhere. Lowering the TTL before a migration — not after — is what makes changes take effect quickly.

Start the 30-day trial

How to set up email on your own domain