Getting email on your own domain without a mail server

Most people discover that their "free" business email wasn't actually free the way everyone discovers it: an invoice for something called Wix Email or a Squarespace Professional Email lands twelve months in, at a price nobody remembers agreeing to. The mailbox was never a permanent feature — a first-year inclusion bundled into the plan, the same shape as the free domain covered in domains and hosting, explained without the registrar sales pitch, a promotion with a renewal date attached and dressed up as a feature.

The instinct at that point is to assume the fix is expensive: a mail server, a sysadmin, a monthly line item forever. It isn't, for most people. Getting mail at your own address is three genuinely different jobs wearing one name, and only one costs real money on a per-seat basis. Picking the wrong one is either a waste of money or a mailbox that quietly can't do what you assumed.

It's worth separating this from the website question entirely, because the two get bundled at checkout even when they have nothing to do with each other technically. If the site itself is the smaller decision — one person, one page, a portfolio or a CV turned into a page — reach is the strongest answer available: upload a CV and a photo, answer a short form, pick a look, and a finished site is generated in about twenty seconds, live at a free subdomain in under two minutes. But reach doesn't bundle email, and never pretends to: its contact section is a mail link, not a form, and there's no mailbox to expire on you a year in. Whatever address that link points to gets sorted separately, using one of the three routes below — the same three routes as anyone building on Wix, Squarespace or WordPress instead.

The three routes, and what they don't tell you upfront

Forwarding is the smallest commitment: mail sent to you@yourdomain.com is redirected, unopened, into an inbox you already have — Gmail, Outlook, whatever you already check. There is no new inbox, no new app, nothing to log into separately. Most registrars bundle a handful of forwarding addresses in with the domain itself at no extra charge, because forwarding costs the registrar almost nothing to run. This is the right answer for a surprising number of people: anyone who wants the look of a professional address, with no real need to manage mail in a second place. The limitation is that forwarding is receive-only — it gets mail to you, but replying from that address convincingly is a separate problem, covered below.

Mailbox hosting is a real inbox at your domain: its own storage, IMAP and SMTP access, nothing else bundled in. This tier exists for the person who wants to actually work from you@yourdomain.com — send, receive, search, keep a real archive — without paying for calendar sharing, shared drives or admin seats they'll never use. Pricing across this category moves often enough that printing a figure here would go stale within a season; check the provider's current page rather than trust a number from an article. Cheaper than a full suite, but it's one more login, and mailbox-only providers vary in how good their spam filtering actually is, which price alone won't tell you.

Full suites — Google Workspace is the example with a published, checkable price — bundle a mailbox with calendar, shared documents, video calls and an admin console for managing more than one address under the same domain. Business Starter is $7 per user per month on monthly billing, and committing annually brings that down by 16%. That's real money for a freelancer who only wants an inbox, but it stops being a strange purchase once a second person joins the account, or the calendar and document features are ones you'd pay for separately anyway.

Prices checked August 2026.

Route	What you get	Cost shape
Forwarding	Mail redirected into an inbox you already use	Usually bundled free with the domain
Mailbox hosting	A real inbox at your domain, nothing else	Per mailbox, per month — check current pricing directly
Full suite (Google Workspace)	Mailbox plus calendar, docs and admin tools	$7/user/month, Business Starter, billed monthly; annual saves 16%

For most people reading this because a builder's free-mail promotion just expired, forwarding is the honest answer, not the consolation prize.

MX records, and the order that keeps mail from vanishing mid-switch

An MX record is the DNS entry that tells the rest of the internet which server should receive mail for your domain — the mail equivalent of the A record that points your domain at a website, living in the same records panel but entirely separate from it. That separation is the single most useful fact in this whole subject: your website's hosting and your domain's mail have nothing to do with each other technically, even though they share one DNS control panel.

Changing MX records is the one part of setting up email where doing it in the wrong order costs you mail rather than just time. The sequence that doesn't lose anything: verify domain ownership with the new provider first — almost every mailbox and suite provider asks for a TXT record before it will accept mail for your domain, so that step has to land before mail can arrive regardless of MX — then add the new MX records without deleting the old ones yet, let DNS propagate, and send test messages to confirm the new provider is actually receiving before removing the old MX entries. Deleting the old provider's records too early is how people end up with a day or two of mail vanishing into a server that no longer exists and never bounces back to the sender. We go through the record types themselves in DNS records for non-technical people; this is the one sequence where getting the order wrong is genuinely costly rather than just slow to fix.

SPF, DKIM and DMARC are why mail lands in spam, not luck

Three more DNS entries, none optional if you plan to send mail people expect to read, and none related to receiving — these three exist purely to prove that mail claiming to come from your domain really did.

SPF (Sender Policy Framework) is a list, published in your DNS, of which servers are allowed to send mail on your domain's behalf. A receiving server checks the SPF record and, if the message arrived from a server not on the list, treats it as suspicious — exactly what a forged message from your address would look like, so the check does real work, not theatre.

DKIM (DomainKeys Identified Mail) attaches a cryptographic signature to outgoing mail, generated from a private key the sending provider holds and verified against a public key published in your DNS. Where SPF checks where a message came from, DKIM checks that it wasn't altered in transit and really was signed by a server your domain trusts. Every legitimate mailbox provider walks you through adding this record during setup; skipping it is a common reason a properly configured mailbox still lands in spam.

DMARC (Domain-based Message Authentication, Reporting and Conformance) is the policy sitting on top of both: it tells receiving servers what to do when a message fails SPF or DKIM — quarantine it, reject it, or just report the failure back to you — and it's the record most people skip because nothing visibly breaks without it. The cost shows up later, gradually, as a rising share of outgoing mail quietly filtered into spam with no error message telling you it happened.

All three live as DNS records, added once and then left alone. The provider you choose will hand you the exact values; the work is pasting them into your registrar's DNS panel correctly, not writing them yourself.

Sending from an alias in a normal mail client

Forwarding solves receiving. It does not, on its own, solve replying in a way that looks legitimate to the person on the other end. If you set your Gmail account to say your replies come from you@yourdomain.com without anything backing that claim, the message goes out with your domain's name in the From field but Google's servers actually sent it — precisely the mismatch SPF exists to catch, and a strict SPF policy on your domain can cause your own replies to fail delivery or land in spam.

The fix most mail clients support is a "send mail as" feature that routes outgoing mail through an SMTP server you authorise — either the mailbox provider you're forwarding from, or a full mailbox's own SMTP credentials — so the message is genuinely sent by a server your SPF record permits. Gmail's version lives under Settings, Accounts, "Send mail as"; Outlook's equivalent sits in connected-accounts settings. Configured correctly, replies from the alias pass SPF and DKIM the same way mail from a real mailbox does, because as far as the receiving server can tell, that's exactly what happened.

What breaks when the website moves and the mail doesn't come along

This is the failure mode worth naming directly, because it happens quietly and the person it happens to usually doesn't notice for days. Someone switches website builders, or moves DNS management from the registrar to a new host, and copies over only the record they were focused on — the A record pointing at the new site. Mail records live in the same DNS zone but serve a completely different purpose, and nothing in a typical hosting checklist flags them as related.

The result isn't an error message. It's silence — mail sent to the domain either bounces immediately, with the sender getting a notice you never see, or sits queued at a server retrying delivery, eventually giving up and telling the sender, not you. The gap between "the migration finished" and "someone mentions they emailed you three days ago and got nothing back" is the actual cost, invisible until someone flags it — the same category covered in the hidden costs of website builders: time lost to a step nobody put on the checklist.

The guard is simple: export or screenshot the full DNS zone before any migration, mail records included, so there's something to restore if the new host's import misses something. Mail and web hosting are separate purchases, controlled by separate records — which is exactly why moving one without checking the other is so easy to do by accident.