Set up email at your own domain, and troubleshoot missing customer messages

An address at your domain makes your business easier to recognize and lets you keep the address when you change mailbox providers. The right setup depends on whether you need to receive messages, send them, or work in a separate business mailbox.

There is no reliable universal setup time. Account approval, DNS updates, and an existing mail migration can take longer than pasting the initial records. Make the change while you have time to test it.

The technical setup is the same for Canadian and US businesses: your DNS and sending/receiving providers determine the records, rather than whether the domain ends in .ca or .com. Regional billing and marketing rules still need separate attention.

Step 1: Choose an address or a mailbox

Before buying a mailbox, read the free business-address guide. Cloudflare Email Routing forwards incoming messages; it does not provide an ordinary mailbox for composing customer replies. Cloudflare documents sending to arbitrary recipients as a separate feature requiring a Workers Paid plan. Sending from the new address needs a supported sending arrangement. Selecting Gmail’s “send as” is not proof that your domain is correctly authenticated.

When you need a mailbox, use the email comparison for current prices, billing terms, currencies, and verification dates. Choose for the work you do: a simple individual inbox, collaboration in Google tools, or Outlook/Office workflows. An already-paid-for business mailbox may be the most economical choice.

Canada: check native CAD billing where offered, the actual tax treatment, and conversion/card fees if billed in USD.United States: check USD billing and applicable tax. For either country, verify seat counts, commitment length, aliases versus separate mailboxes, and any required sending features in the exact plan. A currency display is not proof that data is hosted in that country.

If replacing an existing provider, inventory mail, calendars, contacts, aliases, forwarding, website notifications, and devices first. Do not cancel the old account until the replacement and records you need have been tested.

If you currently combine an external mailbox with personal Gmail

Check the Gmail migration decision table. Google’s third-party Send as, Gmailify, and web POP-fetch features are being removed, with the final transition in January 2027. Receiving forwarding and Google-hosted aliases are different routes. Choose a supported replacement, retain necessary records, and complete the tests below before disconnecting the old arrangement.

When several people answer hello@ or support@

An alias forwards an address into a mailbox; it does not assign enquiries, prevent duplicate replies, or create a complete shared history. Use named user accounts and delegation or a suitable shared-inbox workflow. Never share the owner’s password.

If you already use Google tools, Google Groups Collaborative Inbox can support assignment and resolution. Enable conversation history, the Collaborative Inbox setting, and appropriate permissions. A group workflow is not identical to a conventional mailbox; test incoming mail, responses, visibility, and ownership in the interface the team will actually use.

For Microsoft 365, shared mailboxes use licensed Exchange Online delegates rather than a shared direct login. The shared mailbox generally needs no separate license within the documented storage allowance, but larger storage, archiving, holds, and other advanced requirements can change licensing. Check your exact plan. Verify permissions and shared sent-message visibility rather than assuming sent replies are stored where everyone can see them.

Use the team-response routine to assign the next reply, arrange cover, and remove departed staff. Check features already covered by your subscriptions before buying a new inbox product.

Step 2: Find the DNS account

DNS records are the settings that tell other systems where your domain’s services live. Edit them at the provider that manages your domain’s nameservers. That may be Cloudflare, your registrar, or another host; owning the domain at one company does not mean its DNS is managed there.

Use the values for your domain in the mailbox provider’s current setup wizard. Save the existing records before editing them. Keep unrelated website records in place, and avoid changing nameservers merely to add email records unless your migration plan actually requires it.

Step 3: Connect incoming mail and authentication

Record	Purpose	Common mistake
MX	Directs incoming messages to the receiving service	Leaving conflicting old-provider records or changing MX when only adding a sending tool
SPF	Lists permitted sending systems for the domain it applies to	Publishing multiple SPF records for the same domain instead of using one correct policy
DKIM	Lets a sending service sign messages so recipients can verify them	Using the wrong provider key or failing to enable signing after adding the DNS record
DMARC	Uses authentication and domain alignment to publish handling/reporting instructions	Enforcing rejection before legitimate sending services have been checked

Domain alignment means that the identity authenticated by SPF or DKIM matches the visible sender domain in the way DMARC expects. A valid record sitting in DNS does not prove that a particular invoice app is sending with it.

Follow the provider’s instructions for all services that send on your behalf, including newsletters or invoices. Do not paste a second service’s SPF value over the first without checking what must be retained. Ask the provider for a reviewed setup when the policy includes several senders. Google’s DMARC troubleshooting guide explains how message-level results expose alignment problems.

Use the provider’s verification checks and Scout’s DNS checker as configuration aids. Neither guarantees inbox placement. Google’s sender guidance distinguishes ordinary and bulk sending requirements for personal Gmail addresses, such as @gmail.com, and recommends authentication beyond the minimum. Those rules apply regardless of whether your business is Canadian or American. Check the receiving provider’s requirements for other destinations; this particular guidance does not cover Google Workspace recipients.

Step 4: Test every real sending route

Send a simple message from the new mailbox to test accounts at different receiving providers. Reply back. Then test an actual sample quote or invoice, your contact form notification, and any other service using the address.

Confirm the visible From address, reply destination, attachment/link, and receiving folder. A mailbox test does not validate a separate invoicing application’s sender. Keep the test subjects and times so support can find them.

Only then update public contact details. Keep old receiving arrangements available for a suitable transition when possible, and tell relevant contacts about the change.

An expected quote or invoice and a promotional newsletter have different purposes. Do not turn a customer’s requested reply into automatic permission for ongoing marketing. The newsletter guide covers Canadian CASL and US CAN-SPAM requirements separately. Correct DNS records do not establish marketing consent or satisfy those laws.

If customer quotes are not arriving

Start by asking what happened to one specific message, without sending a burst of repeats.

Symptom	What to collect and check
A bounce or error returned	Save the full error, recipient, sending time, and sending service. Follow the error’s explanation before changing DNS.
The message is in junk	Ask for the received message’s authentication results or headers; compare them with your provider’s setup.
No bounce, no visible message	Confirm the address, ask about junk/quarantine/rules, and ask your sending provider to trace delivery. Absence of a bounce does not establish inbox delivery.
Only invoice-app messages fail	Test the mailbox separately, then inspect that app’s sending identity, authentication settings, and logs.
Only forwarded messages fail	Check the forwarding path with the receiving and forwarding providers. Do not delete protections simply to make a forwarded test pass.

In Gmail’s desktop browser view, open the received message and choose More → Show original, following Google’s header instructions. Headers include message-routing and authentication information. Share them privately with the relevant support team; they can expose addresses and identifiers.

If authentication fails, correct the responsible service’s configuration and retest that route. If it passes but messages still enter junk, review the actual content, links, attachments, sending behaviour, and the receiving provider’s result with support. Passing SPF, DKIM, or DMARC does not compel every recipient to accept a message into the inbox.

For an expected quote, ask the customer whether a short plain reply arrives and whether they can retrieve the original from junk. With their agreement, use another suitable channel for time-sensitive work. Avoid emailing sensitive records to an unverified alternative address.

Give support a useful report

At [time and time zone], [mailbox/app] sent message [subject or ID] from [address] to [test recipient]. It [bounced/arrived in junk/is missing]. The bounce code or received authentication results are [details]. Ordinary mailbox mail [works/also fails]. Please trace this message and identify the next correction.

Do not automatically buy a dedicated sending IP, change your domain, or weaken DMARC. Those are substantial changes that need a diagnosed reason. Use the provider’s evidence rather than an unsolicited seller’s promise to “fix deliverability.”

You are finished when: incoming mail, mailbox replies, and each customer-facing sending app work in representative tests; records and recovery access are retained; and you know which provider handles a failure. Keep business access recoverable even if you currently view personal and business messages together.