Skip to main content

Mail & DNS

Email hosting for small business — Company e-mail is a handful of DNS records and one renewal date

Mail does not live where your website lives, and knowing which record controls which is the difference between a clean move and a fortnight of bounces.

The short answer

Treat mail as a property of the name rather than of the website: mailboxes on your own domain, included with the hosting plan, or the standalone Email Hosting product on its own where the website lives with another provider.

The working sits below: which record directs delivery, which records decide whether you are believed, and the order to change them in so no message is lost.

By the Hosting & Domains team · Reviewed 24 August 2026

24/7

Answers, any hour

1-click

App installs

Free

SSL on every name

Daily

Copies, all plans

Estimates arriving from free webmail addresses get quietly discounted by whoever receives them, which makes an address on your own domain the cheapest credibility a small firm will ever buy.

It is also the part of the domain with the least tolerance for a careless change. A website that stops answering is embarrassing for an hour. Mail that stops being delivered, or that starts being rejected as forged, costs you orders you never hear about.

Mail does not live where you think it lives

The website is found through an A record. Mail is found through MX records, and the two are independent lines in the same zone. Nothing about hosting a site here obliges you to host mail here, or the other way round.

That independence is the single most useful fact in this whole subject. It is what lets a website move host without a mail gap, and what lets mail move platform without touching the website.

It also means somebody has to own the zone knowingly. If your website provider rebuilds a zone during a migration and copies only the web records, your MX lines disappear and mail begins bouncing at the sender's end, where you cannot see it.

The records that decide whether you are believed

MX gets a message to the right server. Three TXT records decide whether the receiving side trusts it.

SPF lists which systems are permitted to send as your domain. Miss out the newsletter tool or the accounting software and their messages start failing checks even though the mailboxes are fine.

DKIM publishes a signing key so a receiver can verify the message really came from something you authorised, and that it was not altered in transit.

DMARC tells receivers what to do when SPF and DKIM disagree, and can ask them to report back. All three are published under your own domain, which is why deliverability follows the name rather than the provider — and why it survives a change of host.

Moving mailboxes without losing a message

Create the mailboxes at the destination first, with the same addresses. Nothing is being switched yet.

Copy the mail across over IMAP, folder for folder, while the old mailboxes are still receiving. Then check a few accounts by hand — sent items and subfolders are what get missed.

Lower the TTL on the MX records a day beforehand. Then change MX. Senders whose resolvers still hold the old answer will deliver to the old server until that TTL expires, so leave the old mailboxes live and collected for a fortnight and copy anything that lands there afterwards.

We run the transfer alongside you and your address keeps working throughout, because DNS only changes once the copy has been checked.

What we would buy

If the website is here, nothing extra: mailboxes on your own domain are already in the hosting plan, with webmail in the browser and IMAP, POP and SMTP for any client, plus spam and virus screening on by default.

If the website lives with another provider, or has not been built, the Email Hosting plan covers the case on its own — mail on a name you own instead of one you borrow, with the same protocols and the same filtering.

Either way the authentication records are yours to publish, and MailChannels handles outbound delivery so your messages arrive rather than being filed as suspicious.

The renewal that takes the mail down with it. An expired registration does not just take the website off the internet. It removes the MX records with the rest of the zone, at which point mail to your firm stops being delivered anywhere.

Worse, the bounces happen at the sender's end. Your customers see a failure notice; you see silence, which is the reason expiry is usually discovered late.

Auto-renew on, an in-date card behind it, and renewal notices going to a role mailbox that more than one person reads. If the notice address is a mailbox on the domain that just expired, nobody will read the warning either.

Mail landing at an address that carries the domain rather than a free provider

Deliverability belongs to the name, not to us

SPF, DKIM and DMARC are published under your own domain, so the reputation you build travels with the name if you ever leave. That is deliberate: a provider that owns your sending identity owns you.

A copy is taken daily on every plan, and putting a file or a database back is one click in the panel rather than a support ticket.

  • MX, SPF, DKIM and DMARC editable in the panel
  • IMAP, POP and SMTP on every mailbox
  • Mail moved alongside you, DNS changed last
  • Authentication published under your own domain

Why Hosting & Domains

Standard on every plan

Mail that survives a change of host

MX is independent of the website's A record, so moving one never obliges you to move the other.

Authentication you own

SPF, DKIM and DMARC published under your own domain — the sending reputation follows the name, not the supplier.

This page's conclusion, orderable

The Email Hosting plan is this page's conclusion in product form — one rate, essentials inside, upgradeable in place.

Every client, no ritual

Webmail in the browser plus IMAP, POP and SMTP, so the phone, the desk and the browser show the same messages in the same state.

An import run alongside you

Mailboxes created first, mail copied over IMAP, MX changed only once you have checked the copy.

Checkable before you commit

Azaanex Inc., federally incorporated in Canada — a filing you can read before you route your company's mail through anybody.

Quick Start

Order placed to site online

  1. 1

    Write down the current mail records

    MX with priorities, the SPF line in full, any DKIM selectors, the DMARC policy, and the TTL on each. Reconstructing these from memory is where mail migrations go wrong.

  2. 2

    Create and fill the new mailboxes first

    Same addresses, copied over IMAP while the old ones still receive. Check sent items and subfolders by hand before you trust the copy.

  3. 3

    Lower the TTL, change MX, then wait a fortnight

    Old mailboxes stay live and collected while caches expire. Anything that lands there gets copied across, and nothing is lost.

Built In

Fitted to every plan

  • Mailboxes that answer at the name you hold
  • Webmail in the browser plus IMAP, POP and SMTP for any client
  • MX, SPF, DKIM and DMARC editable in the panel
  • Spam and virus screening on every mailbox by default
  • MailChannels getting your outbound mail delivered
  • The mail import run alongside you, with DNS changed last
  • People on the support desk every hour of every day
  • Money back within 30 days on hosting plans, 7 on reseller
  • cPanel, which is what most of the industry already runs
  • Upgrades applied in place, with no migration when you change plan

Frequently Asked

Questions we field again and again

The website is with another provider. Can the mail still be here?

Yes, and it is a common arrangement. Mail follows the MX records, the website follows the A record, and they can point at entirely different companies. You either keep the zone where it is and change only MX, or move the zone here and recreate the web records — the first is less work and less risk.

Why did our mail stop the day the domain moved?

Almost always because the zone was rebuilt at the new provider and only the web records were copied across. MX vanished, so senders had nowhere to deliver, and the bounces went to them rather than to you. The fix is the inventory you take before the move, not the panic afterwards.

What order should MX and the website be changed in?

Never together. Move the website first by changing the A record, leaving MX alone. Then, as a separate job, create and fill the new mailboxes, lower the MX TTL, change MX, and keep the old mailboxes collected for a fortnight while resolvers let go of the old answer.

Does an expired domain bounce mail or hold it?

It bounces, at the sending end, which is the dangerous part — you get no notification at all. When the registration lapses the zone stops being answered, so there are no MX records for a sender to use. Roughly thirty days of grace follow, then redemption at a steep fee. Auto-renew and a notice address somebody actually reads prevent the whole episode.

Keep reading

  • Email Hosting

    Mailboxes on the name you hold, for one flat rate, wherever the website is hosted.

  • Domain Names

    Search, register and transfer names — with the MX records in your own hands afterwards.

Changing provider? Work through this checklist beforehand.

A straightforward running order for a migration your visitors never spot: which files travel first, how to bring the mail across without dropping a single message, the right moment to repoint DNS, and the two errors that sit behind almost every outage we get called in to fix.

You get the checklist, followed now and then by a note on keeping a site responsive. Unsubscribe whenever you want; the privacy policy covers the rest.

Mail on a name you hold.

MX, SPF, DKIM and DMARC in your own hands, an import run alongside you, and people answering at any hour.

View Email Hosting plans