Shared-hosting mail vs real mail infrastructure

Your hosting plan came with unlimited email accounts, so you used them. It was already paid for, it took ten minutes to set up, and for two years it worked fine.

Then delivery got patchy. Not broken — patchy. Mail to one customer arrives, mail to another lands in junk, and next month it's the other way round. Nothing you changed caused it, which is the tell: nothing you did caused it.

What "email included" actually is

A shared hosting plan is one physical server running one mail daemon, serving every website on the machine. Depending on the host that's a few hundred domains or a few thousand. They all send from the same IP address, they all share one queue, and they all inherit the same reputation.

You can see how that goes wrong. If a neighbor on the box runs a badly configured newsletter, gets a plugin compromised, or simply signs up a lot of purchased addresses, the receiving world starts distrusting the IP. Nobody at Gmail is evaluating you individually. You are a domain sending from an address that has recently been used for junk, and you get treated accordingly. That is why the patchiness has no correlation with anything you did — because it isn't about you.

Two structural problems come with it. Your website and your email fail together. One suspension, one billing lapse, one hacked plugin, and both go dark simultaneously, at the same vendor, on the same support queue. And you get no operational visibility. When a message doesn't arrive there are no logs you can read, no bounce classification, no complaint feedback. You get "it's not on our end" from a support agent who has no more access than you do.

The part nobody reads before pasting it in

Here's the one that genuinely matters, and it's hiding in a record you copied from a knowledge-base article. A shared host will tell you to publish something like:

v=spf1 +a +mx +ip4:203.0.113.10 ~all

Read what that says. The a mechanism authorizes the IP your domain's A record points at. The mx mechanism authorizes your mail exchangers. The ip4 authorizes the server outright. All three resolve to the same shared machine.

You have just published a public statement that every tenant on that server is authorized to send mail as you. Not conceptually — mechanically. If someone's WordPress install three accounts over gets compromised and starts sending invoices with your domain in the From line, that mail comes from the authorized IP. SPF passes. Alignment is fine, because the envelope sender is your domain. DMARC evaluates it and returns a pass. Your p=reject policy waves it straight through, and your DMARC reports show it as legitimate traffic.

That is the difference that people miss when they compare shared hosting mail to a real platform on price. Authentication on shared hosting authenticates the building, not you.

The same logic applies to the DKIM key. On most shared setups the signing key is generated and held by the host, on the host, for you. It proves the message came off that server. It does not prove it came from you.

What real mail infrastructure means

Not a brand — a set of properties. A mail platform worth moving to gives you:

• A sending path separate from your website. Whatever happens to the site, mail keeps flowing. They fail independently because they are independent.
• Authentication that identifies you specifically. A DKIM key issued for your domain, on infrastructure where your SPF record authorizes a sending service rather than a machine full of strangers.
• Reputation that reflects your own sending. Either a dedicated IP or a properly managed pool where the operator polices its senders — which shared hosts, structurally, do not.
• Bounces and complaints handled as data. Hard bounces suppressed automatically, complaint feedback loops wired up. Repeatedly mailing dead addresses is one of the fastest ways to damage a domain.
• Logs you can actually look at. "Did it leave, was it accepted, was it deferred, why" — answerable in under a minute.

Google Workspace and Microsoft 365 clear that bar for most small businesses and are the right answer for most people reading this. Running your own on top of a transactional sending service is more work and buys you control and cost that only pay off at volume. Either is a real answer. Neither costs much more than the "free" mailboxes once you count an afternoon of lost orders.

When shared hosting mail is fine

Honestly: when the mail doesn't matter. A hobby site's contact form, an internal alias forwarding to a personal address, a domain that sends a dozen messages a month to people who already know you. Don't move that. It works.

Move it when mail is how you get paid. Invoices, quotes, booking confirmations, order receipts, password resets for your own systems — those are the messages where a spam folder costs real money, and they're exactly the ones being pushed through a shared queue on a stranger's reputation.

Curious what your domain currently tells the world about who can send as you? Run the free check and read the SPF line back.