Email on your own domain, set up so it actually delivers
A plain-English guide to running business email on your own domain: what SPF, DKIM, and DMARC prove, how to pick a mail host separate from the web host, why catch-all addresses attract spam, and how to retire a free address without losing anything.
A business email custom domain setup puts your mail at you@yourbusiness.com instead of a free consumer address, hosted by a provider you pick and backed by three DNS records that prove the mail is genuinely yours: SPF, DKIM, and DMARC. Point the domain's MX records at the mail host, publish those records, then migrate the old inbox. Skip the DNS work and your messages quietly land in spam folders.
- An address on your own domain is cheap credibility, and it stays yours when you switch providers.
- SPF, DKIM, and DMARC are DNS records proving that a message claiming to come from your domain really did.
- Mail hosting and website hosting are separate jobs, so separate providers usually mean a site move leaves the inbox alone.
- A catch-all address accepts mail sent to any name at your domain, which invites spam.
- Keep the old free address forwarding for at least a year so nothing gets lost.
Why does an address on your own domain matter?
An address at your own domain shows the business owns something. Registering a domain costs money and ties the name to whoever pays for it, so an address at one carries a signal a free consumer account cannot. Quotes read like they came from a company, invoices are less likely to be mistaken for a scam, and the address matches the website a customer lands on.
The practical reason matters more. A free address belongs to the provider; a domain address belongs to you. Switching mail hosts or handing an inbox to a new person becomes an administrative chore instead of a rebrand, and nothing printed on a truck door has to change.
What do SPF, DKIM, and DMARC actually do?
They are DNS records that let a receiving mail server check whether a message really came from your domain. One plain sentence each:
- SPF lists the servers allowed to send mail for your domain.
- DKIM attaches a signature to every outgoing message, which the receiver verifies against a public key published in your DNS.
- DMARC tells receiving servers what to do when a message fails those checks, and where to send reports about it.
Your mail host generates the values and you paste them into the domain's DNS zone, usually at the registrar. A domain gets exactly one SPF record, so if a newsletter tool and an invoicing tool both send for you, both belong inside that single record. DMARC has a policy setting worth easing into: start at none to collect reports, then tighten to quarantine and finally reject once legitimate mail passes.
Large mailbox providers tightened their sender rules in recent years, and Google and Yahoo now expect authentication from anyone sending at volume. The effect on a small business is simple. Unauthenticated mail gets filtered harder, and you rarely find out, because there is no bounce for "delivered to spam".
Should your mail host be different from your web host?
Usually, yes. Website hosting and mail hosting are separate services that happen to be sold together, and the bundled mailbox is often the weakest part of a hosting plan, with small storage and thin spam filtering. It also ties your inbox to a hosting decision you may want to revisit, and a platform move should never put email at risk.
| Setup | Trust signal | Control over deliverability | If you change website hosts |
|---|---|---|---|
| Free consumer address | Weak, reads as a side job | None | Nothing changes, nothing improves |
| Mailbox bundled with web hosting | Good | Limited by the host's features | Mail moves mid migration |
| Dedicated mail provider | Good | Full console for SPF, DKIM, DMARC, aliases | Only the website records move |
Google Workspace and Microsoft 365 are the mainstream options, with independents like Fastmail and Zoho Mail covering the same ground. Most are priced per mailbox, though plans and billing terms vary by provider.
What order should the setup follow?
Work in this sequence so nothing breaks mid switch:
- Confirm you control DNS for the domain, or register it.
- Pick a mail host and create the mailboxes people need. Role addresses like info@ start as aliases pointing at a person.
- Verify domain ownership with a TXT record, then publish SPF, DKIM, and DMARC before you touch MX.
- Change the MX records. That is the switch, and how quickly mail follows depends on the time-to-live value the old records were published with.
- Import the old mail, forward the old address, then send tests outside and check that the headers show SPF and DKIM passing.
Why is a catch-all address a bad idea?
A catch-all accepts mail addressed to any name at your domain, so sales@, tim@, and asdf@ all land in one inbox. It sounds like insurance against typos. In practice it is a mailbox with no bottom: spam senders guess common names at every domain they find. A catch-all also removes the one useful thing a bounce does, which is tell a real customer they mistyped the address.
Define the addresses you want and let everything else bounce. A personal mailbox per person, one general address, and one for billing covers most small businesses. If form notifications keep getting buried, the intake probably needs somewhere better to land than an inbox.
What should you do with the old free address?
Do not delete it. Forward it to the new mailbox and leave the forward running for at least a year. Customers, suppliers, and old listings keep using an address long after you have moved on, and each of those messages is a job you would otherwise miss.
Then work through what is attached to it:
- Import the archive so old threads stay searchable.
- Change the login address on every account tied to it, starting with banking, payment processing, and anything holding recovery codes.
- Update it anywhere it is published: business listings, invoices, quote templates, printed material.
- Send from the new address only, because replying from the old one teaches people to keep using it.
- After a year, look at what still arrives before shutting it off.
Account recovery is the piece that bites. An old address quietly holding password resets for your payment processor becomes a problem at the worst moment.
Common questions
Can you use a custom domain with a free Gmail account?
Not for hosting the mail. A free Gmail account can send as another address if you supply working SMTP credentials for it, but the mailbox still has to live somewhere, and the domain still needs its own MX and authentication records.
How long do DNS changes take to work?
Often within an hour, though full propagation can take a day or two depending on the record's previous time-to-live value. Lowering the TTL on your MX records a day before the switch makes the change land faster.
Does authentication guarantee mail reaches the inbox?
No. SPF, DKIM, and DMARC clear the first hurdle. Filters also weigh sending history, complaint rates, link reputation, and whether recipients open or delete what you send. Authentication removes a reason to filter you rather than earning trust on its own.
Do you need a paid mailbox for every employee?
Only for people who need their own inbox. Aliases and shared addresses normally come with the plan, so a crew of four might need two mailboxes and several aliases. Avoid sharing one login.
What about the mail your website sends?
Form notifications, receipts, and invoices go out through a sending service rather than your mailbox, and that service needs authorizing in your SPF record plus its own DKIM key, or its mail fails authentication. Sending that traffic from a subdomain helps keep trouble with automated mail away from the domain people write to. That wiring is part of any decent automation build.
How can you tell whether the records are right?
Open a message you sent to an outside account and read the raw headers. In Gmail that is "Show original", which prints pass or fail for SPF, DKIM, and DMARC. DMARC reports will also surface sources you did not know were sending as your domain.