DNS Setup

Before Google Workspace can start receiving mail for your domain, you need to prove you own the domain and point its email traffic to Google's servers. This guide covers the exact DNS records to add — and how to verify them — so your setup goes smoothly.

What DNS records you need

Where to add these records. Log in to the DNS provider where your domain's nameservers are managed — commonly Cloudflare, GoDaddy, Namecheap, or your domain registrar's own DNS panel.

Step 1 — Get the verification value from Google Admin Console

Google generates a unique TXT verification string for your domain.

1. Sign in to admin.google.com as a super-admin.
2. If you're adding a new domain, Google shows the verification step automatically. For an existing domain, go to Account → Domains → Manage domains, select the domain, and click Verify domain ownership.
3. Choose the TXT record verification method.
4. Copy the long string that starts with google-site-verification=....

Step 2 — Add the TXT verification record to your DNS

1. Open your DNS provider's control panel.
2. Add a new TXT record at the root (apex) of the domain — leave the Name or Host field blank or enter @.
3. Paste the Google verification string into the Content or Value field.
4. Save the record.

DNS propagation typically takes 5–10 minutes but can take up to 48 hours. If Google can't verify immediately, wait a few minutes and click Verify again in Admin Console.

Step 3 — Add MX records for Gmail

Once the domain is verified, Google prompts you to activate Gmail. You do this by adding Google's MX records and removing any existing MX records from previous mail hosts.

Google's MX records (priority and value):

1. In your DNS provider, delete any existing MX records.
2. Add the five Google MX records above exactly.
3. Return to Google Admin Console and click Activate Gmail.

If the domain already receives mail elsewhere, plan a cut-over window. Removing old MX records stops delivery to the previous host, so switch during a low-traffic period.

Step 4 — Add the SPF record

An SPF record tells receiving servers which hosts are allowed to send mail for your domain. Without it, your messages are more likely to be flagged as spam.

1. Add a new TXT record at the root of the domain.

2. Set the value to:

   v=spf1 include:_spf.google.com ~all
   

Only one SPF record per domain. If you already have an SPF record, merge Google's include into it instead of creating a second TXT record. For example: v=spf1 include:_spf.google.com include:another-provider.com ~all.

Step 5 — Generate and add DKIM (optional but recommended)

DKIM adds a cryptographic signature to every email you send, proving it came from your domain and wasn't altered in transit.

1. In Google Admin Console, go to Apps → Google Workspace → Gmail → Authenticate email.
2. Click Generate new record and choose your domain.
3. Copy the DNS Host name (selector) and TXT record value.
4. In your DNS provider, add a TXT record using the selector as the name (e.g. google._domainkey) and the value Google provided.
5. Return to Google Admin Console and click Start authentication.

Activate DKIM only after DNS has propagated. Google checks the public key in DNS before it starts signing messages. If you start authentication too early, Gmail may show "DKIM: FAIL" on outgoing mail.

Step 6 — Add a DMARC record (recommended)

DMARC builds on SPF and DKIM by telling receiving servers what to do when authentication checks fail. Start in monitoring mode so you can review reports before enforcing a policy.

1. Add a TXT record at _dmarc (e.g. _dmarc.yourdomain.com).

2. Set the value to:

   v=DMARC1; p=none; rua=mailto:your@email.com;
   

   Replace your@email.com with an address where you want to receive aggregate reports.

p=none means monitor only — mail that fails SPF or DKIM is still delivered, but you get reports. Once you're confident your setup is correct, you can tighten the policy to p=quarantine or p=reject.

Step 7 — Verify everything in Google Admin Console

Return to Google Admin Console and confirm each step shows a green check:

• Domain ownership — verified
• Gmail activation — active
• SPF, DKIM, DMARC — visible under Apps → Google Workspace → Gmail → Authenticate email

Advanced routing: split delivery and legacy mail servers

Most Mercurie customers should use direct Gmail delivery with Google's MX records. Some teams need a staged migration where some users receive mail in Gmail and others still receive mail in an older mail system. Google calls this split delivery.

For split delivery, the usual shape is:

1. Your domain's MX records point to Google.
2. Gmail receives the message first.
3. A Gmail routing rule sends selected recipients to the non-Gmail or legacy mail server.

You can configure this in Google Admin under Apps → Google Workspace → Gmail → Routing after adding the legacy server as a mail route. Google documents the full flow in its guides for split delivery and Gmail routing settings.

Use split delivery carefully. A user should normally receive mail in either Gmail or the legacy system, not both, unless you intentionally configure dual delivery. If you are migrating from an old mail host, contact support before changing MX or routing rules so the cut-over plan is clear.

Troubleshooting

Verification keeps failing

• Double-check the TXT record is at the root (apex), not a subdomain like www.
• Make sure there are no extra spaces or line breaks in the verification string.
• Confirm you're editing the DNS zone that is currently live — check the nameservers listed on your domain registration against the panel you're using.

Mail still goes to the old host

• Ensure you removed the previous MX records. Keeping old and new MX records together causes unpredictable routing.
• Some DNS providers add a trailing dot automatically; others require it. Check your provider's documentation.

SPF causing bounces

• You can only have one SPF TXT record at the root. Merge multiple includes into a single record.
• If you use additional senders (marketing platforms, support desks), add their includes before the ~all mechanism.

Propagation delays

• Lower the TTL on DNS records before making changes if your provider allows it — this speeds up propagation.
• Use a public DNS lookup tool (e.g. dig TXT yourdomain.com @8.8.8.8) to test whether a record is visible outside your provider's own resolver.

Common questions

Can I add these records before buying Google Workspace? You can add the SPF, DKIM, and DMARC records anytime. The TXT verification string and MX records are specific to your Google Workspace account, so you'll need to generate those inside Google Admin Console first.

What if my DNS provider doesn't support @ as the host? Use a blank Name or Host field, or enter your full domain name — most providers treat all three as the root. If you're unsure, check your provider's help docs.

Do I need to restart anything after changing DNS? No. DNS changes propagate automatically. Google Admin Console re-checks records when you click Verify; mail routing switches as soon as MX records are live.

Can I have multiple DKIM selectors? Yes. Google uses one selector per domain by default, but you can rotate or add selectors. Just make sure each selector points to a unique TXT record and you activate the corresponding key in Admin Console.

How long should I keep p=none for DMARC? Most admins monitor for 2–4 weeks to catch misconfigured senders before moving to p=quarantine. Only move to p=reject once you're confident no legitimate

mail is failing authentication.

Need help?

The Support entry on the Mercurie dashboard sidebar opens a ticket with the ops team. We're happy to help with verification strings, MX record syntax, or troubleshooting propagation delays.