✉️ MapleMail
Getting started

Do I need email hosting if I already have a website?

One domain, two completely different jobs. The record that finds your website has nothing to do with the record that delivers your mail.

The sixty-second answer

Yes. Web hosting and email hosting are different services, found through different DNS records on the same domain: your site is reached through address records, your mail through MX records. Having a website gives you a domain, not a mailbox. The two can - and usually should - live with different providers.

One domain, two jobs

The confusion is understandable. You bought a domain, someone built you a site, and now yourbusiness.ca is a thing that exists on the internet. It seems reasonable to assume that [email protected] comes along with it.

It does not, because a domain is not a service. A domain is a name with a set of records attached, and different records answer different questions. When a browser wants your website, it looks up an address record. When a mail server wants to deliver a message to your domain, it looks up an MX record - and the mail standard is emphatic that this takes precedence: "if one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs", with the implicit-MX fallback applying "only if there are no MX records present" [1].

So the two services are wired independently by design. Your website can be on one continent and your mail on another. Neither knows about the other. What they share is the name and the DNS zone that holds both sets of records, each with its own type and its own cache lifetime [2].

This is good news, not a complication. It means you are never forced to buy your email from whoever happens to be hosting your site.

"Email included" - what to actually check

Plenty of web hosting plans advertise email. Some of them mean it. Before you rely on one, get answers to four questions in writing.

Are these mailboxes or forwards? The commonest form of "included email" is a forwarding rule: mail sent to [email protected] is relayed to a personal account elsewhere. That is not a mailbox. You cannot reply from the address, nothing is stored on your domain, and the arrangement has authentication side effects worth understanding - see shared inbox versus email forwarding.

How much storage does each mailbox get? A quota measured in hundreds of megabytes will be full within a year for any business that receives photographs or scanned paperwork. Work out your own number first with how much email storage a business actually needs.

Can I reach it properly from every device? The answer you want is IMAP over an encrypted connection, not webmail only. Implicit TLS for IMAP means the handshake begins as soon as the connection to the standard secure port opens, with certificate validation on the client side [4]. If a host offers only a browser interface, or only unencrypted access, that is a real limitation. Getting your business email on your phone and laptop covers the settings.

Is it billed per mailbox, and what counts as one? Aliases should not consume seats. How many email addresses your business actually needs is the counting exercise to do before you buy anything.

If the answers are "real mailboxes, adequate storage, IMAP over TLS, sensible billing", then your web host is running a mail service and you do not need another one. If the answers are vaguer than that, what you have is a forwarding rule with marketing on top.

The contact form is not email

A related assumption: the site has a contact form, so customers can reach us, so we are covered.

A form is a one-way channel. It gives your customer no address to save, no thread to reply into, and no way to attach a large file reliably. It gives you no way to send first - no quote, no invoice, no follow-up from a company address. And when the form message arrives in a personal account, every reply you send comes from the wrong place, which is the fastest way to look smaller than you are. The commercial case is set out in business email on your own domain versus a free address.

Forms also carry obligations of their own. Collecting a name and an email address is collecting personal information, and PIPEDA's Schedule 1 requires the purposes to be identified before or at the time of collection, requires the individual's knowledge and consent, and requires your policies and practices to be made readily available [6]. A form that silently dumps into an inbox nobody administers is a weak place for that information to land.

Why separating them is the safer arrangement

The strongest argument for buying email separately has nothing to do with features. It is about what happens on a bad day.

Websites get rebuilt. Designers get replaced. Hosting plans get cancelled for non-payment, or a host goes out of business, or you simply outgrow it. If your mailboxes live inside that hosting account, every one of those events is also an email outage - and email outages are the expensive kind, because the messages sent during them are usually gone for good.

Keep the two separable and a website migration is just a website migration: you change address records, the MX records stay untouched, and mail never notices. That single decision removes the most common way a small business loses its correspondence.

The same logic applies to the domain itself, which sits underneath both services. It should be registered in your business's name, in an account you can log into. ICANN's Transfer Policy states that Registered Name Holders "must be able to transfer their domain name registrations between Registrars" and that transfer processes "must be clear and concise", and requires that a transfer lock be removed - or an accessible removal method provided - within five calendar days [5]. That right protects you only if the registration is actually yours. What happens when it lapses is covered in what happens to your email if your domain expires.

The authentication that ties it together

One place the two services do touch: sending. If your website sends mail - form notifications, order confirmations, password resets - it is sending as your domain from infrastructure that is not your mail host. Receiving servers care about that. Sender authentication frameworks exist precisely to describe which infrastructure a domain authorises, including mail service providers that send on behalf of third-party domains [3].

So when you split web and email across two providers, the one piece of homework is to authorise both in your domain's records. It is a handful of DNS entries, done once. Skip it and your legitimate mail starts landing in junk folders for reasons nobody in your business will be able to diagnose. The plain-language walkthrough is SPF, DKIM and DMARC explained for small business, and the symptoms are in why business email goes to spam.

Where we sit

MapleMail is email hosting and nothing else. We do not host your website, we do not want to, and that is the point: your site can live wherever it suits you, with whoever built it, and your mail keeps working through it all.

What you get is Canadian-hosted mailboxes on your own domain, IMAP access over encrypted connections from any device, and the DNS records you need written out plainly so you or your web person can add them. If you already have mail somewhere and want to move it without a gap, switching business email providers without losing mail is the honest version of that process.

Current plans and what each mailbox includes are on the pricing page. Before you get there, though, do the cheaper thing first: ask your existing web host the four questions above. If they answer all four well, you do not need us, and we would rather you knew that.

Frequently asked questions

Do I need email hosting if I already have a website?

Yes, unless your web host is genuinely running a mail service for you. They are separate jobs found through separate DNS records: your website is reached through address records, while mail delivery follows MX records, and SMTP systems must use the MX records when any are present [1]. Having one does not give you the other.

My hosting plan says email is included. Is that enough?

Sometimes. Check three things: how much storage each mailbox gets, whether you can reach it by IMAP over an encrypted connection from every device, and whether the included service is real mailboxes or only forwarding to an address somewhere else. Forwarding-only is common and is not the same product.

Can my website and my email be hosted in different places?

Yes, and it is the normal arrangement. One domain can point its address records at a web host and its MX records at a mail host, because they are different record types serving different protocols [2]. Nothing about the two services requires them to share a provider.

Is a contact form on my website the same as having email?

No. A contact form sends you a message; it does not give you an address customers can write to, reply to, or keep in their address book, and it does not let you send from your domain. It also engages privacy obligations of its own - you must identify the purpose of collection, obtain consent, and make your policies readily available [6].

What breaks if I move my website to a new host?

Only your website, if the MX records are pointed at a separate mail service. If your email lives with the web host, moving hosts moves your mail too - which is exactly when businesses lose mailboxes. Keeping the two separable is the cheapest insurance available.

Why does my mail sometimes go to spam when my web host sends it?

Because sending mail for a domain requires that domain to authorise the sending infrastructure. Sender authentication frameworks exist specifically to cover providers sending on behalf of third-party domains [3]; if your website's form or your mail host is not authorised in your domain's records, receiving servers have reason to distrust it.

Who should hold my domain if my website and email are in different places?

You should, in your own registrar account, in the business's name. ICANN's Transfer Policy says registrants must be able to transfer registrations between registrars, and that a transfer lock must be removed or an accessible removal method provided within five calendar days [5]. That right is only useful if the account is yours.

Sources

  1. RFC 5321 - Simple Mail Transfer Protocol, section 5 — Only names 'that can be resolved to MX RRs or address (i.e., A or AAAA) RRs' are permitted in SMTP. 'If one or more MX RRs are found for a given name, SMTP systems MUST NOT utilize any address RRs associated with that name unless they are located using the MX RRs; the implicit MX rule applies only if there are no MX records present.'
  2. RFC 1035 - Domain Names: Implementation and Specification — Resource records carry a TYPE and a TTL, 'a 32 bit unsigned integer that specifies the time interval (in seconds) that the resource record may be cached before it should be discarded'; a zero TTL means the record may be used only for the transaction in progress.
  3. RFC 7208 - Sender Policy Framework (SPF) — Appendix E covers mail service providers offering mail services for third-party domains, and Appendix D.2 explains that mediators handling forwarded mail can rewrite the MAIL FROM into their own domain, with schemes that 'vary widely in complexity and resource requirements'.
  4. RFC 8314 - Cleartext Considered Obsolete: Use of TLS for Email Submission and Access — Section 3.2 specifies Implicit TLS for IMAP: on a TCP connection to the 'imaps' service (default port 993) 'a TLS handshake begins immediately', and clients must implement certificate validation.
  5. ICANN Transfer Policy — Registered Name Holders 'must be able to transfer their domain name registrations between Registrars' and transfer processes 'must be clear and concise'. A lock such as ClientTransferProhibited must be removed, or an accessible removal method provided, within five calendar days.
  6. Personal Information Protection and Electronic Documents Act, Schedule 1 — Principle 2 (4.2) requires purposes to be identified before or at the time of collection; Principle 3 (4.3) requires knowledge and consent; Principle 8 (4.8) requires policies and practices to be made readily available to individuals.

All sources verified 2026-09-02.

MapleMail is Canadian-hosted business email on your own domain, independent of wherever your website lives.

See plans and pricing