How to Collect Your Google Workspace DNS Records and Send Them to Us

If you have bought Google Workspace and your domain's DNS is managed by Cynet, we can publish the records Google needs on your behalf. To do that we need the exact values Google generated for your domain — they are unique to your account, so we cannot look them up ourselves.

This guide shows you where each record lives inside the Google Admin console and gives you a template to paste into a support ticket.

Note: Google does not provide a single "download all my DNS records" button. Every record is shown separately, inside the setup task it belongs to. Collecting them is a matter of visiting four or five screens, which is exactly what the steps below walk through.

Before You Start: Check Who Controls Your DNS

We can only edit DNS for domains that point at Cynet's nameservers. Check yours first.

1. Go to whatsmydns.net.
2. Enter your domain and set the record type to NS.
3. Click Search.

You will also need the right level of access on the Google side. Reading the verification and MX records requires the Domain settings administrator privilege, and generating a DKIM key requires a super administrator account. If the screens below are missing or the buttons are greyed out, you are signed in with an account that lacks the privilege.

The Records Google Asks For

Most Google Workspace setups need these five. Not every domain needs all of them on day one.

Step 1: Find Your Domain Verification Record

This is the record Google uses to confirm you own the domain. It is usually the first thing the setup flow asks for.

1. Sign in to the Google Admin console as an administrator.
2. Go to Menu → Account → Domains → Manage domains.
3. Find your domain and click Verify domain.
4. Google asks you to choose your domain registrar. If yours is not listed, choose Other, then click Continue.
5. Google displays a TXT record section. Copy the whole Value.

google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ

Copy it including the google-site-verification= prefix. Without that prefix the record is meaningless.

Note: Do not click Confirm in the Admin console yet. That button tells Google to go and check DNS, and it will fail until we have published the record. Send us the value first, wait for us to confirm it is live, then come back and click it.

Step 2: Find Your Gmail MX Record

MX records control where incoming mail is delivered. This is the record that actually moves your email to Google.

1. In the Admin console, go to Menu → Account → Domains → Manage domains.
2. Click Activate Gmail next to your domain.
3. Google shows the MX record to add.

Tell us in your ticket whether Google showed you the single smtp.google.com record or a list of aspmx records, and paste exactly what you were shown.

Warning: Google requires that all other MX records be removed. Leaving your old mail host's MX record alongside Google's is the most common cause of mail arriving in two places, or vanishing entirely. We handle this removal for you, but we need to know it is intended — see Decide These Things First.

Step 3: Work Out Your SPF Record

SPF is a TXT record listing which servers may send email using your domain. If your domain sends only through Google Workspace, the record is exactly this:

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

Most Cynet customers are not in that simple position. If your website also sends mail — a WordPress contact form, an order confirmation, a booking notification — those messages leave from our web server, not from Google. Both senders must appear in one record.

A domain may have only one SPF record. Two records is not "extra coverage": it is a permanent error that makes SPF fail entirely. So the two records get merged into one, like this:

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

You do not have to build this yourself. Tell us in the ticket whether your website sends email, and we will merge your existing record with Google's and publish the combined result.

Two things worth knowing if you want to check our work:

• Everything after ~all is ignored, so a merged record always ends with ~all and nothing follows it.
• Once your MX points at Google, a leftover +mx in your old SPF record no longer authorises our web server. It authorises Google's inbound servers, which is not what you want. That is why the merged record names our server's IP address directly.

Step 4: Generate Your DKIM Key

DKIM adds a cryptographic signature to your outgoing mail. Google generates the key; it does not exist until you ask for it.

1. In the Admin console, go to Menu → Apps → Google Workspace → Gmail.
2. Click Authenticate email.
3. In the Selected domain menu, choose your domain.
4. Click Generate New Record.
5. Leave DKIM key bit length at 2048 and Prefix selector at google, then click Generate.
6. The page now shows two fields: DNS Host name (TXT record name) and TXT record value. Copy both.

Warning: Do not click Start authentication yet. Google's own instructions say to leave it until the DNS record is live. We will tell you when to come back and click it — and you must, because a DKIM key that is generated and published but never switched on does nothing.

Copying the DKIM value without breaking it

The value is the single most error-prone thing in this whole process. When you paste it into email or a ticket, the text box wraps it across several lines, and those line breaks are not part of the record.

• Paste it into a plain text editor first and join it into one continuous line.
• Keep the spaces after v=DKIM1; and after k=rsa;. Those belong to the record.
• Do not remove or add anything else, and do not retype any of it by hand.

Note: If you have only just switched Gmail on, the Generate New Record button may fail. Google requires a wait of 24 to 72 hours after enabling Gmail before a DKIM key can be created. This is normal, not a fault.

Step 5: Decide on DMARC (Later, Not Now)

DMARC tells receiving mail servers what to do with messages that fail SPF and DKIM. Gmail began enforcing its sender requirements more aggressively from November 2025, so it is worth having.

It is a TXT record on the host _dmarc. The safe starting value is:

v=DMARC1; p=none; rua=mailto:[email protected]

p=none means "monitor only, change nothing" — it is the correct place to start. Do not begin at p=quarantine or p=reject, which instruct other providers to bin mail that fails.

Do not publish DMARC at the same time as everything else. Google is explicit that SPF and DKIM should be authenticating successfully for at least 48 hours first. Raise DMARC as a follow-up ticket a few days after cutover and we will add it then.

Note: The address in rua= receives the daily reports, and there can be a lot of them. Point it at a mailbox you have set aside for the purpose, not your own day-to-day inbox.

Decide These Things First

These are decisions only you can make, and getting them wrong is what causes lost mail. Answer all four in your ticket.

1. What happens to your existing Cynet mailboxes? Once MX points at Google, mail stops being delivered to your cPanel mailboxes. Tell us whether to leave them in place as an archive or remove them.

2. Have you moved your old mail across? Messages already sitting in a cPanel mailbox do not travel to Google by themselves. If you need them, import them into Google Workspace, or download them in your mail client, before the cutover. Ask us if you want help with this.

3. Have you created the mailboxes in Google first? Every address that currently receives mail — including info@, sales@, and any forwarders — needs an equivalent user or alias in Google Workspace before the switch. Mail for an address Google does not know about will bounce.

4. When should we make the change? Incoming mail moves over as the MX change propagates, so there is a window where messages may land on either side. Outside business hours is usually the least disruptive.

Send Us This

Open a ticket at manage.cynet.com.my with the subject "Google Workspace DNS setup", and paste this template with your values filled in:

Domain:
Google Workspace admin email:
Nameservers currently: (Cynet / other - which)
Does your website also send email (contact form, WooCommerce, etc.)?
Existing cPanel mailboxes: keep as archive / remove
Old mail already migrated to Google?  Yes / No
Mailboxes and aliases already created in Google?  Yes / No
Preferred cutover time:

--- RECORDS FROM GOOGLE ---

VERIFICATION (TXT)
  Host:  @
  Value: google-site-verification=

MX
  Host:     @
  Priority: 1
  Value:    smtp.google.com
  (Or paste the full aspmx list if that is what Google showed you.)

SPF (TXT)
  Host:  @
  Value: v=spf1 include:_spf.google.com ~all

DKIM (TXT)
  Host:  google._domainkey
  Value: v=DKIM1; k=rsa; p=
  (One unbroken line, no line breaks.)

DMARC (TXT) - optional, add later
  Host:  _dmarc
  Value: v=DMARC1; p=none; rua=mailto:

Anything you cannot find, leave blank and say so. A partial ticket that says what is missing is far more useful than a guessed value.

Worked Example

Here is what a completed ticket looks like for a fictional domain, solarmora.com.my:

Domain: solarmora.com.my
Google Workspace admin email: [email protected]
Nameservers currently: Cynet (ns1-ns4.cynethost.com)
Does your website also send email? Yes - WordPress contact form
Existing cPanel mailboxes: keep as archive
Old mail already migrated to Google? Yes, via Gmail import
Mailboxes and aliases already created in Google? Yes - info@, sales@, admin@
Preferred cutover time: Saturday after 6pm

--- RECORDS FROM GOOGLE ---

VERIFICATION (TXT)
  Host:  @
  Value: google-site-verification=rXOxyZounnZasA8Z7oaD3c14JdjS9aKSWvsR1EbUSIQ

MX
  Host:     @
  Priority: 1
  Value:    smtp.google.com

SPF (TXT)
  Host:  @
  Value: v=spf1 include:_spf.google.com ~all

DKIM (TXT)
  Host:  google._domainkey
  Value: v=DKIM1; k=rsa; p=MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAraC3pqvqTkAfXhUn7Kn3JUNMwDkZ65ftwXH58anno/bElnTDAd/idk8kWpslrQIMsvVKAe...

Note that this customer's website sends mail, so we would publish a merged SPF record naming both Google and our web server rather than the plain value they pasted.

What We Do After You Send It

Once we have your records:

1. Publish the records in your domain's DNS zone, splitting the DKIM value into the quoted segments DNS requires.
2. Remove conflicting records — the old MX entries, and the SPF and DKIM records cPanel generated for our own mail server. Leaving those alongside Google's is what breaks authentication.
3. Merge SPF into a single record if your website also sends mail.
4. Switch mail routing — in cPanel, your domain is set to Local Mail Exchanger by default, meaning the server delivers mail for your domain to itself. We change it to Remote Mail Exchanger. Without this step, mail sent from your own website or from another account on the same server never reaches Google, even though outside mail arrives correctly.
5. Confirm back to you when the records are live, so you can return to the Admin console and click Confirm and then Start authentication.

What to Expect Afterwards

To see what is actually published at any point, use Google's Admin Toolbox Dig tool and look up your domain's MX and TXT records.

Frequently Asked Questions

Can Cynet just log in to my Google account and get the records?

No. We have no access to your Google Workspace account and would not ask for it. The records are generated per domain inside your Admin console, so an administrator on your side has to copy them out.

Will my website go down when we switch to Google Workspace?

No. Only the mail-related records change. The A record that points your domain at your website, and your SSL certificate, are untouched.

Do I still need my Cynet hosting if email moves to Google?

Yes, if your website is hosted with us. Google Workspace handles mail only. Your site, databases, and files stay where they are.

My DKIM record is rejected as too long. What now?

That is expected for a 2048-bit key and it is our problem, not yours. Send us the full unbroken value and we will publish it in the split form DNS requires. If your DNS is hosted elsewhere and their panel refuses it, regenerate the key at 1024 bits instead.

The Admin console still says my DNS records need updating. Did it fail?

Probably not. That message can persist for up to 48 hours after a correct record is published, and Google's documentation says to ignore it. Do not regenerate the DKIM key — that would invalidate the record already published. If it is still showing after 48 hours, open a ticket and we will check what is actually resolving.

Can I keep some mailboxes on Cynet and move others to Google?

Not for the same domain. MX records apply to the whole domain, so mail for that domain goes either to Google or to us. A split is only possible using a subdomain, which needs separate records. Ask us if this is what you need.

What about SPF if I send newsletters through Mailchimp or a similar service?

Those senders must appear in the same single SPF record. Tell us which services you use and we will include them. Related reading: Understanding DNS Records and Fix: Email to Gmail Blocked.