A client buys a second domain and the question arrives the same way every time: we also own the new name, can you make email work on it. In the Admin console there are two ways to add it. They sit on the same screen and they lead to very different months. One gives the people you already have a second address at no extra cost. The other creates a separate set of users, each one paid for.
Pick wrong and you find out late. We have been called in to unpick a secondary domain full of empty mailboxes nobody needed, and to explain to a sales team why their shiny new address cannot sign in. Neither repair is hard. Both were avoidable. Here is how we decide, and the DNS that has to follow either choice.
What a domain alias actually does
Google's documentation calls it a user alias domain. The Admin console calls it a domain alias. Same thing. You add the domain, verify that you own it, and Google creates the matching alias for every user you already have. If example.com is your primary domain and you add solarmora.com as an alias, then bob@example.com also receives mail at bob@solarmora.com, in the same mailbox, with no second account and nothing extra to pay. People can send from either address.
Two consequences are worth saying out loud. An alias is an address, not an account: no separate mailbox, no separate Drive, no separate anything. And nobody signs in with it. Sign-in stays on the primary address. That single fact is the most common support ticket in the week after an alias domain goes live.
What a secondary domain actually does
A secondary domain is a second set of people. You add and verify it the same way, then you create users at that domain, and each of those users is a real account with its own mailbox, its own Drive and its own license to pay for. Administration stays in one place: all domains and all users are managed from the primary domain's Admin console, so you get one console and one bill.
The relationship is a dependency rather than a partnership. A secondary domain hangs off the primary one, and a few things belong to the primary domain alone. You can specify only one logo across your domains, and you cannot set up a separate billing address for a secondary domain.
Which one to add
Read the whole decision as one question: does the new domain need its own people? If it does not, and the same team simply wants to be reachable at both names, an alias is the entire job. If the new name comes with staff, or with a team that should not see the first domain's files, it is a secondary domain.
| What you need | Domain alias | Secondary domain |
|---|---|---|
| A second address for the people you already have | Yes, created for every existing user | No, you create each user yourself |
| Its own users and mailboxes | No, one mailbox serves both addresses | Yes, one account per person |
| Cost for a person at the new domain | No extra license | A paid license for each account |
| Signing in at the new domain | Not possible, people sign in with the primary address | Yes, the account lives at that domain |
| Where you can attach it | Admin console attaches an alias to the primary domain only; the Directory API is needed to alias a secondary domain | Added as a domain in its own right |
| How many you get | Up to 20 domain aliases | Up to 599 additional domains in total, aliases included |
Those two limits are the ones Google publishes in its multiple domains FAQ, checked 6 November 2026. The 599 figure is the whole allowance, so secondary domains and aliases draw from the same pool. Nonprofit accounts are capped far lower, at five domains in total.
What we check before adding anything
The choice is the easy half. On a client project we go through four things first, because all four have bitten someone.
- Where mail for that domain lives today. Adding the domain to Workspace does not move anything. The MX change moves it, and if the domain has a live mailbox at an old host, that is a cutover with its own plan. We have written up how to change MX records without losing mail.
- Who already sends as that domain. If the name has been in use, something is already sending from it: an invoicing system, a CRM, a store, a newsletter. Those senders do not stop when you add the domain to Workspace, and they will fail authentication unless you account for them.
- What DNS is already sitting at the new domain. A leftover SPF record from the old host, an abandoned DKIM selector, and now and then a DMARC record set to reject that will start rejecting your own mail the moment you send the first message.
- Whether anyone is planning to make the new name the main one. This is the question people forget to ask, and it decides the answer on its own. More on that below.
If you want to see what the new domain currently claims about itself before you touch anything, check it:
The DNS a new domain needs
Adding a domain in the Admin console does not create DNS. Every domain you add, alias or secondary, is its own zone with its own records, and nothing is inherited from the primary domain. This is where most of the broken multi-domain setups we see went wrong: the domain was added, and then nobody published anything.
MX, so the domain can receive
Google Workspace needs one MX record. The value is smtp.google.com at priority 1, with the host field left blank or set to @ for a root domain, or set to the subdomain name for a subdomain. Older zones carry a set of records whose values begin with aspmx; Google describes those as legacy values that are still supported, so an older setup is not broken by default. New MX records can take up to 72 hours to be recognised.
Type Host Value Priority
MX @ smtp.google.com 1SPF, so the domain can send
Each domain must have its own SPF record, and if you send from subdomains, each subdomain needs one too. For a domain that sends only through Workspace, that is a single TXT record:
example2.com. TXT "v=spf1 include:_spf.google.com ~all"If the store, the invoicing provider or the newsletter also send as that domain, their includes belong in the same record, because a domain gets one SPF record and not two. Watch the budget while you do it: a record is limited to ten lookups, and stacking a few providers burns through that faster than people expect. We go through the arithmetic in the fix for SPF too many DNS lookups.
DKIM, so the signature matches the address people see
This is the step that gets skipped, and the reason it gets skipped is that nothing appears to break. DKIM is configured per domain. On the Authenticate email page you pick the domain from the Selected domain menu, generate a unique key for that domain, publish the TXT record in that domain's DNS, and then start authentication. Google's instruction is explicit: if you are setting up DKIM for more than one domain, complete the steps for each domain. Allow up to 48 hours after publishing the key for DKIM to start working.
Leave it undone and mail still goes out, which is exactly why it goes unnoticed for months. Gmail signs outgoing messages with a default key on the gappssmtp.com domain. That signature is real and it verifies, and it does not carry your domain, so a DMARC check on the address the recipient actually reads has nothing but SPF holding it up. One forward along the way and SPF is gone too, which is the failure we describe in why forwarding breaks SPF.
DMARC, so you find out what is happening
A DMARC record is a TXT record at _dmarc under the domain, published per domain like the other two. Start at p=none with a reports address, read a couple of weeks of reports, then tighten. On a brand new name that has never sent anything, the ramp is short and the reports are quiet. If the reports address is at a different domain than the record, that other domain has to publish a record authorising it, or the reports are never sent.
_dmarc.example2.com. TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"Four traps that cost a week
An alias cannot be promoted to primary. If the business might eventually run under the new name, adding it as an alias is a dead end. You cannot swap a user alias domain with your primary domain. The way out is to remove the alias and add the same domain back as a secondary domain, which means waiting on the removal and then on verification again. When a client says they might move to the new name, we add it as a secondary domain from the start, even if nobody has a mailbox there yet.
The alias ceiling is low. Twenty aliases is generous for one business and nothing at all for an agency or a holding company that collects domain names. Count the names before you promise the structure.
Policy does not split by domain. You cannot apply different settings to different domains directly. If the second brand needs its own sharing rules or its own 2-Step Verification enforcement, the structure that carries that is organizational units: put each domain's users in their own unit and set policy there. The same applies to who administers what.
Inherited DNS lies to you. A domain bought second hand, or one that has been parked at a host which helpfully published an SPF record on your behalf, fails authentication in ways that look like Workspace misbehaving. Read the zone and remove the records you did not put there before the first message goes out.
How Guanacos Tech helps
We treat a second domain as a short project with the decision at the front: alias or secondary, chosen against what the business intends to do with the name, not against what is fastest to click. Then the new domain's DNS in order, MX, SPF, DKIM and DMARC, with reports going somewhere a person reads them, and the existing senders found before they start failing. If you are weighing a second name and would rather make the choice once, that is the work we do as Google Workspace consultants. A 30 minute call is enough to say which of the two your case needs and what has to change in DNS.
Sources
- Google Workspace Admin Help: Add a user alias domain or secondary domain
- Google Workspace Admin Help: FAQ for multiple domains
- Google Workspace Admin Help: Limitations with multiple domains
- Google Workspace Admin Help: Set up MX records for Google Workspace
- Google Workspace Admin Help: Set up SPF
- Google Workspace Admin Help: Set up DKIM
- Google Workspace Admin Help: Set up DMARC