Google Workspace Custom Gmail URLs Are Broken: HTTPS Doesn't Work and Google Doesn't Care

There's a particular kind of bug that's worse than a crash or an error message. It's the kind where everything looks correct — the documentation says you've done it right, the admin console confirms your settings — and yet the feature simply doesn't work. No warning. No deprecation notice. Just silence, and hours of your life you'll never get back.

This is the story of Google Workspace's custom Gmail URL feature, a capability that Google still actively advertises and lets you configure, but which has been quietly broken for HTTPS — the protocol that every modern browser now demands.

The Promise

Google Workspace (formerly G Suite, formerly Google Apps for Your Domain — Google loves renaming things) offers a compelling feature for organizations that want a professional, branded experience: custom URLs for core services.

Buried in the Google Admin Console under Apps > Google Workspace > Gmail > Setup, there's an option called "Web address." It lets you configure a custom URL for your team's email. Instead of directing people to gmail.com or mail.google.com, you can set up something like:

1mail.yourcompany.com

The setup looks straightforward. Google's documentation tells you to:

1. Go to your DNS provider
2. Create a CNAME record pointing mail.yourcompany.com to ghs.googlehosted.com
3. Wait for DNS propagation
4. Select the custom URL in the Admin Console

The expectation is simple: your team types a branded URL, they get Google's Gmail interface. Professional. Clean. On-brand. This is what you're paying for with your Workspace subscription.

The Setup: Doing Everything Right

Let's walk through a real-world example. You manage a domain — let's call it yourcompany.com — with DNS hosted on Cloudflare, one of the most popular DNS providers on the planet.

Step 1: Create the CNAME Record

In Cloudflare's DNS dashboard, you add:

1Type:    CNAME
2Name:    mail
3Target:  ghs.googlehosted.com
4TTL:     Auto
5Proxy:   Proxied (orange cloud)

Step 2: Configure Google Admin Console

In the Google Workspace Admin Console, you navigate to Gmail settings and select the custom URL option. Google confirms the CNAME is detected. Everything looks green. Configuration saved.

Step 3: Verify DNS

You run a quick check to make sure DNS is resolving correctly:

1$ dig mail.yourcompany.com CNAME +short
2ghs.googlehosted.com.
3
4$ dig ghs.googlehosted.com A +short
5216.239.32.21
6216.239.34.21
7216.239.36.21
8216.239.38.21

Perfect. The CNAME is pointing to Google's hosting infrastructure. Four Google IPs are resolving. DNS propagation is complete.

Step 4: Visit the URL

You type https://mail.yourcompany.com into your browser and...

SSL handshake fails.

Down the Debugging Rabbit Hole

What follows is a journey that every affected admin has taken, wasting anywhere from two to eight hours before arriving at the same grim conclusion.

Level 1: The Cloudflare Red Herring

Because Cloudflare is proxying the domain, the first thing you see is Cloudflare Error 525: SSL Handshake Failed. This is Cloudflare's way of saying: "I tried to establish an HTTPS connection to the origin server, but the TLS handshake failed."

Your instinct is to blame Cloudflare. After all, Cloudflare is the intermediary, and the error page has Cloudflare's branding. So you start troubleshooting the Cloudflare layer:

• SSL/TLS mode: Try "Full," then "Full (Strict)," then "Flexible." None work.
• Edge certificates: Verified. Cloudflare has a valid certificate for *.yourcompany.com.
• Origin server cipher suites: You can't configure these — it's Google's server, not yours.
• Minimum TLS version: Tried lowering to TLS 1.0. No change.

Nothing works. An hour gone.

Level 2: Bypass Cloudflare

You decide to take Cloudflare out of the equation entirely. Set the DNS record to "DNS only" (grey cloud) — no proxy, no Cloudflare edge, just a plain CNAME.

Now you get a different error: ERR_CONNECTION_CLOSED or ERR_SSL_PROTOCOL_ERROR depending on the browser.

This is the "aha" moment that should have come sooner: the problem isn't Cloudflare at all. It's Google.

Level 3: The Proof

To confirm, you test the connection directly:

1$ curl -v https://mail.yourcompany.com
2* Trying 216.239.32.21:443...
3* Connected to mail.yourcompany.com (216.239.32.21) port 443
4* SSL: no alternative certificate subject name matches target host name 'mail.yourcompany.com'
5* Closing connection
6curl: (60) SSL: no alternative certificate subject name matches target host name 'mail.yourcompany.com'

There it is. Google's server at ghs.googlehosted.com is presenting an SSL certificate, but that certificate doesn't include mail.yourcompany.com as a Subject Alternative Name (SAN). The certificate belongs to Google's own domains, not yours.

Let's look at what certificate Google is actually serving:

1$ openssl s_client -connect ghs.googlehosted.com:443 -servername mail.yourcompany.com 2>/dev/null | openssl x509 -noout -text | grep -A1 "Subject Alternative Name"
2  X509v3 Subject Alternative Name:
3    DNS:*.google.com, DNS:*.appengine.google.com, DNS:*.googlehosted.com, ...

The certificate covers *.googlehosted.com and various *.google.com subdomains. Your custom domain? Nowhere to be found. Google simply never provisioned a certificate for it.

Level 4: HTTP Works Fine

And here's the final twist. If you try http://mail.yourcompany.com (plain HTTP, no TLS), it works perfectly. Google's server accepts the connection, reads the Host header, and redirects you to https://mail.google.com/a/yourcompany.com. The CNAME is correct. The Google configuration is correct. Everything is working — except for the one thing that matters in 2026: HTTPS.

Why This Is a Bigger Deal Than It Sounds

You might think: "So just use HTTP. Problem solved." But that ship sailed years ago. The modern web has made plain HTTP essentially non-functional for end users:

• HSTS preloading: Many domains are on HSTS preload lists, meaning browsers will refuse to make HTTP connections at all — they automatically upgrade to HTTPS.
• Browser defaults: Chrome, Firefox, and Safari all default to HTTPS when you type a URL without a protocol. A user typing "mail.yourcompany.com" into the address bar will get the HTTPS version — and an error.
• Security warnings: Even if the browser does load the HTTP version, it will display prominent "Not Secure" warnings in the address bar. For a business email URL, this looks terrible.
• Corporate policies: Many organizations enforce HTTPS-only browsing through group policies, proxy servers, or network firewalls. HTTP connections are blocked entirely.

The practical result: if you follow Google's documentation to set up a custom Gmail URL, it won't work for the vast majority of users. They'll see an error page instead of their email.

Google's Silence

What makes this particularly frustrating is the complete absence of communication from Google:

• The documentation still instructs admins to set up custom URLs with no mention of HTTPS limitations.
• The Admin Console still lets you configure the feature with no warnings or caveats.
• There is no deprecation notice — the feature appears fully supported.
• Google Workspace support typically responds with generic SSL troubleshooting steps that don't address the actual issue.

The only evidence that this is a known problem comes from community forums, Stack Overflow threads, and Reddit posts — all with the same pattern: an admin sets up the CNAME, everything looks correct, HTTPS doesn't work, and eventually someone in the comments explains that Google just doesn't provision SSL certificates for custom Workspace URLs anymore.

The Workaround: Cloudflare to the Rescue (Ironically)

Remember Cloudflare, the service whose error page sent us down the wrong path? Ironically, it's also the solution.

The workaround is to use Cloudflare (or any reverse proxy/edge service) not as a pass-through to Google, but as a redirect layer:

Option A: Cloudflare Page Rules / Redirect Rules

1. Keep the CNAME record mail.yourcompany.com → ghs.googlehosted.com with Cloudflare proxy enabled (orange cloud)
2. Set Cloudflare SSL mode to "Flexible" (Cloudflare terminates SSL but doesn't need to verify the origin)
3. Create a redirect rule:

1# Cloudflare Redirect Rule
2# When: hostname equals "mail.yourcompany.com"
3# Then: Dynamic redirect to
4#   https://mail.google.com/a/yourcompany.com
5# Status code: 301 (permanent)

Option B: Cloudflare Worker

For more control, you can use a Cloudflare Worker:

1export default {
2  async fetch(request) {
3    const url = new URL(request.url);
4
5    if (url.hostname === 'mail.yourcompany.com') {
6      return Response.redirect(
7        'https://mail.google.com/a/yourcompany.com',
8        301
9      );
10    }
11
12    return fetch(request);
13  }
14};

Option C: Nginx Reverse Proxy

If you're running your own infrastructure:

1server {
2    listen 443 ssl;
3    server_name mail.yourcompany.com;
4
5    ssl_certificate     /etc/ssl/yourcompany/fullchain.pem;
6    ssl_certificate_key /etc/ssl/yourcompany/privkey.pem;
7
8    return 301 https://mail.google.com/a/yourcompany.com;
9}

What Each Option Does

All three approaches do the same thing:

1. Cloudflare (or your proxy) provisions its own SSL certificate for mail.yourcompany.com — solving the HTTPS problem.
2. The user visits https://mail.yourcompany.com and gets a valid HTTPS response — a 301 redirect.
3. The redirect sends them to https://mail.google.com/a/yourcompany.com — Google's native multi-tenant Gmail URL, which works perfectly.

It's not a true custom URL — the user ends up at a Google domain after the redirect. But it's functional, secure, and the best you can do with Google's broken infrastructure.

It's Not Just Gmail

The same problem affects all Google Workspace custom URL configurations:

1Service       Custom URL                    CNAME Target
2─────────     ────────────────────────────  ─────────────────────
3Gmail         mail.yourcompany.com          ghs.googlehosted.com
4Calendar      calendar.yourcompany.com      ghs.googlehosted.com
5Drive         drive.yourcompany.com         ghs.googlehosted.com
6Sites         sites.yourcompany.com         ghs.googlehosted.com

All of them point to ghs.googlehosted.com. None of them get SSL certificates provisioned. The entire custom URL feature for Workspace is broken for HTTPS.

If you want branded URLs for all services, you'll need to set up redirects for each one:

1# Redirect destinations for Google Workspace services
2mail.yourcompany.com      →  https://mail.google.com/a/yourcompany.com
3calendar.yourcompany.com  →  https://calendar.google.com/a/yourcompany.com
4drive.yourcompany.com     →  https://drive.google.com/a/yourcompany.com
5sites.yourcompany.com     →  https://sites.google.com/a/yourcompany.com

The Larger Pattern: Google's Quiet Feature Graveyard

This isn't an isolated incident. Google has a well-documented pattern of abandoning features without formal deprecation:

• Google Domains — sold to Squarespace in 2023 with minimal notice
• Google Cloud Print — shut down in 2020 after years of stagnation
• Google Hangouts → Google Chat/Meet — years-long confused migration
• Google Business Profiles website builder — shut down in March 2024
• Dynamic DNS support in Google Domains — worked, then didn't, with no announcement

The custom URL feature fits this pattern perfectly. It was likely built in the early days of Google Apps when HTTP was still acceptable. As the web moved to HTTPS-everywhere, the feature wasn't updated. Google didn't deprecate it — that would require acknowledgment. Instead, it just... sits there. Configured. Broken. Silent.

What Google Should Do

The fix is not complicated. Google has several clear options:

Option 1: Provision SSL Certificates (The Right Fix)

Google already has one of the world's most sophisticated certificate infrastructure. They operate their own Certificate Authority (Google Trust Services). Let's Encrypt-style automated certificate provisioning is a solved problem. When an admin configures a custom URL and the CNAME points to ghs.googlehosted.com, Google should automatically provision a certificate for that subdomain. This is exactly what every modern hosting platform does — GitHub Pages, Netlify, Vercel, Cloudflare Pages — all of them handle SSL for custom domains automatically.

Option 2: Deprecate the Feature (The Honest Fix)

If Google doesn't want to maintain custom URL support, they should formally deprecate it. Remove the option from the Admin Console. Update the documentation. Send a notification to affected admins. This is the bare minimum of responsible feature management.

Option 3: Add a Warning (The Minimum Fix)

At the very least, the Admin Console should display a warning when an admin configures a custom URL:

Even this tiny change would save thousands of admin-hours globally.

The Complete Setup Guide (What the Docs Should Say)

Since Google won't document this, here's the complete setup for a working branded Gmail URL using Cloudflare:

Prerequisites

• A domain managed in Cloudflare (free plan works)
• A Google Workspace subscription
• Admin access to both Cloudflare and Google Admin Console

Step 1: DNS Record

1Type:    CNAME
2Name:    mail
3Target:  ghs.googlehosted.com
4Proxy:   Proxied (orange cloud) ← IMPORTANT
5TTL:     Auto

Step 2: SSL/TLS Settings

In Cloudflare dashboard → SSL/TLS → Overview, set the encryption mode to Flexible for this specific hostname, or create a Configuration Rule that sets SSL mode to Flexible for mail.yourcompany.com only (recommended to avoid affecting your other subdomains).

Step 3: Create Redirect Rule

In Cloudflare dashboard → Rules → Redirect Rules, create a new rule:

1Rule name:     Gmail Custom URL Redirect
2When:          Hostname equals "mail.yourcompany.com"
3Then:          URL redirect
4  Type:        Dynamic
5  Expression:  concat("https://mail.google.com/a/yourcompany.com", http.request.uri.path)
6  Status code: 301

Step 4: Test

1$ curl -I https://mail.yourcompany.com
2HTTP/2 301
3location: https://mail.google.com/a/yourcompany.com
4server: cloudflare
5
6# Success! HTTPS works, redirect is functional.

Users now get a seamless experience: they type the branded URL, get a valid HTTPS response, and arrive at their Gmail inbox.

The Lesson for IT Admins

If there's one takeaway from this ordeal, it's this: don't trust a feature just because the vendor's UI lets you configure it. Google's Admin Console will happily let you set up custom URLs that don't work. The configuration will succeed. The DNS will verify. And the feature will be broken.

Before rolling out any feature to your organization:

1. Test the actual user experience — don't just verify the configuration succeeded in the admin panel. Open a browser and try the full flow.
2. Check community forums — if a feature is broken, other admins have probably documented it, even if the vendor hasn't.
3. Have a fallback plan — in this case, the redirect workaround is simple and takes 10 minutes. But it took hours to figure out that you needed it.
4. File feedback — Google may not respond, but volume matters. If you're affected, file feedback through the Admin Console (Admin Console → Send feedback). The more reports, the higher the chance someone at Google notices.

And to Google: you charge organizations for Workspace. These organizations trust you to maintain the features you advertise. Either fix custom URL SSL provisioning, or take the feature down. The current state — functional in the UI, broken in reality, silent about both — is the worst possible outcome.

Your admins deserve better than a feature that works on HTTP in an HTTPS world.