Business email on your own domain: the complete setup guide

Setting up email for business on a domain you own takes four DNS records and about half an hour, and most of that half hour is waiting for DNS to propagate. That is the whole job: four records, and a business email account on an address your customers already trust. Undoing a bad start takes far longer: a brand parked on @gmail.com, a mail bill that climbs with every hire, or a forwarding chain that silently eats replies. This guide is the whole job, start to finish. The DNS examples are not mockups; they are our production records, pulled with dig on August 7, 2026, from a domain that has been receiving and sending real mail since June 2026.

Why your business email should live on a domain you own

An email address on someone else's domain is a rental. If your business runs on yourbusiness@gmail.com and you ever leave Gmail, the address does not come with you, and neither does the years of correspondence people have filed under it. An address on your own domain has the opposite property: the mailbox host behind it is a DNS setting you can change in an afternoon while hello@yourdomain.com stays exactly the same. Portability is the whole argument, and it only works in one direction.

Trust is the second argument, and it is smaller than the industry pretends but real. People do read the part after the @. A professional email address on the same domain as your website confirms you are who the website says you are; a free-provider address makes a customer do that verification themselves. Since November 2025, receivers also verify senders mechanically: Gmail hard-rejects unauthenticated mail with a 550 error rather than spam-foldering it, and Microsoft has done the same since May 2025. Authentication lives in DNS you control, which means it requires a domain you control.

The third argument is arithmetic. Per-seat pricing means your mail bill is a function of headcount, forever. That model made sense when a mailbox was a slice of a server someone had to provision. It makes less sense now: on our own stack, an address is a routing rule, not a seat, which is why we can offer unlimited addresses without doing anything clever. The cost section below has the exact crossover math; the short version is that per-seat pricing wins for very small teams and loses from the fourth hire on.

If you want the deeper case for owning the domain, our custom domain email article makes it in full. The rest of this guide assumes you are convinced and want the mechanics.

Choosing the domain

Use the domain your website is on. Your mail inherits the recognition the domain already has, and your domain builds one reputation instead of two. Buying a separate lookalike domain (yourbusiness-mail.com) for everyday correspondence is a mistake twice over: it reads like phishing to recipients, and it starts from zero sender reputation while your real domain's reputation sits unused.

There are two structured exceptions. Cold outreach belongs on a separate domain so that its complaint rates cannot touch the domain your invoices come from; that is a different discipline with its own guide, cold email infrastructure. And once you send a newsletter at any real volume, put the bulk stream on a subdomain (news.yourdomain.com) while replies and transactional email stay on the root, so a bad campaign cannot sink your password resets. A subdomain is isolation, not a wall: sustained abuse still rolls up to the parent domain, so this is containment for accidents, not a license for bad lists.

One thing to plan around: a domain that has never sent mail has no reputation, and mailbox providers treat no reputation as mild suspicion. New-domain reputation matures over roughly 4 to 8 weeks of consistent sending. For one-to-one business correspondence you will not notice. For anything bulk, ramp deliberately; that process is called warm-up and our deliverability handbook covers the exact schedule we enforce in code.

On TLDs: any TLD can authenticate and deliver. Pick the one your customers will type correctly on the first try, which usually means the .com if you can get it.

The four DNS records, with our production values

Every record below is live on nostalgiapost.com, the domain our own workspace has run since June 2026. You can dig them yourself and get the same answers.

MX: where your mail arrives

The MX record tells the world which servers accept mail for your domain. Whatever inbound provider you choose gives you the hostnames; you publish them with priorities, and senders try the lowest number first. Ours point at Cloudflare Email Routing:

$ dig +short MX nostalgiapost.com
2  route3.mx.cloudflare.net.
12 route1.mx.cloudflare.net.
77 route2.mx.cloudflare.net.

Three records, three fallbacks. If you are on Google Workspace this is a single record pointing at smtp.google.com; on Microsoft 365 it points at yourdomain-com.mail.protection.outlook.com. The shape is always the same. Our MX record guide covers the details, including the classic failure of a stray old MX record splitting your inbound mail between two providers.

SPF: who may send as you

SPF is a TXT record on the root of your domain listing the servers allowed to send mail claiming to be from it. Ours:

nostalgiapost.com  TXT  "v=spf1 include:_spf.mx.cloudflare.net include:amazonses.com ~all"

Each include: pulls in a provider's server list (Cloudflare for our forwarding paths, Amazon SES because our sending relay rides on it). The ~all at the end means "softfail anything else": mail from unlisted servers gets marked suspicious rather than refused outright, which is the right setting while DMARC does the actual enforcement.

Publish exactly one record starting with v=spf1. Two of them is a permanent error, and receivers treat your SPF as broken. The other way SPF breaks is the ten-lookup limit, which gets its own section under failure modes.

DKIM: a signature that survives the trip

DKIM puts a cryptographic signature on every message you send; the public key sits in DNS at a selector your provider names. Ours, from our sending relay:

resend._domainkey.nostalgiapost.com  TXT  "p=MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDmekwp...IDAQAB"

(Key truncated here for readability; the real record is a 1,024-bit RSA public key, which is the minimum Google's sender guidelines accept.) You never write this record from scratch. Your provider generates the key pair, you paste the record it gives you, and the provider signs outbound mail with the private half. What you are responsible for is keeping the record in sync when keys rotate, covered under failure modes below.

DMARC: your published policy

DMARC is a TXT record at _dmarc.yourdomain.com telling receivers what to do with mail that fails SPF and DKIM alignment, and where to send reports about it. Ours:

_dmarc.nostalgiapost.com  TXT  "v=DMARC1; p=reject; rua=mailto:dmarc@nostalgiapost.com; fo=1"

p=reject means "refuse anything that fails." Do not start there. The progression that works: publish p=none with a rua= reporting address on day one, read the aggregate reports for a few weeks to find every legitimate service sending as your domain, move to p=quarantine, then to p=reject once the reports run clean. We are at p=reject because we went through that sequence, and the fo=1 flag asks for a failure report on any alignment miss so problems surface fast.

A scoping note: Google and Yahoo's bulk-sender rules (February 2024) formally apply at 5,000+ messages per day to Gmail, but the authentication requirements bite at any volume, and the hard rejections that started in late 2025 do not check your volume first. We follow all of it at dozens of messages a day.

If your sending provider uses a dedicated return-path subdomain, it will hand you a couple of extra records. Ours did: send.nostalgiapost.com carries its own SPF record and an MX for bounce handling (10 feedback-smtp.us-east-1.amazonses.com). Paste what the provider gives you; the pattern is the same four jobs at a different label.

Address architecture: people, roles, aliases, and the catch-all

DNS gets mail to your domain. Address architecture decides what happens next, and it is worth ten minutes of design before you create anything.

Give every person one canonical address and pick one pattern for all of them: firstname@ for small teams, first.last@ if you expect name collisions. Do not mix patterns; the moment you have both sara@ and james.wong@, every future address is a coin flip for the people mailing you. Give each person a consistent signature while you are at it; our email signature examples article has copy-ready blocks.

Role addresses (sales@, support@, billing@, press@) belong to functions, not people, so they survive staff changes. Route them somewhere more than one person can see: a shared inbox beats forwarding-to-whoever-handled-it-last, because the thread history stays in one place when the handler changes. One nuance from our own deliverability rules: role addresses are excellent to own and terrible to subscribe. We host them happily as receiving addresses, and our newsletter signup rejects them, because info@ addresses on a mailing list correlate with spam traps and stale lists. The same address can be a fine inbox and a bad subscriber.

An email alias is an extra name that delivers into an existing mailbox: press@ landing in Sara's inbox is an alias, not a second account. Aliases are free at every serious host. A mailbox is a separate credentialed store, and at per-seat hosts it is a paid seat. Knowing which one you need is most of the cost control: a five-person company might need five mailboxes and fifteen aliases, not twenty seats.

Then there is the catch-all: a rule that accepts mail for any address on the domain that does not otherwise exist. We run one in production. It is how anything@nostalgiapost.com reaches us, how typos in our address still arrive, and how we can hand out a fresh address per vendor without creating anything first. In our stack the catch-all routes every message to a Cloudflare Email Worker, the raw message is read once, parsed, and written to a database that is the source of truth; an address is literally a routing rule. The honest tradeoff is spam: a catch-all accepts dictionary-attack mail addressed to invoice@, admin@, and a thousand guessed names, so it needs decent filtering in front of a shared view rather than someone's personal inbox. The pros, cons, and our production experience are in the catch-all email article.

Connecting it: a mail host, a client, or a workspace

With DNS published and addresses planned, you need something that actually holds and displays the mail. There are three shapes.

A bundled workspace host (Google Workspace, Microsoft 365) is the default choice: point MX at them, and mail arrives alongside Docs or Office, calendars, and video calls. You pay per seat, and the office suite is the reason to. If your team lives in shared spreadsheets, this is the honest recommendation and the rest of this guide still applies to you, because the DNS and address architecture are identical.

A mailbox host plus a client of your choice is the open-protocols route: a provider hosts the mailboxes, and any client connects over IMAP or POP3 to read and SMTP to send. Choose IMAP unless you have a specific archival reason not to; the difference matters and IMAP vs POP3 explains it in five minutes. What SMTP actually does is worth the same five minutes, because every "my email won't send" ticket is an SMTP question wearing a costume.

An email workspace is the third shape, and it is what we build. No per-seat mailboxes: the catch-all delivers every address on the domain into one shared, threaded workspace, and anyone on the team can read and reply as any address, with sends going out through an authenticated relay. Replies carry In-Reply-To and References headers so conversations thread correctly in the recipient's client no matter which address they wrote to. The tradeoff, stated plainly: there are no office apps, no video calls, and no per-person private mailboxes. It is email, contacts, and newsletters on your domain, and nothing else.

The cost math: per seat vs flat

List prices as of August 2026: Google Workspace Business Standard is $14 per user per month on an annual commitment (per Google's pricing page), and Microsoft 365 Business Standard is also $14, up from $12.50 on July 1, 2026 (per Microsoft's pricing announcement). Here is what headcount does to those numbers against a $50 flat rate per domain:

The crossover is the fourth person: $56 a month for four seats against $50 flat, and the gap widens with every hire after that. Below four people, per-seat is cheaper, and the suites bundle document editing and video calls that a flat-rate email workspace does not have. That is the honest version of this table.

The number the table does not show is the newsletter. Per-seat hosts do not include one, so a growing business typically adds a second bill that scales on a second axis: subscribers. Mailchimp's Standard plan is $100 per month at 5,000 contacts (list price, August 2026), on top of whatever the mailboxes cost. A flat per-domain price that includes the newsletter collapses both axes into one line item, which is the pricing argument for the workspace shape in one sentence.

Where setups fail (and how ours failed)

Everything above is the happy path. These four failure modes account for most of the mail that silently disappears.

The SPF ten-lookup limit

RFC 7208, section 4.6.4, caps SPF evaluation at ten DNS lookups; exceed it and receivers return permerror, which DMARC treats as an SPF fail. Every include:, a, mx, and redirect in your record costs lookups, including the ones nested inside your providers' own records. The failure is sneaky because it arrives gradually: you add a helpdesk tool, then a CRM, then a billing system, each appending an include:, and the eleventh lookup quietly breaks authentication for everything. Count your lookups with any SPF checker before and after adding a service. Our own root record spends its budget on two includes plus whatever they expand to, and we count before we add anything. If you are over the limit, remove includes for services that no longer send as you before reaching for SPF flattening; flattened records go stale when providers change IPs.

DKIM keys go stale

DKIM fails in two undramatic ways. First, weak keys: 1,024 bits is the floor Google accepts, and new setups should ask their provider for 2,048. Second, rotation: providers that give you a CNAME (Microsoft 365 does this) rotate the underlying keys themselves, but a raw TXT key like ours is frozen until someone updates it. If your provider rotates or re-issues keys and your zone still holds the old record, every message you send fails DKIM from that moment, and nothing on your side looks different. Know which type you pasted. If it is a raw key, rotation is your job, and your DMARC aggregate reports are where you will find out it happened.

Forwarding breaks DMARC

This one we can quantify from experience. In June 2026 we mirrored inbound mail to a Gmail archive using standard forwarding, and Gmail was rejecting 73% of it. No bounce reached us and nothing errored in our pipeline; the mail was accepted on our side and refused on theirs, because forwarding re-sends a message from a server the original domain's SPF never authorized, and strict alignment does the rest. Mail from any sender with p=reject just vanished. We found it by noticing archive copies were missing, measured the damage, and replaced forwarding with an API insert that places messages into the archive mailbox directly instead of re-sending them across the public internet. Forwarding survives as a last-resort fallback only.

The general lesson for your setup: do not build anything load-bearing on email forwarding. If you want mail in two places, deliver it twice or insert it via the destination's API; anything that re-sends someone else's mail is fighting DMARC and will lose more often as p=reject adoption climbs.

Silent failure is the default

Notice what the last two failures share: no error message. Email infrastructure fails silently because the errors go to the sender, not to you, and senders rarely relay them. We take this seriously enough that our production system sends itself a canary probe every two hours, through the real path (DNS, routing, worker, parser, database), and emails the owner if it fails to arrive; the probe is absorbed on ingest so no user ever sees it. You do not need that machinery on day one, but you need its habit: after setup, send yourself mail from an outside account and reply to it from your new address, then repeat the test monthly. Publish the rua= address in your DMARC record and actually read the reports. Silence from a monitored system means healthy; silence from an unmonitored one means nothing at all.

The setup checklist

1. Register or choose the domain; use the one your website is on.
2. Pick the shape: bundled suite, mailbox host plus client, or an email workspace.
3. Publish the MX records your inbound provider gives you.
4. Publish one SPF record; count its DNS lookups.
5. Add the DKIM record from your provider; ask for 2,048-bit keys.
6. Publish DMARC at p=none with a rua= reporting address.
7. Create person addresses on one naming pattern, role addresses for functions, and decide whether a catch-all fits your spam tolerance.
8. Send a test from an outside account, reply to it, and confirm both directions authenticate (any mailbox provider's "show original" view shows SPF, DKIM, and DMARC results per message).
9. After a few clean weeks of DMARC reports, move to p=quarantine, then p=reject.

Step 8 is the one people skip. Run it before the domain goes on your business cards, and put a repeat of it in your calendar for the first of every month.