Email hosting security: risks, controls and a 2027 checklist

Most mail security advice is about the mailbox. Hosting introduces a second layer that sits underneath it, and an attacker who reaches that layer does not need anyone's password at all.

Point a domain somewhere else and every message intended for the organization arrives at a stranger's server, correctly delivered, with no warning to the sender and no trace in your inbox. That is not a mailbox compromise, and nothing you enforce on mailboxes prevents it. This page is about the layer underneath: what depends on your provider, what depends on your own control plane, and what you can actually verify.

What to take away

• Whoever controls the domain name controls the mail. Protect that account harder than any mailbox.
• Some of your security is your provider's, and you cannot inspect it. Judge it on evidence of behavior rather than on a list of certifications.
• The provider's backup exists to protect the platform. A deletion you make propagates into it, so decide separately how you would recover mail somebody deleted.
• Old records that point at services you no longer use are a live risk, not clutter. Remove them.

The layer under the mailbox

Three things sit below your accounts, in decreasing order of consequence.

The domain registration. Losing it is the worst outcome available in this category. Mail can be redirected, certificates can be obtained, and the accounts that use the domain for recovery can be reset by whoever now receives that mail. Lock the domain against transfer where the registrar supports it, require a second factor on that account, use a recovery address that is not at the domain itself, and diary the renewal so it cannot lapse. More than one person must be able to reach it.

The DNS operator. Whoever answers questions about your domain can change where mail is delivered without touching the registrar. Access to that console is equivalent to access to your mail, and it is routinely handed to web developers and left with them for years.

The hosting console. From here mailboxes can be created, forwarded, exported, or granted to somebody else. The console setup covers how to structure access to it; the point here is that this is a security boundary and should be reviewed like one.

The habit worth building is a short quarterly check: who can reach each of the three, when they last did, and whether any of them still needs to.

Stale records are an unlocked door

DNS accumulates. A record for a service you stopped using two years ago still points at an address at a hosting company, and that address will eventually belong to somebody else.

What that gets an attacker varies from a page on a name that looks like yours to, in the worst cases, the ability to obtain a certificate for a name at your domain or to receive mail sent to it. None of it is exotic and all of it is preventable by a task nobody schedules. Knowing what you own and removing what you no longer use is the first of the 10 steps to cyber security for a reason: it is dull, it is cheap, and it closes more doors than anything you can buy.

Once a year, list every record at your domain and account for each one. Anything you cannot explain gets removed rather than kept in case. Pay particular attention to records left over from a previous provider, from a marketing campaign, from a trial that ended, and from any service that once sent mail on your behalf, which is the same list you built for the sender inventory.

What is your provider's problem and what is yours

Some controls are entirely theirs, and you cannot audit them. Judging them is still possible, on evidence rather than assurance.

Their side	What you can actually check
Physical and platform security	Independent assessment reports, and whether they will show you one under an agreement
Staff access to customer mail	Their written policy on it, whether administrative access is logged, and whether you can see those logs
Patching and platform maintenance	How changes are announced, and how past incidents were described afterward
Isolation between customers	Whether the platform is shared, what a neighbor's compromise could reach, and what the operator assessment turns up about their record
Transport encryption between mail systems	Whether they support requiring it, and whether you can publish a policy that asks other systems to
Encryption of stored mail	What it protects against, which is theft of the underlying storage, and not an attacker who has your password

That last row is worth stating plainly, because storage encryption is the most oversold control in the category. It defends against a threat that is real for the provider and nearly irrelevant to your day to day risk. An intruder using a valid session sees plaintext regardless.

Backups are not what most people assume

The provider almost certainly has backups. They exist so the provider can restore the platform after a failure at their end, and that is a different problem from yours. The scenario that exposes the difference is mass deletion or encryption reaching your mailboxes through a compromised account, which unfolds in a well documented way described in ransomware guidance and is a recovery problem rather than a filtering one.

Establish three things before you rely on anything:

• Can a single mailbox, or a single folder, be restored? Platform recovery restores everything to a moment. Recovering one person's mail from last Tuesday is a separate capability that may not exist on your tier.
• How long does a deletion survive? When somebody empties a mailbox, that change flows into the provider's copies after a defined period. Beyond that window the mail is gone, and this window is often much shorter than people assume.
• Would you survive losing the account itself? A billing dispute, a suspension, or a compromise of your own console can put your mail out of reach while the account still exists. A periodic export you hold yourself is the only answer to that, and it is one you can arrange today.

Retention and archiving are frequently sold separately, which is why they appear as their own line in a cost model rather than as a feature you assume is included.

What you can do while the provider is having a bad day

You cannot fix their platform. You can prepare for the hours during which it is broken.

• Know where to get authoritative status information, and confirm it is not served from the infrastructure that would be down.
• Have a way to reach your team that does not depend on the mail system, agreed in advance rather than improvised.
• Know who is authorized to make an emergency change to where mail is delivered, and make sure at least two people can.
• Understand what happens to mail sent to you while you are down: most sending systems retry for a period, so an outage of a few hours usually delays mail rather than losing it. Knowing that is worth a great deal to whoever is answering the phone.
• Keep a record of your own configuration, so that rebuilding elsewhere is a task rather than an archaeology project.
• Decide in advance what would make you leave, and check that your export capability still works before you need it. That decision belongs beside your migration plan rather than in the middle of an incident.

Common questions

Is a certification enough to establish that a provider is secure?

It establishes that a defined scope was assessed at a point in time. Read what the scope covered, because it often excludes the part you care about. Certification is evidence, not a conclusion.

Should we require encrypted delivery from everyone who mails us?

Requiring it improves privacy in transit and can cause mail from badly configured senders to fail. The usual approach is to publish a policy in a mode that reports rather than enforces, read the reports for long enough to see the exceptions, and then tighten. That sequencing is the same discipline that applies to publishing any sending policy.

How much does shared infrastructure actually cost us in security terms?

Less in direct compromise than people fear, and more in dependency than they expect. Your realistic exposure is that the platform is a bigger target, that a neighbor's behavior affects delivery, and that an incident affecting the platform affects you whether or not you were the target.

Who should own this in a small organization?

One named person with a quarterly reminder, and a deputy who can act if they are away. Almost everything on this page is an annual or quarterly check that takes under an hour. The failure is never difficulty; it is that these tasks belong to nobody until the day they belong to everybody.