How to Set Up Business Email With Your Own Domain

To set up business email with your own domain, choose an email suite, prove to it that you own the domain, create every mailbox and shared address, and then point the domain's MX record at the new provider. On a domain that has never had email, that can fit into an afternoon. Moving a domain that already receives mail takes longer, because existing messages, shared addresses and other services that send as your domain all need a place in the plan.

Whichever provider you choose, the order of work is the same. This guide follows it for Google Workspace, Microsoft 365 and Proton Workspace, with the DNS records each one asks for and a checklist for the evening you switch. If your domain has never had email, you can skip the migration and old-mailbox steps.

How do you set up business email with your own domain?

1. Choose a suite that fits how your team works.
2. Create the account with two administrators.
3. Verify the domain with a TXT record. Your current email keeps working.
4. Create every mailbox and shared address, and send a test message to each one.
5. Copy existing mail across, if you are moving from another service.
6. Switch the MX and SPF records at a quiet time, then test incoming and outgoing mail.
7. Confirm DKIM is signing (set it up earlier where your provider allows), add DMARC, then retire the old service once nothing is still arriving there.

Before you start

Gather four things before you open a sign-up page.

1. A domain and access to its DNS. If you do not own one yet, register a domain the business controls. DNS is edited at the registrar or a separate DNS host such as Cloudflare. If the domain is in a former web designer's account, recover it first; our guide to checking who owns your business domain covers that. You do not need to transfer the domain or change nameservers merely to add email.
2. A list of people who need their own address, with the naming pattern you will use (for example firstname@).
3. A list of shared addresses, such as info@, invoices@ and an admin@ or domains@ address for notices from registrars and software vendors.
4. A copy of your current DNS records. Export or screenshot the MX, SPF, DKIM and DMARC records. Restore old MX values only as part of a tested rollback; changing MX again cannot retrieve mail already delivered to the new provider.

Choose a quiet time for the switch, and make sure someone can check both mail systems for the day or two after it. A Friday evening works well when someone will look in over the weekend.

If this is a new domain with no existing email: choose a plan, verify ownership, create the users and public addresses, then publish the provider's MX, SPF and available DKIM records. Send and receive test messages from an outside account, and add DMARC after authentication passes. The migration and old-service steps below apply only when you are replacing an existing mail setup.

Step 1: Choose the suite

All three suites put email on your own domain with an admin console. They differ in how people work day to day.

Google's and Microsoft's Business plans are each sold for up to 300 users. Proton needs a paid plan for a custom domain. Check the current Google, Microsoft and Proton checkout prices before buying; billing terms and offers change.

For a deeper look at the choice, see Google Workspace vs Microsoft 365 and Google Workspace vs Proton Workspace. To pick a tier within a suite, see Business Starter vs Standard and our Microsoft 365 business plan guide. Whichever you choose, write down why in one or two sentences. Next year, when someone asks why the business is on this suite, that note answers it.

Step 2: Create the account with two administrators

Create the new organization, then set up administrator access before inviting the rest of the team. Use a recovery method you control independently of the new domain so a domain outage does not also lock you out of the admin account.

• Two administrators, each with their own sign-in. One is the owner; the other is a trusted backup. Give each only the privileges needed for the role. A second administrator gives the business a recovery path if the first is unavailable.
• Separate admin accounts from everyday accounts. A name like owner-admin@ used only for administration means the administrator account is not used for everyday mail, so routine messages and links never reach it.
• Two-step sign-in on both from the first day, with recovery codes stored in the business password manager.

Step 3: Verify the domain

Each provider asks you to prove you own the domain by adding a TXT record to your DNS. This does not affect your current email, so it is safe to do during the day.

• Google Workspace offers two routes: update settings at your registrar, or add a TXT record by hand. Google says it can take up to an hour to confirm the record, and that you must verify within the first 9 days of the free trial or when a paid contract starts.
• Microsoft 365 gives you a TXT record that starts with MS=ms followed by a value from the admin center.
• Proton gives you a TXT record that starts with protonmail-verification=. Its guide suggests a TTL of 300 seconds for the record.

Add the record, wait for the confirmation, and leave everything else alone for now. In particular, do not touch the MX records yet.

Step 4: Create people and shared addresses before touching MX

Microsoft says to add users before updating the MX record. Mail that arrives before a mailbox exists has nowhere to go. Create every person's account, then the shared addresses.

Shared addresses should belong to the business function, not to one person. A forwarding rule from info@ to one inbox works until that person leaves and takes the history with them, which is one of the access gaps covered in our former employee access guide. Each suite handles this differently:

• Microsoft 365 has shared mailboxes. A shared mailbox can store up to 50 GB without a license of its own; the people who use it need their own licensed mailboxes, and you grant them permission to read it and send from it.
• Google Workspace uses Google Groups. A group can be made a Collaborative Inbox, where members you give permission can take and assign conversations. Gmail delegation is the other option when a small number of people need to read, send and delete mail for one account.
• Proton has distribution groups that forward messages to members, but custom-domain group addresses use @groups.your-domain, not a plain info@your-domain address. Create info@ as a custom-domain address and decide who owns and monitors that inbox; test any forwarding workflow separately.

An alias delivers into an existing person's mailbox; it does not create a shared history or shared ownership. For each public address, decide who reads it, who may reply as it, and where its history will remain when a staff member leaves. Then send a test message to every address before changing MX.

Step 5: Copy the old mail

If you are moving an existing domain, begin copying mail before the switch so people have their history in the new system. A large import can take days. Start with one mailbox and check folders, dates and a sample of attachments before migrating the rest.

Microsoft's IMAP route does not move contacts, calendars or tasks, so plan those separately. Check the source and destination tool for migration prerequisites and keep the source available until a final synchronization or reconciliation is complete. Google's import options, Microsoft's IMAP limits and Proton's Easy Switch rules differ. If you are moving from Microsoft 365 to Proton, our migration walk-through covers imports, cutover and rollback in more detail.

The records each provider asks for

Every provider shows the exact values in its admin console; use those values as the source of truth. The table is a recognition guide, not a complete record template for your particular domain. DNS hosts also differ in whether they require @, a blank host name or a trailing dot. Microsoft may ask for additional records such as Autodiscover; follow its domain wizard for those too. Editing mail records does not require changing the website's A or CNAME records.

A few details matter. Older Google Workspace domains may still use MX values beginning with aspmx; Google still supports them. A domain must publish one SPF policy. If a newsletter tool, invoicing system or website form sends mail as your domain, inventory it before editing SPF. Some services use their own DKIM or a subdomain, so copy each service's actual instructions into the plan. Our SPF, DKIM and DMARC explainer shows how a combined record reads, and the Proton custom domain guide walks through Proton's DNS screens one record at a time.

Cutover evening

The switch itself needs a quiet hour, followed by a day or two of checking both systems. The steps run in this order, and each has a check before you move on.

While cached MX answers expire, some senders may still reach the old provider. Keep both services working, monitor the old inboxes and use a final incremental import if your migration method supports it. If external mail fails to arrive, check the public MX lookup, the new mailbox and its routing, and the old mailbox before deciding whether to restore the original MX.

Before the first real invoice goes out from the new system, send a test invoice to an outside address and check that it arrives in the inbox, not in spam.

DKIM and DMARC: finish authentication

DKIM signs outgoing mail with a domain key that receivers can verify. Configure it before cutover when your provider allows, then check a message sent to an outside account. Google's key-generation wait is the main scheduling exception.

• Google Workspace: Google says to wait 24–72 hours after Gmail is turned on before generating its DKIM key. Put a reminder in the calendar. Choose a 2048-bit key if your DNS host supports it, publish the TXT record, then start authentication.
• Microsoft 365: Set up DKIM for the custom domain as soon as the domain is ready. Publish the two CNAME values shown for your tenant, then enable signing in the Defender portal. The CNAME targets are tenant-specific; do not construct them from an example.
• Proton: Publish the three CNAME values once Proton shows them after domain verification. Because they are CNAME records, Proton rotates the keys automatically, generating a new 2048-bit key every six months.

Once you have checked SPF or DKIM alignment for every legitimate sending service, publish a DMARC record. For a migration, p=none lets you collect reports without asking receivers to quarantine or reject failing mail. Set a reporting address you can monitor and review reports before increasing enforcement; p=none alone does not block spoofing. Our DMARC guide for small businesses covers that progression.

After a monitored transition: retire the old service

If your old address was on a different domain, such as a personal Gmail account, forward or monitor it during a transition period you choose; a month is a useful review point, not a guarantee that everyone has updated their address. If you are keeping the same domain and changing hosts, keep the old hosting account available until late mail and the final migration have been checked. Forwarding within that old host may not work once public MX points elsewhere.

During the transition, send one short message to clients and suppliers with the new addresses, and update the sign-in email on the accounts the business depends on: the bank, payroll, the domain registrar and software subscriptions. Password resets for all of them land in this mailbox, so they belong on business addresses.

Cancel the old email plan only after you have confirmed incoming and outgoing mail, migrated needed history, checked old inboxes and identified any service still using the old host. Keep a separate personal account if you use it for personal mail; change only its business contacts and forwarding. Check the old provider's renewal date before cancellation.

Common mistakes

• Changing the MX record first. Mail starts arriving before the mailboxes exist. Verify, create users and shared addresses, copy mail, then switch.
• Two SPF records. The new provider's record goes into the existing one, not next to it. More than one SPF record makes SPF fail.
• One administrator. If that person is unavailable, nobody can manage the account.
• Forwarding info@ to one person. Use a shared mailbox or group so the history stays with the business.
• Leaving DKIM until later on every suite. Google says to wait 24 to 72 hours after Gmail is turned on before generating the key; Microsoft and Proton DKIM can be set up once the domain is added and verified.
• Cancelling the old host on cutover day. Keep it available until cached delivery and the final migration have been checked.

Which order fits your business?

The shared sequence is: verify the domain, create and test every receiving address, inventory senders, migrate old mail if needed, switch MX and SPF, then test incoming and outgoing mail. Finish DKIM as soon as your provider permits and add DMARC after checking alignment. Retire the old host after reconciliation. Google has one current MX value and a possible DKIM wait; Microsoft uses a domain-specific MX value and a DKIM switch; Proton uses two MX records and three DKIM records.

If other services send as your domain, list and test them before cutover. Check each service's SPF, DKIM and DMARC alignment requirements; adding an SPF include alone may not make DMARC pass. The guide to fixing business email that goes to spam covers diagnosis if a sender is missed.

Related Resources

• Who Owns Your Business Domain Name? — Check and secure the domain before you build email on it.
• How to Get Your Small Business Online — Domain, email, authentication and website, in the order to set them up.
• Google Workspace vs Microsoft 365 — Prices, apps, storage and admin, compared for small businesses.
• Proton Mail Custom Domain Setup — Proton's DNS records and tests, screen by screen.
• SPF, DKIM and DMARC Explained — What each authentication record does and how they work together.
• DMARC for Small Business — Reading reports and moving from monitoring to enforcement.
• Microsoft 365 to Proton Workspace Migration — Imports, cutover and rollback for a move between suites.