Features
Part of Shared, dedicated or self-run: comparing email hosting arrangements
Email hosting security starts below the inbox, at your DNS records
A practical 2027 guide to email hosting security: risks, controls and a 2027 checklist with current definitions, decisions, checks, and review steps.
Most mail security advice is about the mailbox. Hosting adds a second layer underneath it. An attacker who reaches that layer does not need anyone's password at all.
Point a domain somewhere else and every message for the organization lands on a stranger's server. Delivery succeeds, the sender gets no warning, and your inbox shows no trace. That is not a mailbox compromise, and no mailbox rule prevents it.
This page covers the layer underneath: what your provider controls, what your own control plane controls, and what you can verify. In email hosting security terms, that means the DNS records that decide where your mail is delivered, who may send as your domain, and which systems can obtain a certificate for it.
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.
Three layers below the mailbox
Domain registration
- Worst outcome
- Mail redirected
- Lock it
- Transfer lock
- Second factor
- Required
- Recovery address
- Off-domain
- Who can reach
- More than one
- Quarterly check
- Yes
DNS operator
- Worst outcome
- Mail rerouted
- Lock it
- Restrict access
- Second factor
- Required
- Recovery address
- Off-domain
- Who can reach
- Named owners
- Quarterly check
- Yes
Hosting console
- Worst outcome
- Mailboxes taken
- Lock it
- Review access
- Second factor
- Required
- Recovery address
- Off-domain
- Who can reach
- Named owners
- Quarterly check
- Yes
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. Turn on the registrar's transfer lock — the clientTransferProhibited status most registrars let you set — and ask for a registry lock where your registry offers one, which holds changes until an out-of-band process is completed. Keep the EPP authorization code out of shared folders: under ICANN's transfer policy it is the credential that authorizes a domain to move. Require a second factor on that account, use a recovery address that is not at the domain itself, keep your registrant contact details current in the WHOIS/RDAP record so renewal notices reach you, 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.
The records that decide what happens to your mail
The domain layer is made of records, and every one of them is a setting you can read and change:
- MXwhere mail for your domain is delivered. An MX pointed at the wrong host sends every message there.
- SPFand DKIM — SPF lists the systems allowed to send as your domain; DKIM adds a signature receivers can check. Both live in TXT records.
- DMARCthe policy receivers apply when SPF or DKIM fails. At
p=noneit only reports; atp=quarantineorp=rejectit enforces. Start by reading the reports sent to theruaaddress. - CAAnames the certificate authorities allowed to issue certificates for your domain, closing a common route to impersonation.
- DNSSECsigns your DNS answers so a forged response cannot quietly redirect mail or certificates.
- MTA-STSand TLS-RPT — require transport encryption between mail servers and report where it fails.
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, a certificate for a name at your domain or mail sent to it. None of it is exotic. 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 from the UK's National Cyber Security Centre, and for a reason: it is dull, it is cheap, and it closes more doors than anything you can buy.
Annual stale DNS record audit
- List every record at your domain
- Account for each record's purpose
- Remove anything you cannot explain
- Check records from previous providers
- Check ended trials and campaigns
- Check services that once sent mail
Check records left over from a previous provider, a marketing campaign, an ended trial, or any service that once sent mail for you. This is the same list you built for the sender inventory.
How to verify what is actually published
What you intended to publish and what your domain actually answers are not always the same. Two commands and one browser tab close most of the gap. dig (or nslookup on Windows) shows the live answers:
dig MX yourdomain.comwhere mail is delivered.dig TXT yourdomain.comSPF and other TXT-based records.dig TXT _dmarc.yourdomain.comyour DMARC policy; read thep=andrua=values directly rather than trusting a dashboard.dig CAA yourdomain.comanddig DNSKEY yourdomain.comCAA and DNSSEC settings.
A DNS checker such as MXToolbox runs the same lookups in a browser and keeps a history you can compare quarter to quarter. Run the checks after every change, and again on the quarterly review, because stale records rarely announce themselves.
What is your provider's problem and what is yours
Some controls are entirely theirs, and you cannot audit them directly. Judging them is still possible, on evidence rather than assurance. Ask for the artifact by name: an ISO/IEC 27001 certificate with its statement of applicability, or a SOC 2 Type II report listing the Trust Services Criteria it covered, the auditor who signed it, and the period it covers. A report from a named auditor for a named period is evidence you can weigh. A badge on a marketing page is not.
Provider's problem versus yours
Their side
- Physical security
- Independent reports
- Staff mail access
- Written policy
- Patching
- Change notices
- Customer isolation
- Shared platform
- Transport encryption
- Require support
- Stored mail encryption
- Storage theft only
What you can check
- Physical security
- Ask under agreement
- Staff mail access
- Are logs visible
- Patching
- Past incident writeups
- Customer isolation
- Neighbor compromise reach
- Transport encryption
- Publish policy
- Stored mail encryption
- Not password theft
Provider's problem and yours
| 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. That is a different problem from yours.
Can you restore your own mail?
Can a single mailbox or folder be restored?
Confirm tier supports it
Arrange periodic export
The scenario that exposes the difference is mass deletion or encryption reaching your mailboxes through a compromised account. It unfolds in a documented way described in CISA's ransomware guidance. This is a recovery problem, not 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.
Prepare for provider outage
- Find authoritative status source
- Agree out-of-band team channel
- Name two emergency mail changers
- Explain retry delays to callers
- Keep your configuration record
- Decide what triggers leaving
- Test export before you need it
- 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 switch it on in report-only mode first: an MTA-STS policy with TLS-RPT reporting for delivery, and a DMARC record at p=none with an rua= address for your own sending. Read the reports for long enough to see the exceptions, 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.
