An email hosting setup order: console first, mailboxes second, proof last

This is the part of an email hosting setup that gets written about: publishing the right records. The part that decides how the next five years go is duller: whose name the account is in, who can get into the control panel, and what happens on the morning the person who built it is unreachable.

This page is about the host side of the email hosting setup. It assumes the DNS records themselves—SPF, DKIM, DMARC, MTA-STS—are handled, and concentrates on the account, the console, and the limits you will meet later if nobody sets them now.

What to take away

Three roles, and why they should stay separable

The registrar holds the domain name—Namecheap, Cloudflare Registrar, GoDaddy, or your web host. This is the master key. Whoever controls it can point the domain anywhere, including at their own mail server, and no other control on this page survives losing it.

The DNS operator answers questions about where your services live. Often the registrar, often the web host, sometimes a third party. This is who you need at two in the morning when mail has to be repointed.

The mail host runs the mailboxes—Google Workspace, Microsoft 365, Zoho Mail, Fastmail, or Proton Mail.

Conflating all three into one supplier account is convenient and turns any dispute, outage, or offboarding into a crisis on three fronts at once. It also makes a future move harder than it needs to be, which matters more than it sounds when you read what actually breaks during a mail migration.

Whatever you choose, record for each of the three: the account it lives in, who has access, what the recovery address is, and when the renewal falls. Then check that the recovery address for the domain is not an address at that domain, because if mail stops you cannot receive the message that would let you fix it.

Set up the console before the mailboxes

The order here is deliberate. Every item is much easier before there are users.

Before configuring the accounts, decide what you will require of an authenticator and how somebody locked out gets back in. Those two questions are the whole of the digital identity guidelines on binding and recovery, and answering them on day one is much easier than retrofitting an answer later.

A break-glass administrator. One account that exists only to regain control. It is not anyone's daily account, it does not receive mail, its credentials live in a password manager that other people can reach, and its second factor is not tied to one person's phone. Test that someone other than the person who created it can sign in.

Separate administrative accounts from working accounts. Administration done from an account that also reads mail means every phishing attempt aimed at that person is aimed at your console.

Decide who else has access, and write down why. Web developers, agencies, and the friend who set things up originally all accumulate console access and never lose it. Give outsiders their own named accounts, never a shared one, and diary the date you will remove them.

Choose defaults deliberately. Default mailbox size, default warning thresholds, what a new account can and cannot do, whether new users may create forwarding rules to outside addresses. Defaults set now apply to everyone; defaults set later apply to nobody who already exists.

Find the logs before you need them. Know where sign-in history and administrative actions are recorded, and how long they are kept. Retention often depends on the tier, which belongs in your budget model rather than in an incident.

Provision mailboxes with the defaults already set

Once the console is configured, create the mailboxes. Do it in a batch, not one at a time, so the defaults from the previous section apply uniformly. For each mailbox: assign the user, set the primary and alias addresses, confirm the mailbox lands in the right group or organizational unit, and verify the recovery email is not at the same domain. Name the shared mailboxes (info@, support@, billing@) and decide who may send as them. Leave the break-glass account unprovisioned for mail; it exists only to reach the console.

Turn off basic authentication and unused protocols

A mail host arrives with more surface than you need. The first day is the cheapest time to reduce it. Settings are the same later; the number of things they affect is not, which is the practical argument running through the advice on using cloud services securely.

Each of these is a five-minute change now and a negotiation with an annoyed department later.

Quotas, warnings, and sending limits

Three limits will eventually interrupt someone's day. Set them consciously.

Mailbox size. Decide the ceiling, and decide what happens when it is reached: mail stops arriving, or old mail moves to an archive, or the mailbox simply grows and you pay. Set a warning threshold well below the limit, and make sure the warning goes somewhere a human reads.

Message size. The maximum attachment size is a number people meet weekly. Know yours, know that the recipient's limit also applies, and tell people what to do instead, which usually means a link from your file storage rather than a bigger attachment.

Sending limits. Every mailbox host caps how much a single account may send, per hour or per day, to protect the platform's reputation. This is the limit that catches organizations by surprise, because it is invisible until someone sends the annual customer mailing from their own mailbox, hits the cap, and gets the account suspended mid-send with no record of who received what.

The rule that follows is simple: personal correspondence goes through your mailbox host, and bulk or automated mail goes through something built for it. Set that boundary before someone discovers the wrong answer, and include it in the sender inventory described in the setup sequence.

Prove it works before you depend on it

Test while the old arrangement is still live, and test the things that fail quietly. At minimum: send a message from a new mailbox to an external address and confirm delivery; send one back and confirm receipt; run dig MX yourdomain.com to verify routing; paste a test message into mail-tester.com to score SPF, DKIM, and DMARC alignment; and confirm that the break-glass account can reach the console from a different network.

Finally, write down what you built: which records exist, which accounts are administrators, where the break-glass credentials are, what the limits are set to, and which outside parties hold access. One page, stored where it can be found by somebody who is not you.

Almost every genuinely painful mail incident in a small organization is made worse by the fact that the only person who understood the setup is on holiday. That is a documentation problem rather than a technical one. It is the same gap that makes an unplanned administration handover so expensive.

Common questions

Should mail and the website share a provider?

Separating them keeps one decision from forcing the other, and it means a website problem is not also a mail problem. Bundling is defensible for a very small team, provided the console gives you real administrative control and the exit is clean.

Who should hold the domain?

The organization, in an account the organization controls, with more than one person able to reach it. A domain in a former contractor's personal account is a common and entirely avoidable emergency.

How many administrators is right?

At least two humans, plus the break-glass account. One is a single point of failure; five is nobody paying attention. Review the list on a fixed date each year rather than when someone leaves.

What should be documented for the next person?

Where each of the three roles lives, who has access to each, what the recovery paths are, what limits are set, and what deliberate decisions were made and why. The reasoning matters as much as the settings, because the next person will otherwise undo something on purpose without knowing what it protected.