Google Workspace gives a company Gmail mailboxes like name@company.uz, shared calendars, Drive and Meet. Google will never let anyone run mail on a domain they do not control, so the first task after signing up is to prove the domain is yours. You do that by adding a special TXT record from Google to the domain's DNS zone. After verification, a few more records are needed for mail to work.
Why a TXT record proves ownership
Only the domain owner, or someone they authorize, can change the DNS zone. Google gives you a unique random string and waits to see it in the zone. If it appears, you control the zone and the domain is yours. The record does not affect the website, mail or anything else; it is simply a publicly visible key.
Getting the code and adding the record
The signup wizard usually opens the verification page for you. If you skipped it, go to the Google Admin console and open Account, then Domains, then Manage domains, and follow the verify link. Copy the string beginning with google-site-verification= exactly. If the domain is registered through sayt.uz and uses our nameservers, create a TXT record in the domain's DNS section of the cabinet; otherwise add it wherever your nameservers point.
| Type | Name | Value |
|---|---|---|
| TXT | @ | google-site-verification=AbC123...xyz |
The domain may already have TXT records such as SPF. Do not merge Google's string into them; add it as a separate record, since several TXT records on one name are perfectly normal. Then click verify in the Admin console. It often passes within an hour but can take longer depending on TTL. Keep the record afterwards, because Google rechecks ownership. If TXT is impossible, Google also offers CNAME verification with a value ending in googlehosted.com.
dig +short TXT example.uz
nslookup -type=TXT example.uz 8.8.8.8If the string does not appear, the record went into the wrong panel, the name field contains extra text (producing example.uz.example.uz), or the change has not propagated yet.
MX records for Gmail
Verification only proves ownership; mail reaches Gmail once MX records point to Google. Google's current instructions recommend a single MX record for new setups: smtp.google.com with priority 1. The older five ASPMX.L.GOOGLE.COM and ALT records still work. Remove MX records that point to your old hosting mail, or messages will be split between the two. Plan the migration of old mailboxes in advance, because new mail goes to Google as soon as MX changes.
SPF, DKIM and DMARC
SPF lists the servers allowed to send for your domain; for Google it is v=spf1 include:_spf.google.com ~all. Keep exactly one SPF record, merging other senders such as your web hosting into it. DKIM signs every message: generate it in the Admin console under Apps, Google Workspace, Gmail, email authentication, add the google._domainkey TXT record, then click Start authentication. DMARC tells receivers what to do with unauthenticated mail; start with a relaxed policy.
@ TXT "v=spf1 include:_spf.google.com ~all"
google._domainkey TXT "v=DKIM1; k=rsa; p=MIIBIjANBgkq..."
_dmarc TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.uz"Example: a private clinic in Tashkent
Staff at a private clinic in Yunusabad had been using personal Gmail addresses, so patient correspondence was scattered. The clinic signed up for Google Workspace and verified example.uz. The administrator added the TXT record, and after verification switched MX to smtp.google.com one evening after hours, updated SPF and turned on DKIM. The next morning reception, the lab and the head doctor were using corporate mailboxes, while the appointment form on the website kept sending mail from the hosting server because that server was included in the SPF record.