Domains, verification and DNS records

Sofia's second session starts with a question for Owen: "How many email domains does Birchline actually receive mail for?" Owen guesses one. The answer, after an hour with the Exchange accepted-domains list and the company's domain registrar account, is three. There is birchline.example, the company's main domain since 2009. There is birchlineoutfitters.example, the old domain from before a 2009 rebrand, which still receives a trickle of mail from long-standing suppliers and appears on some warranty cards. And there is trailheadrentals.example, the domain of Trailhead Rentals, a 48-person kayak and bike rental business Birchline bought in September 2026. Each will be handled differently in Google Workspace, and choosing the right type for each is the subject of this lesson.

Why domains matter in Workspace

A Google customer account is built around domains. Every user's sign-in name is an email address at a domain the organization has proved it owns, and Google will not deliver mail for, or create accounts at, a domain until that proof is in place. Domain decisions are also hard to undo. Changing the primary domain later is possible but disruptive, and a domain that is verified in one Google account cannot be added to another until it is removed from the first. Getting the design right before users are created saves weeks of clean-up.

Primary domain, secondary domains and domain aliases

Workspace has three kinds of domain, and the exam expects you to know when to use each.

The primary domain is the one the account was created with. It cannot be removed while the account exists, and every user and group needs an address at some domain in the account; most will use the primary one. Birchline's primary domain is birchline.example, set when Farah created Cloud Identity for Google Cloud. That choice carries over to Workspace.

A secondary domain is an additional domain whose users are separate people with their own accounts. Someone at a secondary domain has a sign-in address such as maya.lund@trailheadrentals.example, their own mailbox and their own license. Secondary domains suit a company that runs several brands or businesses with different identities, such as Trailhead Rentals, whose staff and customers know the Trailhead name.

A domain alias gives every user in the primary domain an extra address at another domain automatically. If birchlineoutfitters.example is a domain alias of birchline.example, then mail sent to owen.mitchell@birchlineoutfitters.example arrives in Owen's normal mailbox, without anyone creating anything per user. Domain aliases suit old domains, regional variants and common misspellings that should simply land in the same mailboxes.

Two details trip up new administrators. First, a domain alias applies to users at the primary domain only; users at secondary domains do not automatically get alias addresses, though a secondary domain can have its own alias. Second, a domain alias does not create sign-in names. Owen still signs in as owen.mitchell@birchline.example; the alias address only receives mail. If someone wants to send mail from an alias address, they set it up in Gmail's send-mail-as settings.

There is also a per-user version. A user alias (sometimes called an email alias) is an extra address for one user, such as jobs@birchline.example on the recruiter's account. Each user can have a number of aliases, which Google's documentation lists. Lesson 3 shows how to add them. When a shared address is needed by several people, a group or collaborative inbox (lesson 5) is usually better than an alias on one person's account, because it survives that person leaving.

Proving you own a domain

Before Google will accept a domain, an administrator must verify it: prove control of the domain's DNS by publishing a value that Google asks for. The standard method is a TXT record, a text entry in the domain's DNS zone. Google shows a unique verification string in the console, the administrator adds it at the DNS host (the registrar or DNS provider), and Google checks for it. Other methods, such as a CNAME record or, for some cases, a file or tag on the domain's website, also exist; the TXT method is the one to know first.

birchlineoutfitters.example.   3600   IN   TXT   "google-site-verification=Xb7…(unique string from the Admin console)…"

Each part of the record means something. The name is the domain itself (many DNS hosts write it as an @ sign). 3600 is the time to live (TTL), the number of seconds other DNS servers may cache the answer. TXT is the record type, and the quoted value is the string Google issued. Leaving the verification record in place after verification is recommended; Google may check it again later, and removing it can cause the domain to become unverified.

Verification usually succeeds within minutes, but DNS changes can take time to spread, and Google's help pages allow up to about 48 hours. If verification fails, the usual causes are a typo in the string, the record added to the wrong domain or subdomain, the record added at a DNS host that is not actually authoritative for the domain (for example, the registrar's DNS when the domain's name servers point elsewhere), or a stale cached answer that a lower TTL would have avoided.

Finding who controls DNS

Owen's first real task is not in the Google console at all. Birchline's domains were registered over fifteen years by three different people, and he needs to know where each domain's DNS is actually hosted. He looks up each domain's name servers (NS records), which point to the DNS provider that answers for it, and compares them with the accounts Birchline has.

The inventory explains why Trailhead has to wait. Until Birchline takes over the registrar and DNS accounts for trailheadrentals.example, nobody can publish a verification record, so the domain cannot be added. Owen opens a ticket with the acquisition team to transfer the accounts, and Sofia notes that this is the most common reason Workspace projects slip: someone outside IT controls the DNS.

The DNS records Workspace cares about

Verification is only the first record. A domain that will send and receive mail through Gmail needs several more, and Owen will set them up in GCP-211. Here is the overview, so that he can plan the DNS work with the network team now.

The MX records are the ones that move mail, so they are the ones Sofia will not touch until the migration plan says so. Today, Birchline's MX records point to its Exchange servers. If Owen changed them to Google during the pilot, all mail for all 1,100 staff would start arriving in Gmail, where only 14 people have mailboxes. Adding and verifying a domain does not change mail flow; changing MX records does. Lesson 11 explains how organizations keep both systems working during a migration.

Adding domains in the Admin console

Domains are managed in the console's account settings, on the page for domains. To add one, an administrator chooses whether it is a secondary domain or a domain alias, enters the name and follows the verification steps. Owen adds birchlineoutfitters.example as a domain alias in about ten minutes: he enters the domain, copies the string, publishes the TXT record at Registrar A and waits. Twenty minutes later it shows as verified.

He then checks the result with a test. A message sent from his personal email to owen.mitchell@birchlineoutfitters.example does not arrive in Gmail. That is expected: the alias exists in Google, but the domain's MX records still point to Exchange, so the mail went to Exchange. The alias will start delivering to Gmail only when the domain's MX records change during the migration.

# Check a planned list of domains for clashes before adding them to the account.
planned = [
    ("birchline.example", "primary"),
    ("birchlineoutfitters.example", "alias"),
    ("trailheadrentals.example", "secondary"),
    ("shop.birchline.example", "secondary"),
]
verified_elsewhere = {"trailheadrentals.example"}   # still in the former owner's Google account
dns_editable = {"birchline.example", "birchlineoutfitters.example"}

primary = [d for d, kind in planned if kind == "primary"]
print("primary domains:", len(primary))
for domain, kind in planned:
    issues = []
    if domain in verified_elsewhere:
        issues.append("remove from the other Google account first")
    if domain not in dns_editable and not any(domain.endswith("." + p) for p in dns_editable):
        issues.append("no DNS access yet")
    if kind != "primary" and any(domain.endswith("." + p) for p in primary):
        issues.append("subdomain of the primary; a plain subdomain may be all you need")
    print(f"{domain:30} {kind:10}", "; ".join(issues) or "ready")

primary domains: 1
birchline.example              primary    ready
birchlineoutfitters.example    alias      ready
trailheadrentals.example       secondary  remove from the other Google account first; no DNS access yet
shop.birchline.example         secondary  subdomain of the primary; a plain subdomain may be all you need

The check surfaces two problems at once. Trailhead's domain is blocked twice over: Birchline cannot edit its DNS yet, and the former owner had once signed up for a free Google trial with it, so it is still verified in someone else's Google account. The domain must be removed from that account (or the account closed) before Birchline can add it. The shop subdomain raises a design question rather than a blocker, discussed next.

Subdomains and when to use them

A subdomain such as shop.birchline.example can be added as a secondary domain if separate users really need addresses there. Often, though, a subdomain is better left to DNS alone. Jules Baptiste's e-commerce team wanted shop.birchline.example for order confirmation emails, but those are sent by the shop's mail service, not by people with mailboxes. Sofia's view is that the subdomain belongs in DNS with its own SPF and DKIM records for the sending service, not in Workspace as a secondary domain.

The general rule: add a domain to Workspace only when people (or groups) need addresses there. Domains used only by websites or by automated sending services stay in DNS.

Planning domain changes safely

Sofia closes with three rules she has learned from earlier migrations. Lower the TTL on any record you plan to change a day or two in advance, so that a mistake can be corrected quickly. Never change MX records until the mailboxes they will point to exist and have been tested. And keep a written record of every DNS change, with the old value, because the old value is what you need when something has to be rolled back.