Migrating a mailbox from Aruba to Exchange Online, licence-free

A shared mailbox costs nothing up to 50 GB. The DKIM value the portal suggests is the wrong one, and IMAP migrations have no Complete button.

Moving a mailbox from a hosting provider to Exchange Online has two halves: copying the messages, which is mechanical, and switching the DNS, which is the part where mail stops for everybody if you get it wrong.

This one was done without spending a licence, and the DKIM step cost an hour because the portal suggests a value that no longer works.

The mailbox that costs nothing

A shared mailbox in Exchange Online is free up to 50 GB and requires no licence of its own.

For a info@-style address — read by several people, not owned by one — that is the correct object anyway, and it happens to make the migration cost nothing. Create it in the admin centre under Teams & groups → Shared mailboxes before starting.

The IMAP batch

You need three things from the source provider: the IMAP server name, the port, and whether it wants SSL. For the provider in question: imaps.<provider>, port 993, SSL, Basic authentication.

The migration CSV is three columns:

EmailAddress,UserName,Password
[email protected],[email protected],PASSWORD

Exchange admin centre → Migration → Add migration batch.
Type: Migration to Exchange Online → IMAP migration.
Create a new migration endpoint with the server, port, SSL and Basic authentication, and let it validate.
Upload the CSV and start the batch.

Result to look for: status Synced, data consistency Perfect, 100%, zero failed.

Keeping the batch alive for 24 hours after the DNS cutover is worthwhile: it picks up anything that still landed on the old server during propagation.

The DNS cutover

Three records change. Get the exact values from the admin centre under Settings → Domains → DNS records — do not copy them from a guide, because the tenant-specific part differs.

Type	Host	Value
MX	`@`	`<tenant>.mail.protection.outlook.com`, priority 0
TXT	`@`	`v=spf1 include:spf.protection.outlook.com -all`
CNAME	`autodiscover`	`autodiscover.outlook.com`

The domain verification TXT (MS=…) stays exactly as it is.

If the provider’s control panel asks what kind of MX you are configuring, the answer is external servers — the mail is no longer theirs.

DKIM, and the value the portal gets wrong

Signing is configured in Defender, not in the mail admin centre: Email & collaboration → Policies & rules → Threat policies → Email authentication settings → DKIM. Select the domain, Create DKIM keys, publish the two CNAMEs, then flip the toggle to Enable.

The two records look like this:

Host	Points to
`selector1._domainkey`	`selector1-<domain>._domainkey.<tenant>.k-v1.dkim.mail.microsoft`
`selector2._domainkey`	`selector2-<domain>._domainkey.<tenant>.k-v1.dkim.mail.microsoft`

Verify with nslookup -type=cname selector1._domainkey.<domain> against a public resolver. The provider’s own authoritative servers can be a few minutes out of step with each other, so one answering correctly and another not is normal mid-change.

What to check when it is done

The domain shows as healthy in the admin centre, with the three records recognised.
Send to the address from an external account — Gmail works — and confirm arrival.
Send from it, then open the received message’s headers and look for spf=pass, dkim=pass, dmarc=pass.
After 24 hours: Stop → Delete the migration batch.

Two records you can leave alone

If the old provider published a DKIM key of its own — commonly on a selector like a1._domainkey — and a DMARC record at p=none, both are harmless and can stay for now.

The old DKIM key signs nothing once mail leaves through Microsoft, and p=none instructs nobody to reject anything. Removing them is tidying, not repair, and tidying is better done after the migration has been stable for a while than during it.