Setting Up Business Email with Google Workspace
A step-by-step guide to business email on Google Workspace: verifying the domain, creating users and groups, adding MX, SPF, DKIM, and DMARC records, and the Admin console settings to review once mail is flowing.
Business email on your own domain is usually the first piece of infrastructure a new company sets up, and Google Workspace is one of the most common ways to do it. The setup is not difficult, but it touches three systems at once: the Workspace Admin console, your domain’s DNS, and the mail clients your team will use. This guide walks through the sequence in the order that avoids downtime, explains the DNS records you will add and why, and covers the admin settings that matter once mail is flowing.
Before you start: domain, plan, and admin account
You need three things in hand. First, a domain you control at a registrar or DNS host, with access to edit its records. Second, a Google Workspace subscription; plans differ in storage per user, meeting features, and security tooling, and the current plan list and prices are set by Google and change over time. Third, a super administrator account. That first admin account is created during signup and is the identity that owns the Workspace tenant, so choose its address carefully and protect it from the first day.
If you are taking over an existing Workspace tenant rather than creating one, sign in to the Admin console with the super admin credentials you were given, change the password immediately, and enrol your own 2-Step Verification method before doing anything else. The section on handover further down covers the rest of that review.
- Domain
- Registered and with DNS you can edit
- Plan
- Chosen for storage, security, and seat count; terms set by Google
- Super admin
- The owning account; secure it with 2-Step Verification
- Admin console
- admin.google.com, where every setting below lives
Step one: verify the domain
Google must confirm you control the domain before it will deliver mail for it. In the Admin console, under Account and then Domains, the wizard offers a TXT record to add at your DNS host. Add it at the root of the domain, wait for propagation, and click verify. Some registrars are recognised by the wizard and can be verified with a sign-in instead of a manual record; either path ends in the same verified state.
Add any secondary domains or domain aliases at the same time. A domain alias lets every user receive mail at a second domain without extra licences, which is useful when a company owns both a .com and a country-code domain.
Step two: create users and groups
Create a user for each person under Directory and then Users. Each user consumes a licence. For shared addresses such as support@ or billing@, create a Google Group with collaborative inbox settings instead of a user; groups are free, can have several members, and keep a shared history. Set a naming convention now, because renaming addresses later leaves old aliases and confused threads behind.
Assign a second super admin so the tenant does not depend on one person, then give everyone else the least privilege their role needs. The Admin console has pre-built admin roles for help desk, groups, and user management that cover most small teams without granting full control.
Step three: point DNS at Google
Mail routing is controlled by the domain’s MX records. Google currently publishes a single MX target for Workspace domains, and older tenants still work with the previous five-record set; the Admin console shows the exact values for your tenant. Add the MX record at your DNS host, remove any MX records pointing at a previous mail provider, and wait for the change to propagate. Until the old records are gone, some mail will still land at the old provider.
Add the authentication records in the same session. These are what stop your domain being spoofed and what receiving servers check before accepting your mail.
| Record | Purpose | Where you get the value |
|---|---|---|
| MX | Routes inbound mail to Google’s servers | Admin console, Gmail setup wizard |
| TXT (SPF) | Lists servers allowed to send for the domain; include Google’s SPF record | Google Workspace Admin Help |
| TXT (DKIM) | Publishes the public key Google uses to sign outbound mail | Admin console, Apps, Google Workspace, Gmail, Authenticate email |
| TXT (DMARC) | Tells receivers what to do with mail that fails SPF or DKIM, and where to send reports | You write it; start with a monitoring policy |
Generate the DKIM key in the Admin console, add the TXT record it gives you, then return and click start authentication. Publish DMARC with a monitoring policy first and tighten it after you have read a few weeks of reports. If any other system sends mail as your domain, such as a CRM, a billing platform, or Amazon SES, include it in SPF and set up DKIM for it too, or DMARC will flag that mail.
Step four: settings to review once mail flows
With MX live, send a test message from an outside address and reply to it. Then work through the settings that a new tenant ships with defaults for.
- 2-Step Verification. Under Security, enforce it for all users after an enrolment period. Security keys or the Google Authenticator app are stronger than SMS codes.
- Password policy. Set a minimum length and require a change on next sign-in for accounts you created with temporary passwords.
- Gmail routing and compliance. Review spam settings, attachment rules, and whether to allow external forwarding. Disabling automatic forwarding to outside addresses removes a common data exfiltration path.
- Less secure apps and IMAP. Decide whether users may connect third-party mail clients, and prefer OAuth-based clients over app passwords.
- Data retention and Vault. If your plan includes Google Vault, set retention rules before you accumulate years of mail without a policy.
- Recovery information. Confirm the super admin has a recovery phone and email that belong to the company, not to whoever set the tenant up.
Taking over an existing tenant, and the terms you agreed to
When a tenant changes hands, the review is the same whether it came from a departing employee or a marketplace. Change every admin password, remove admin roles you do not recognise, check Security and then API controls for third-party apps with access to mail, and read the audit log for recent sign-ins. Confirm the billing contact and payment method in the Admin console under Billing, and confirm the domain’s registrar account is also under your control; a Workspace tenant is only as secure as the DNS that points at it.
Google Workspace runs under Google’s terms of service and acceptable use policy. Listings such as “Non Profit 300” restate the label attached to a tenant; eligibility for Google for Nonprofits is determined by Google, and using a nonprofit subscription for a commercial business breaks those terms. Read them before you rely on the tenant, and use the service for what it is licensed for.
Where to go next
The Workspace variants available on the marketplace are listed on the Buy Google Workspace Account page; each label restates the tenant’s state at listing time, so run the handover review above once you sign in.
Related reading in the Cloud Library:
- SPF, DKIM, and DMARC: email authentication setup
- Google Workspace explained: Gmail, the Admin console, and custom domains
- Transactional vs marketing email: infrastructure differences
Browse every guide in the Cloud Library.