Google Domains Synthetic Records and What Replaced Them

If you have arrived here looking for the Synthetic Records section in your Google Domains dashboard, there is something you should know first.

Google Domains no longer exists. Google sold its registrar business to Squarespace, domains were migrated, and the synthetic records feature went with it.

A surprising number of articles still describe this feature in the present tense, complete with instructions for a dashboard nobody can open. This guide explains what synthetic records were, what happened to them, and what you should use instead.

The Short Answer

Synthetic records were a Google Domains convenience feature that bundled multiple DNS records into a single setting. They no longer exist.

Google announced the retirement of these features in October 2023, with a shutdown date of 22 January 2024. Domains moved to Squarespace Domains, and the feature set changed.

If you had synthetic records configured before the migration, some of that configuration persisted in a frozen state. You could not change it.

What Synthetic Records Actually Were

Here is the part worth understanding, because the concept still matters.

A synthetic record was never a real DNS record type. It was not part of any internet standard. It was a Google-specific abstraction layer sitting on top of ordinary DNS.

You picked a goal in plain language, such as forwarding a subdomain or connecting Google Workspace, and Google generated and managed the correct combination of underlying A, CNAME, and MX records for you.

The value was never technical. DNS itself did not change. What changed was accessibility. Before this feature, setting up business email or a subdomain redirect meant understanding record types, priority values, TTL settings, and the specific requirements of whatever service you were connecting to. Synthetic records hid all of that.

That is why the feature was so popular with freelancers, small business owners, and bloggers, and why its removal caused genuine disruption.

The Three Types

Subdomain forwarding was by far the most used. It let you point blog.yourdomain.com at an external service, or redirect a root domain to a specific page, in one step, with HTTPS handled for you in many cases.

Some documentation and third-party guides also described email forwarding as a synthetic record, since it worked the same way from the user’s perspective.

How They Worked Under the Hood

When you created a forwarding synthetic record, Google Domains generated the necessary A and CNAME records pointing at Google’s own forwarding servers. Those servers performed the actual redirect and, in many cases, provisioned a free SSL certificate so the forwarded domain worked over HTTPS.

The configuration options exposed to users were minimal but meaningful:

• Temporary (302) or permanent (301) redirect. Permanent tells browsers and search engines the move is final and passes ranking signals. Temporary is safer while you are still deciding.
• Forward path or do not forward path. Path forwarding sends /about on the old domain to /about on the new one, which matters enormously for SEO during a migration.

Those two settings are the ones people most often get wrong when recreating this behaviour elsewhere.

What Happened, and When

Google’s rationale was straightforward. Domain registration is a low-margin commodity business outside its core focus. For Squarespace, a website builder, owning a registrar creates a vertically integrated product.

What Survived and What Did Not

The distinction matters if you still hold a migrated domain.

Preserved but frozen. Existing domain forwarding and email forwarding configurations continued working according to their last supported settings. You could not change them.

Lost entirely. Dynamic DNS stopped functioning. Active DDNS records remained as A or AAAA records pointing at whatever IP address was last recorded before migration, and stopped updating. Any DDNS client left running received errors. Squarespace does not offer a DDNS service.

Carried over. Standard DNS settings, nameservers, email routing, and WHOIS information all transferred. Renewal dates stayed the same.

That DDNS loss is the one that genuinely broke things. A home server pointed at a stale IP address simply stops being reachable the next time the ISP reassigns it.

Replacing Each Synthetic Record Type Today

Squarespace does offer URL forwarding for domains registered through it, including former Google Domains assets. The feature set differs from Google’s, and some users have reported inconsistency in HTTPS behaviour and configuration options.

Cloudflare Registrar is the common destination for people leaving. It sells domains at cost, roughly $9.15 per year for a .com as of 2026, with free WHOIS privacy and DNSSEC included. Redirect Rules handle forwarding, and the API supports DDNS through third-party clients.

The trade-offs are real: Cloudflare does not support every TLD, and its support is less hands-on than Namecheap or GoDaddy.

How to Recreate Subdomain Forwarding Manually

If your registrar has no forwarding feature, the underlying mechanics are not complicated.

1. Decide the redirect type. Use 301 for a permanent move, since it passes ranking signals. Use 302 only while testing.
2. Decide on path forwarding. For a site migration, forward the path so /pricing lands on /pricing. For pointing a domain at a single landing page, do not.
3. Point the record. Create a CNAME for the subdomain, or an A record for the root, aimed at whatever service will perform the redirect.
4. Configure the redirect at that service, whether that is Cloudflare Redirect Rules, a hosting provider’s redirect settings, or a small server rule.
5. Verify HTTPS. This is where DIY forwarding most often fails. Confirm the certificate covers the forwarding hostname.
6. Test with a redirect checker. You want one hop, correct status code, and a live 200 destination.

Before You Transfer Anything

One piece of advice that applies to any registrar move, learned repeatedly during this migration.

Export or screenshot your existing DNS records before you transfer. Records frequently do not survive a transfer cleanly, and reconstructing them from memory while a site is down is a bad afternoon.

Also check what you depend on before choosing a destination. If you run DDNS, verify the new registrar supports it. If you rely on email forwarding, confirm it exists. Squarespace’s lack of DDNS was announced in migration emails, but plenty of people found out when their home server went dark.

If You Are Still Affected

Check three things today:

Does your domain still resolve correctly? Frozen forwarding configurations work until something changes upstream.

Is anything pointing at a stale IP? Former DDNS records are the most likely culprit.

Can you actually edit your DNS? If your domain still uses retired Google Domains DNS, the last settings continue working but you cannot change records until you move to a different DNS provider.

If any of those raise a flag, moving to a registrar with an active DNS product is the fix, not a workaround.

The Takeaway

Synthetic records were a genuinely good idea: hide DNS complexity behind plain-language goals. Their disappearance is a reminder that convenience features tied to one provider are borrowed, not owned.

The underlying DNS knowledge, on the other hand, transfers everywhere. Learning what a CNAME actually does takes an afternoon and outlasts every dashboard that promised you would never need to know.

FAQs