To use Gmail with an address on your company domain, set up the appropriate Google Workspace account, verify the domain and configure Gmail delivery. Check 4 things first: domain control, the intended Workspace edition, mailbox ownership and the existing email service. A personal address ending in gmail.com is different from a company-domain address managed through Workspace.
The steps below explain the business-email route without assuming a particular registrar or changing any live account. If email already works for the domain, treat the change as a migration. Preserve the current configuration and plan the handover before replacing delivery records. A website remaining online does not prove that email delivery is unaffected.
What do you need before creating the account?
Google’s Workspace sign-up guidance describes different Business editions and says a domain can be one already owned or one purchased during sign-up. It also distinguishes education and nonprofit routes that have eligibility conditions. Do not assume that an organisation qualifies for a special edition merely because its activities sound educational or charitable.
Confirm who controls the domain and where its DNS records are actually managed. The registrar and DNS host may be different services. Obtain legitimate administrative access through the business’s own process; do not ask a website contact to send passwords in an ordinary enquiry. Record the accountable owner and recovery route.
List the addresses required and who will use them. A named person’s mailbox, an address used by several staff and an alternative address pointing to an existing mailbox are different requirements. Do not choose the account structure solely to make a short list look tidy. Check the relevant Workspace feature documentation for the proposed arrangement.
| Requirement | Question to settle before setup | Record to retain |
|---|---|---|
| Domain | Who controls the DNS service? | Account owner and authorised administrator |
| Edition | Which Workspace features are actually needed? | Selected edition and applicable terms |
| Mailboxes | Which people need their own managed account? | Address-to-owner register |
| Existing email | Which service currently receives mail? | Current delivery configuration and migration scope |
| Recovery | Who can regain administrator access? | Business-controlled recovery arrangements |
| Cutover | How will incoming and outgoing mail be tested? | Agreed checks and responsible person |
Keep payment and subscription decisions with the authorised business owner. This guide gives no public monetary price or invented plan recommendation. Review the current terms in the account being created and distinguish a trial from the ongoing service that may follow.
How does domain verification differ from mail delivery?
Domain verification establishes control for the service’s setup process. Mail delivery depends on DNS mail-exchanger records, usually called MX records. Completing one does not mean the other is finished. Follow the current instructions shown for the actual account and registrar rather than copying a screenshot from an unrelated setup.
Google’s MX-record documentation explains that senders use the domain’s MX records to locate the receiving mail service. Its current instructions include adding Google’s record and activating Gmail in the Admin console. These are connected steps. A record entered into the wrong DNS service will not affect the authoritative domain configuration.
The same documentation discusses legacy Google MX values and says working older configurations do not need changing merely because a newer single-record option exists. Do not rewrite a functioning setup simply to make it resemble a new-account tutorial. First establish whether the task is initial activation, a migration or troubleshooting.
For a migration, inventory what must be retained: existing messages, contacts, shared working practices and any systems sending email on the domain’s behalf. Changing MX records redirects incoming delivery; it does not by itself move historical mail or reconfigure every application that sends notifications. Plan those dependencies separately.
What should you do during setup and handover?
Work from the account’s current setup flow. Record the chosen domain and addresses before making DNS changes, and preserve the earlier records so an authorised administrator can understand what changed. The appropriate sequence depends on whether this is a new domain or an existing mail service being replaced.
Use Google’s documented values for the specific setup and follow the DNS host’s formatting requirements. Hosts can differ in how they represent a blank name, the root domain or a fully qualified destination. Do not add several incompatible records because different tutorials show different generations of instructions.
Allow for DNS changes to become visible and inspect the actual result. Repeatedly altering records before understanding the previous change can make diagnosis harder. Use the service’s verification or troubleshooting route and compare the authoritative configuration with what was intended.
This original activation evidence sheet separates account creation from a usable email service:
| Stage | Test | Evidence of completion |
|---|---|---|
| Account | Sign in through the intended managed account | Correct organisation and user identified |
| Domain | Complete the prescribed verification | Domain shown as verified in the relevant setup |
| Incoming mail | Send a clearly labelled test from an independent address | Message received in the intended mailbox |
| Outgoing mail | Reply to the independent address | Recipient receives the expected sender identity |
| Existing systems | Trigger a non-sensitive notification from each relevant application | Correct delivery and sender behaviour |
| Handover | Ask the owner to identify administration and recovery routes | Responsibility documented without sharing secrets |
The sheet is not a claim that a particular domain has been configured. A successful test in one direction does not establish delivery in the other. Keep the evidence specific enough to distinguish a routing problem from a wrong address, an application setting or an individual mailbox issue.
What should remain under business control?
Document who administers users, who approves new addresses and who removes access when someone leaves. A domain-based email service is an operational system, not simply a more professional-looking address. The business needs a reliable way to correct access and recover control without depending on a departed contractor.
Keep authentication and sender-identity configuration within the relevant administrator’s scope. If additional email-authentication work is required, follow the current provider guidance and identify every legitimate sending system before changing policy. Do not treat a mailbox login as proof that all domain email is configured correctly.
For the broader requirements, see business email. To discuss a setup or migration, get started with the domain, current provider and required addresses, without sending passwords or live mailbox contents.
By Spout Team. AI-assisted drafting by Codex using the linked primary sources.