A business email address is infrastructure, not a mailbox

A company's address is not the subscription that whoever set it up happens to own. It is the line customers answer, the sender on every quote, and the recovery address for the accounting system. Register the domain in the company's name and the address outlives the person in front of it; leave it on a personal free mailbox, and the day that account is locked the business stops answering.

What does a mailbox on your own domain give you that a free one does not?

Control over the address rather than over a login. On your own domain you decide which addresses exist and who receives each one; a free mailbox rents a seat inside somebody else's namespace, where the account belongs to the individual and the company's claim on it is a password one employee knows.

The difference is invisible while everything works, and it decides three ordinary situations: hiring a second person, replacing the first, and answering a customer two years later.

What the company holds	Free mailbox	Mailbox on its own domain
The address	Issued by the provider	Follows the domain you renew
A second person	Another account, another address	A new mailbox, or an alias
A departure	The inbox leaves with the person	The mailbox stays, reassigned

The claim is not philosophical either: account recovery runs on a phone number the provider holds, entered by whoever created the account.

What is the difference between an address, a mailbox and an alias?

A mailbox is storage: a seat, a quota, a password, a place where mail accumulates and can be searched. An address is a string after the @ sign. An alias is a rule saying mail to this address lands in that mailbox; it holds nothing of its own, so deleting it deletes no history.

The distinction matters because companies buy an address and assume they have a mailbox. A sales address should be an alias pointing at a person's mailbox, so the address survives the person; an invoices address should point at two, so a week of leave does not delay a payment.

Sending as an alias is a separate permission, and the one that catches people: many providers accept mail to the alias and still put the individual's address in the From line, which is where the reply goes.

What happens to the inbox when the person who owns it leaves?

Whatever was agreed at setup, which is usually nothing. Three endings are common: the mailbox is deleted on the last day and customers bounce for a year; it is kept and nobody opens it; or it is forwarded to the person's private address, and company correspondence keeps arriving in an inbox it does not control.

What is inside is what nobody inventories: the reply chain with the largest customer, the price agreed in March, the recovery link for the hosting panel, the codes for the bank portal. That is also why the mailbox is the objective of an account takeover rather than a way in, as guidance on phishing and protecting accounts frames it.

Handover is a procedure, not a conversation: reassign the mailbox to a role address, forward it for a stated period, change every recovery address that pointed at it, remove the mail app from the departing phone. Contingency planning guidance starts from the same place: the plan is written for the day a dependency disappears, and one person holding the only login is a dependency.

Why does the mailbox need its DNS records from the first day?

An address that can receive but cannot prove it sent is half an address, and two records carry that proof.

SPF is one TXT record naming the servers permitted to send for the domain. The receiver compares the machine that connected against that list, so it has to cover the mail server and every system that sends for you: the invoicing tool, the newsletter, the website form, the monitoring alerts.

DKIM is a signature. Each sending system signs the message with a private key, the matching public key is published in DNS under a selector, and the receiver checks that a system holding your key signed it and that the content did not change on the way. It survives forwarding, which SPF does not.

They must exist together because a receiver reads both answers: the path the mail arrived by, and whether the message is intact. A sender added in six months — a new invoicing platform, a script nobody remembers — is a new record and a new key, and nothing warns you until that mail is refused. DMARC is the policy layer above the pair, and has a piece of its own.

In what order do you move a business off a free mailbox?

1. Confirm the domain is registered in the company's name, with a card that is not an employee's and a contact address the company controls.
2. Decide who holds the admin login: a company account, two named administrators, a recovery route that is not the mailbox being set up.
3. Create one mailbox per person, then aliases per function — sales, invoices, support — each pointing at one or two real mailboxes.
4. Publish SPF and DKIM for every system that sends, and record which selector belongs to which system.
5. Migrate the history, not just the address. Import the old mail so reply chains and attachments survive, and keep the old address forwarding for a fixed period with a date to switch it off.
6. Test from outside: send from an unrelated account, read the authentication results in the headers, confirm a bank password reset arrives, and write down who can reset what for somebody other than the person who built it.

Where this goes wrong

• The domain is registered by the web developer, so mail, site and DNS share one login nobody at the company holds.
• One inbox for the whole company. Six people know the password, and nobody can say who read the quote.
• A role address created as a mailbox, so when its owner leaves the address is deleted and customers bounce for a year.
• SPF published once at migration and never touched when the invoicing tool moved provider.
• Mail migrated, contacts and calendar left behind, so the new mailbox looks empty on the first morning.

What this does not cover

This is about the address existing, belonging to the company, and surviving a handover. It does not pick a provider, compare quotas or discuss price, and it says nothing about retention obligations for business correspondence, which differ by country and belong with your accountant. Self-hosting mail is a different trade — blocklists, deliverability, somebody on call — and reasonable only when there is a reason for it. Nor does it cover the shared calendars and file storage that arrive with a mailbox.

We set up domain mail inside the company's own accounts, publish the sending records before the first invoice goes out, and write the handover down, because an address that leaves with an employee was never the company's.