Email hosting setup: a practical setup guide for 2027

Publishing the right records is the part of a mail setup that gets written about. 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 work. It assumes the records themselves 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 get confused and should not be: who owns the domain name, who runs its DNS, and who hosts the mailboxes. Any one of them can be moved without the others, and only if you kept them separable.
• Create a break-glass administrator account before you need it, and store its credentials somewhere that does not depend on the mail you are setting up.
• Turn off the old sign-in methods on the first day. Retiring them later means breaking things people already rely on.
• Your mailbox host is not a bulk sending platform. Decide where marketing and automated mail will go before someone sends the first newsletter through it.

Three roles, and why they should stay separable

The registrar holds the domain name. 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.

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.

Turn off what you do not intend to use

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.

• Older sign-in methods that carry a password directly and cannot enforce a second factor. These are the reason an account with a second factor still gets taken over. The relevant detail is that they are usually enabled by default and quietly used by an old device somewhere.
• Protocols you have decided not to support. If everyone uses the browser and the mobile app, direct client access does not need to be on for everyone.
• Automatic forwarding to outside addresses, on by default in many places, and the standard tool for quietly copying an inbox after a compromise. The security page covers why this one matters more than its obscurity suggests.
• Sign-in from places you do not operate in, where the host offers that control and your working pattern makes it realistic.

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.

• Send and receive with an address outside the organization, in both directions, from a real account rather than an administrator's.
• Send to a distribution address and a shared address, and check who actually received it.
• Send a message that should be filtered, and find where it lands, who can release it, and whether anyone is told it exists.
• Send an attachment at the size your team actually uses.
• Sign in from a phone, on mobile data rather than the office network.
• Deliberately fail a sign-in a few times, and see what appears in the log.
• Ask the host, in writing, what an administrator can export without contacting support. Then run that export and open the result on a machine that has never touched the service.

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, and 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.