Setting up Google Workspace email for your business involves more than creating accounts. The part most people skip is the DNS configuration that actually makes your emails deliverable. Without correct SPF, DKIM, and DMARC records, your new professional addresses could end up in spam folders before anyone reads them.
This guide walks through the complete Google Workspace email setup process with a focus on the DNS records that matter. It covers what each record does, the order to set them up, how to verify everything is working, and the mistakes that cause problems later. The guidance applies to UK small businesses setting up their first professional email through Google Workspace.
Why Google Workspace email needs proper DNS configuration
When you create a Google Workspace account, Google provides your email service. But the internet needs to know that your domain belongs to you and that Google is allowed to send mail on your behalf. That is what DNS records do.
DNS stands for Domain Name System. It acts like an address book for the internet. When someone sends an email to hello@yourbusiness.co.uk, mail servers check your DNS records to verify that the message is legitimate before delivering it.
Google Workspace handles the actual email hosting. Your domain registrar and DNS provider handle the records that tell the world where to find your email and how to verify it is genuine. Getting these records right means the difference between emails landing in inboxes and disappearing into spam folders.
What you need before starting
Before configuring anything, gather the following:
- Admin access to your Google Workspace account to find your verification code and DKIM key
- Access to your domain registrar where your domain is registered, such as GoDaddy, Namecheap, or 123-Reg
- Access to your DNS provider which might be the same as your registrar or a separate service like Cloudflare
- Your domain name that you want to use with Google Workspace
Most UK small businesses register their domain through one of the major registrars. The DNS management interface varies between providers, but the records you need to create are standardised.
Step 1: Verify your domain with Google Workspace
Google needs proof that you own the domain before it will host email for it. Google offers several verification methods, but the HTML meta tag method is usually the fastest for small businesses.
In your Google Workspace admin panel, go to Domains, add your domain, and select Verify with a domain provider. Choose the HTML meta tag option. Google will give you a unique meta tag that looks like this:
<meta name="google-site-verification" content="YOUR_UNIQUE_CODE" />Log in to your domain registrar and access the DNS settings for your domain. Look for a section called CNAME records, TXT records, or advanced DNS. Create a new TXT record with the name field set to @ (or your domain name) and the value field containing the verification code Google gave you.
After saving the record, return to Google Workspace and click Verify. DNS changes can take anywhere from a few minutes to 48 hours to propagate across the internet, though it is usually much faster with major UK registrars.
Step 2: Set up your MX records for email delivery
MX stands for Mail Exchange. These records tell other mail servers where to deliver email sent to your domain. Once verified, you need to point your MX records to Google's mail servers.
Google provides specific MX record values that look like:
ASPMX.L.GOOGLE.COM
ALT1.ASPMX.L.GOOGLE.COM
ALT2.ASPMX.L.GOOGLE.COM
ALT3.ASPMX.L.GOOGLE.COM
ALT4.ASPMX.L.GOOGLE.COMEach record has a priority number. Lower numbers have higher priority. Set up all five MX records with their assigned priorities. In your DNS panel, you will typically need to add five separate MX records.
If you were using email with your domain before, remove any existing MX records from previous hosting. Leaving old MX records alongside new ones causes conflicts and unpredictable email routing.
Test your MX setup by sending an email to one of your new addresses from an external account. If the email arrives, the MX records are working.
Step 3: Configure SPF to authorise Google to send on your behalf
SPF (Sender Policy Framework) is a TXT record that lists which mail servers are allowed to send email from your domain. Without it, other mail servers have no way to verify that Google is legitimately sending mail for you.
Your SPF record is a single line of text that goes into a TXT record. For Google Workspace, the basic record looks like:
v=spf1 include:_spf.google.com ~allBreak down what this does:
- v=spf1 declares this as an SPF record
- include:_spf.google.com tells receivers to check Googles SPF records too
- ~all means soft fail. Emails from servers not listed should be flagged but not rejected
The ~all at the end is the most common setting for small businesses. Some administrators use -all for hard fail, which rejects non-listed servers, but this can cause issues if you ever need to send from another service later.
Add this as a TXT record with the name field set to @ or your domain. If you already have an SPF record from another service, you cannot simply overwrite it. You need to combine both into a single record using multiple include statements.
For a deeper explanation of how SPF works alongside its companions, see the guide to SPF, DKIM and DMARC explained.
Step 4: Set up DKIM for email authentication
DKIM (DomainKeys Identified Mail) adds a digital signature to your outgoing emails. When a mail server receives an email from your domain, it can verify the signature using your public key published in DNS. This proves the email was not altered in transit and genuinely came from your domain.
Unlike SPF, which lists authorised servers, DKIM works through cryptographic keys. Google generates a pair of keys for you: a private key that signs your emails, and a public key that goes into your DNS records.
In Google Workspace admin, go to Apps, then Google Workspace, then Gmail, then Authenticate email. Select your domain and click Generate new record. Google will generate a DKIM key with a domain selector, typically something like google.
The resulting TXT record will have a name in this format:
google._domainkey.yourdomain.co.ukAnd a value that is a long string of characters containing your public key. Copy both parts exactly as shown and create a new TXT record in your DNS settings.
Allow up to 48 hours for the DKIM record to propagate. In Google Workspace, you can click the Verify button once the record appears to be active. Google will check DNS and confirm whether the key is properly published.
After verification, Google will start signing outgoing emails automatically. This applies to all email sent through your Google Workspace accounts.
Step 5: Add DMARC to protect your domain reputation
DMARC (Domain-based Message Authentication, Reporting and Conformance) builds on SPF and DKIM. It tells receiving mail servers what to do if an email fails authentication checks and sends you reports about authentication activity.
DMARC records are more complex than SPF or DKIM. A basic DMARC record looks like:
v=DMARC1; p=quarantine; rua=mailto:your@email.comBreak down the components:
- v=DMARC1 declares this as a DMARC record
- p=quarantine tells receivers to send failing emails to spam rather than rejecting them outright
- rua=mailto: specifies where to send aggregate DMARC reports
The p tag (policy) has three options:
- none — monitor only, take no action on failing emails
- quarantine — send failing emails to spam
- reject — refuse to accept failing emails entirely
Start with p=none to receive reports and see what traffic is failing. After a week or two of reports, you can assess whether legitimate email is being flagged. If everything looks clean, move to p=quarantine. Only use p=reject once you are confident your setup is solid and all legitimate sending sources are covered.
The rua tag sends aggregate reports to an email address you specify. These reports arrive periodically, typically daily, and show which servers are sending email from your domain and whether they pass authentication. Review these reports to catch any unauthorised sending early.
Add the DMARC record as a TXT record with the name _dmarc.yourdomain.co.uk.
Verifying your complete email setup
After configuring all records, test the setup systematically. Use a free DMARC lookup tool to verify your DMARC record is published correctly. Send a test email to a Gmail address and check the email headers. Look for authentication results that show SPF pass, DKIM pass, and DMARC pass.
In Gmail, open the test email, click the three dots next to the reply button, and select Show original. Search for Authentication-Results. You should see entries like:
Authentication-Results: mx.google.com;
spf=pass (google.com: domain of your@yourdomain.co.uk designates ...);
dkim=pass ...;
dmarc=pass ...If any of these show fail instead of pass, check that specific record in your DNS settings. Common issues include typos in TXT record values, incorrect record names, or DNS propagation delays.
Common mistakes that cause email problems
Several issues come up repeatedly when small businesses set up Google Workspace email.
Overwriting instead of combining SPF records. If you previously used another email service with an SPF record, adding Google Workspace means updating the existing record, not replacing it. A common error is creating a second SPF record, which causes authentication failures.
Leaving old MX records active. If your previous email provider still has MX records pointing to their servers, incoming mail may split between providers. Remove all old MX records before adding Googles.
Incorrect DKIM selector names. The DKIM record name must exactly match what Google generated, including the domain selector prefix. Missing or mistyping the selector means the record cannot be found during email verification.
Setting DMARC to reject before testing. Moving straight to p=reject can block legitimate email if your SPF or DKIM is misconfigured. Start with monitoring mode.
Not waiting for DNS propagation. DNS changes are not instant. Some systems check DNS frequently, but others cache records for hours. If verification fails immediately, wait and retry before making changes.
What happens if your email still goes to spam
Even with correct DNS records, other factors affect email deliverability. Your domain age matters: brand new domains have less reputation and may face extra scrutiny. Your sending practices matter: high complaint rates or spammy content triggers filters. Your domain IP reputation matters if you send large volumes.
For most UK small businesses just starting with Google Workspace, correct SPF, DKIM, and DMARC records resolve the majority of deliverability issues. If problems persist, check whether your domain has been flagged previously or whether your email content triggers spam filters.
When to set up Google Workspace email yourself and when to get help
Setting up the core records is straightforward if you are comfortable navigating DNS settings and reading technical instructions. The process takes most people an hour or two, including waiting time for propagation.
Consider getting help if your domain is already used for complex email routing, if you have multiple subdomains with different email providers, if you have had previous email deliverability problems, or if you manage multiple domains and want them configured consistently.
For businesses setting up their first professional email system, working through this process yourself builds useful understanding of how your domain and email work. For businesses that would rather focus on their work, a quick call with an IT specialist who handles DNS and email configuration regularly can get everything verified and working without trial and error.
Maintaining your email authentication over time
Once configured, your email authentication records do not need frequent changes. However, review them when you add new services that send email from your domain, such as email marketing platforms, invoicing software, or contact form plugins. Each new service needs to be added to your SPF record.
Check your DMARC reports periodically, especially in the first few weeks after setup. They reveal whether any legitimate email sources are being flagged and whether anyone is attempting to send email pretending to be your domain.
If you ever switch email providers in the future, update your SPF record to remove the old provider and add the new one. Leaving orphaned entries in SPF records does not break anything but adds unnecessary complexity.