Domains, Hosting and Business Email Without the Traps

Domain, hosting and email get bundled together, sold together, and treated as one purchase. They're three separate things, and most of the painful situations we're called in to fix come from not understanding where one ends and the next begins.

None of this is complicated. It's just rarely explained before something goes wrong.

The three things, separated

The domain is your address — the name itself. You rent it from a registrar, annually.
Hosting is the building — the server your website's files actually sit on.
Email is the postal service that happens to use the same address, and is very often provided by someone else entirely.

They can all come from one company, which is convenient right up until you want to change one of them.

The domain: own it yourself

This is the single most important thing in this article.

If your domain is registered in your developer's name rather than your business's, you do not control your own address. Fix that before it matters.

It's rarely malicious. Someone helpful set it up on their own account years ago, and now they've moved on, or the relationship ended awkwardly, or nobody remembers which email address the account uses. Meanwhile the renewal is coming.

What to check today:

The registrant is your business name, and the contact email is one your business still controls — not a personal address belonging to someone who left.
Auto-renew is on. Expired domains get bought quickly, and getting one back ranges from expensive to impossible.
You can log in to the registrar yourself. If you can't, you don't control it, whatever the paperwork says.
Registrar lock is enabled, which stops the domain being transferred away without your approval.

DNS: the part that confuses everyone

DNS is the lookup that turns your name into a location. It's why your website and your email can live in completely different places under the same domain.

The records worth recognising:

A — points the domain at a server address. This is your website.
CNAME — points one name at another name, commonly used for subdomains.
MX — where mail for this domain should be delivered. Entirely independent of your website.
TXT — free-form text records, used mostly to prove ownership and to authorise who may send mail as you.

Two practical notes. Changes are not instant — records are cached for a period set by their TTL, so allow time. And if you're planning a migration, lower the TTL a day or two beforehand, so the actual switch propagates quickly.

Hosting: what shared hosting is and isn't good at

Most small business sites sit on shared hosting, where many sites share one server. It's inexpensive and, for a normal business website, entirely appropriate.

Its real limits are worth knowing before you hit them:

Resources are capped, and a traffic spike can hit those limits.
You're sharing with strangers, so someone else's bad day can affect your performance.
You often can't install arbitrary software, which occasionally constrains what can be built.
Disk quotas include things you forget about — backups, logs, and old uploads quietly fill space until something fails for no obvious reason.

What matters more than the tier: automated backups you have actually tested restoring, a straightforward way to get a certificate for HTTPS, and support that answers.

Email: why yours goes to spam

This is the most common complaint we hear, and it's almost always the same cause. Receiving mail is easy. Being trusted when you send is the hard part, and it rests on three DNS records.

SPF lists which servers are allowed to send mail as your domain. If you send from your website, your mail host, and a newsletter tool, all three must be listed — and there must be exactly one SPF record.
DKIM cryptographically signs your outgoing mail so the receiver can verify it genuinely came from you and wasn't altered.
DMARC tells receiving servers what to do when a message fails those checks, and can send you reports about who is sending mail as your domain.

Without these, your mail is competing against enormous volumes of forged mail with nothing to distinguish it. With them, deliverability usually improves immediately.

Two specific traps

Sending as an address you don't authenticate. If your contact form sends mail claiming to be from the visitor's own address, you're asking receiving servers to accept mail from a domain you have no authority over. Send from your own address and set reply-to to the visitor's instead.

Certificate name mismatches. When your website connects to a mail server over an encrypted connection, the certificate presented has to match the hostname you asked for. Point your application at a hostname the certificate doesn't cover and it will refuse to connect — usually with an error that looks nothing like "you used the wrong hostname". Use the exact hostname your provider specifies, not a guess that looks tidier.

A checklist worth ten minutes

Domain registered to the business, with a contact address you control.
Auto-renew on, registrar lock on, and someone who can actually log in.
HTTPS working, with a certificate that renews automatically.
SPF, DKIM and DMARC configured — and re-checked whenever you add a new tool that sends mail.
Backups running, and one restore actually tested. An untested backup is a hope.
A written note of what is hosted where and who to contact. The moment you need this is the moment nobody can remember.

Almost every emergency we get called into is one of these six, unattended for long enough to matter. They're all cheaper to sort out on a quiet afternoon than on the day the site goes down.

If you're not sure where your domain is registered or whether your mail is properly authenticated, ask us — checking is quick, and it's better to know.