Business Email Hosting in Belize, On a Server You Own

If your organisation's email came bundled with your website package, you are almost certainly on shared hosting, which means a server you rent a slice of alongside hundreds of other sites. That arrangement is cheap and it works right up until it doesn't. This post is about business email hosting in Belize when you decide to stop renting mailboxes and run the mail server yourself, which is exactly what I did for my own domain.

I run Mark Logic Development out of Belmopan and I have been building and operating software here since 2008. Alongside client work I manage Systems Development and Data Processing at the Statistical Institute of Belize. The mail server described here is not a thought experiment. It is the one my own business runs on, and the one my applications send from.

What goes wrong with email on shared hosting?

Nothing, at first. You get mailboxes, a webmail page, and someone else worries about the hardware.

The problems show up later, and they tend to be the same ones.

• You share a sending reputation with every other customer on that server. If one of them sends bulk mail carelessly, your invoices start landing in spam folders.
• Mailbox size limits are tight, and the fix is usually a bigger plan rather than more storage.
• Your applications, the booking form, the payroll system, the school portal, all send through the same address as your staff, so a burst of automated mail drags down the reputation of the address you use to talk to the bank.
• Spam filtering is generic. It does not learn from what your particular staff mark as junk.
• You cannot see the delivery logs, so when a client says "I never got your email", nobody can tell you whether it left the building.

None of that is a scandal. It is simply the limit of a product designed to be cheap for thousands of customers at once.

What does a self-hosted mail server actually include?

When I moved my own domain, I built the server on two well established pieces of open source software. Postfix handles sending and receiving mail between servers. Dovecot stores the mailboxes and serves them to your mail programme.

What came with it:

1. Every mailbox copied across without loss. Folders, read and unread state, years of history. The migration is a copy, not a restart.
2. IMAP and SMTP over TLS. IMAP is the protocol that keeps a mailbox in sync across your laptop and your phone. SMTP is the protocol that sends. TLS is the encryption that wraps both, so nothing travels in plain text.
3. Webmail. A browser page for staff who do not want to configure anything, and for when someone is on a borrowed computer.
4. Automatic configuration for Thunderbird and Outlook. Staff type an address and a password and the mail programme finds the right settings on its own. No printed sheet of server names.
5. Server-side spam filtering that learns. When a user drags a message into the Junk folder, the filter is trained by that action. It gets better at recognising the rubbish that targets your particular organisation.
6. Separate sending identities for applications. Each system gets its own no-reply address or alias, so automated mail is kept apart from the mail your people write by hand.

It also means the logs are yours. When delivery fails, I can read the exact reason the receiving server gave.

Will my mail still reach Gmail and Outlook inboxes?

This is the question that matters, and it is the one most people skip past. Running your own server does not automatically earn you a place in the inbox. You have to prove the mail is genuinely yours, using three records published in your domain's DNS, the public directory that tells the internet where your domain lives.

• SPF lists which servers are allowed to send mail for your domain. Anything else is suspicious.
• DKIM signs each message cryptographically, so the receiving server can confirm it was not altered in transit.
• DMARC tells receiving servers what to do when SPF or DKIM fails, and asks them to send you reports.

I set all three up for my own domain, and I set them up for clients whose applications send mail. Done properly, a self-hosted server delivers at least as reliably as shared hosting, because its reputation belongs to you alone.

Lessons I would pass on from my own migration

Four things cost me time, so they do not have to cost you any.

• Publish exactly one DMARC record. Two records, even if both look correct, cause receiving servers to ignore the policy entirely.
• Keep IPv6 out of the sending path unless it has reverse DNS. IPv6 is the newer internet addressing scheme. Reverse DNS is the lookup that maps an address back to a hostname. Large providers quietly reject IPv6 mail that lacks it.
• Check Google Postmaster Tools. It is a free dashboard showing how Google rates mail from your domain. It will tell you about a reputation problem before your customers do.
• Give every application its own mailbox or alias. When something misbehaves, you want to isolate it without touching staff mail.

Shared hosting or a server you control?

| | Shared hosting mailboxes | Mail server you control | | --- | --- | --- | | Sending reputation | Shared with strangers | Yours alone | | Storage | Plan limits | Limited by the disk | | Spam filtering | Generic | Trained by your staff | | Application mail | Mixed with staff mail | Separate identities | | Delivery logs | Not visible to you | Readable, with reasons | | Ongoing attention | None required | Patching and monitoring | | Best for | One or two mailboxes, no app mail | Organisations whose software sends mail |

That last row is the honest one. A server you own needs someone to keep it patched and watched. If nobody will do that, shared hosting is the better choice, and I will tell you so.

How long does a mail migration take, and does mail stop?

For a single domain with a normal number of mailboxes, plan on a few days of work spread across most of a week, because DNS changes need time to settle across the internet.

Mail does not stop. The new server is built and tested while the old one is still live, mailboxes are copied, and the switch is a DNS change that happens once everything has been proven. For a short period both servers accept mail and nothing is lost.

The mail server sits on the same kind of infrastructure as the rest of my work: my own Linux servers, firewalls and managed networks. If your offices are spread across towns, the same thinking applies to the network underneath, which I wrote about in connecting three offices into one business network.

Where to start

1. Count your mailboxes and list what sends mail. Staff addresses are easy. The forgotten ones are the website contact form, the accounting system and the booking engine.
2. Check what your domain publishes today. Ask whoever manages your DNS for the current SPF, DKIM and DMARC records. Many Belizean domains have none, or have two DMARC records by accident.
3. Decide who will mind the server. Internal staff, or an outside engineer on a standing arrangement. This decision comes before the technical one.
4. Give every application its own address before you migrate anything. It is useful on shared hosting too, and it makes the move simpler later.
5. Plan the switch for a quiet week. Not the week of payroll, enrolment or high season.

If you would like a second opinion on where your email sits now, or you want to see the range of work I take on, you are welcome to get in touch through the contact page. Everything I build is delivered with source code, documentation and in-app help, and the client keeps ownership.