Professional Email on Your Domain with Acrux Mail

Moving a ten-person company’s email onto its own domain loses nothing if it’s done in the right order, and costs a week of lost messages if it starts by changing the MX record. The right order: plan the addresses, create the mailboxes, add the authentication records while incoming mail stays with the old provider, copy the old mail, switch the MX and copy whatever arrived in the meantime, then verify and tighten. This guide walks you through those steps on business email from Illevante in partnership with Acrux Mail, and most of it applies to any email service on your domain.

01Plan the addresses before you create them

An address you print on a business card or an invoice isn’t easy to change, so decide before you create the first mailbox. For Luqaimat House, a family sweets business on the domain bayt-alluqaimat.com, the plan looks like this:

• One naming format: First name, such as rana@, or first and last name, such as rana.haddad@. Decide now what happens when two names clash, and adopt one way of spelling Arabic names in Latin letters, so one employee doesn’t get mohammad@ and another muhammad@.
• Role addresses: sales@ and info@ are aliases that deliver to people, and invoices@ is a shared mailbox the accounts team works from. That way the printed address doesn’t change when the team does.
• Technical addresses: postmaster@ is required by the SMTP standard, abuse@ is where people expect to report abuse, and dmarc@ receives DMARC reports. Make them aliases that deliver to whoever runs your email.

02The DNS records you add

Every email service on your domain needs the same records; only their values change. Copy the exact values from your client area after activation; the table shows example names. The only record that changes where your incoming mail goes is the MX record, which is why it comes last, on switch day:

Three rules prevent the most common mistakes:

• One SPF record: If your website sends form mail from its own server, add that server to the same record, for example v=spf1 include:spf.mail.example ip4:198.51.100.20 ~all. Two records break the whole check, and a record is limited to 10 DNS lookups.
• DMARC step by step: Start at p=none, read the reports for two or three weeks to make sure everything that sends as you passes, then move to quarantine and then reject.
• Don’t delete the old provider’s records too early: Keep the old MX until switch day, and keep the old DKIM key published for a few days afterwards, because some messages signed with it are still in transit.

TTL and switch day

At least a day before the switch, lower the current MX record’s TTL to 300 seconds. Resolvers that cached the record for 3,600 or 86,400 seconds will ask again after just five minutes, so the switch reaches the world quickly, and you can roll back quickly if you need to. Once mail has settled on the new service, raise the TTL back to 3,600. We explain how DNS changes propagate in a separate article on the blog.

03Setting up mail apps

Most modern mail apps find their settings on their own when you type your address and password, as long as autoconfiguration records are published. If they don’t, these are the standard values, with the exact server names in your client area:

The username is the full address, such as rana@bayt-alluqaimat.com, and the outgoing server asks for authentication with the same password, so turn on “My outgoing server requires authentication” if the app asks.

Use IMAP, not POP3. IMAP keeps messages on the server and syncs folders and read status between phone and laptop, whereas POP3, in its usual setup, downloads messages to one device and deletes them from the server, so they vanish from the phone and fall outside your retention policy. And don’t send from mail apps over port 25: it’s the server-to-server port, and many internet providers block it. The submission ports 465 and 587 were designed for this, and both require authentication.

04Moving mail from the old provider

The plan that loses no messages copies the mail in two passes:

1. 01Create the new mailboxes, publish SPF, DKIM and DMARC, and keep the MX with the old provider.
2. 02Copy all the old mail into the new mailboxes. This is the longest stage, and it runs while the team works as usual.
3. 03On switch day, change the MX to the new service and ask the team to add the new accounts to their apps.
4. 04A day or two later, run the copy again to bring over whatever reached the old mailbox while the change propagated.
5. 05Keep the old account read-only for 30 days, then close it.

imapsync is the standard tool for moving mail between two IMAP servers: it copies folders, messages and read status, and doesn’t duplicate what it already copied, so you can run it twice without worry. It isn’t in the current Ubuntu repositories, so the easiest way to run it is its official Docker image:

# Put each account’s password in its own file instead of on the command line, e.g. old-rana and new-ranamkdir -p "$HOME/imap-pass" && chmod 700 "$HOME/imap-pass"# The first run is a dry run: --dry shows what would be copied without copying anythingdocker run --rm -v "$HOME/imap-pass:/pass:ro" gilleslamiral/imapsync imapsync \  --host1 imap.old-provider.example --user1 [email protected] --passfile1 /pass/old-rana \  --host2 imap.mail.example --user2 [email protected] --passfile2 /pass/new-rana \  --ssl1 --ssl2 --automap --dry# If the output looks right, run the same command without --dry, and repeat it after the switch

A 10 GB mailbox can take hours depending on the speed of both servers, so start the first pass two or three days before switch day, and repeat the command for each mailbox.

05Hardening after activation

• Passwords: A long, unique password for every mailbox, used for no other service and kept in a password manager. Turn on multi-factor authentication for every account wherever it’s available.
• Forwarding rules: Review them in every mailbox each month. An attacker who steals a password usually creates a silent rule that copies mail to their own address, and it keeps working after you change the password.
• POP3: If nobody needs it, don’t configure it on any device: every protocol you don’t use is one more door for password guessing.
• DMARC to reject: After weeks of clean reports, tighten the policy to quarantine and then reject, so anyone spoofing your domain gets turned away.

06Verify everything

# The records as the world sees themdig +short MX bayt-alluqaimat.comdig +short TXT bayt-alluqaimat.com | grep spf1dig +short TXT _dmarc.bayt-alluqaimat.com# The DKIM key: replace selector with the one shown in your client areadig +short TXT selector._domainkey.bayt-alluqaimat.com# The IMAP server’s certificate and TLS versionopenssl s_client -connect imap.mail.example:993 -servername imap.mail.example -brief </dev/null

Then send a message from your new account to a Gmail address and open it with “Show original”: you should see PASS next to SPF, DKIM and DMARC. To watch the new MX record reach the world, use Illevante’s DNS propagation checker, and to check the certificate of the IMAP server on port 993 or the sending server on 465, use the SSL certificate checker.

ProblemNew messages arrive in the old mailbox after the switch

FixSome resolvers still cache the old MX until its TTL runs out. Wait, then run imapsync a second time to bring over what arrived there.

ProblemThe app receives fine, but sending fails with an authentication error

FixTurn on “My outgoing server requires authentication”, and check that the username is the full address and that port 465 or 587 uses the matching encryption.

Problemimapsync can’t log in to the old provider although the password is right

FixMany providers disable IMAP by default, or require an app password when multi-factor authentication is on. Enable IMAP or create an app password.

ProblemDMARC reports show the invoicing system sending as you and failing

FixAdd its server to the SPF record or enable DKIM for it before you tighten the policy, or your invoices will be rejected along with the impostors’ mail.

07Go-live checklist

When you activate the service, work through this list in order, and don’t move to an item until you’ve confirmed the one before it:

1. 01The address plan is written down and agreed.
2. 02Mailboxes, aliases and shared mailboxes are created.
3. 03SPF, DKIM and DMARC are published, and the MX record’s TTL is lowered to 300 seconds.
4. 04The first pass of old mail is copied.
5. 05The MX is switched, and the team’s apps use IMAP on port 993 and SMTP on 465 or 587.
6. 06The second pass is copied, and the test message shows PASS three times.
7. 07Weeks later: DMARC is at reject, and the old account is closed.

Until the service is activated, you can finish the first item today and publish DMARC at p=none on your current email. That way you reach switch day already knowing everything that sends as your domain.