Advanced: Google Cloud Setup for Link Branding SSL

This advanced configuration is for customers using Google Cloud to terminate SSL for their branded link domain.

This guide walks through configuring SendGrid link branding with SSL when the customer manages their branded link domain on Google Cloud Platform. It is a companion to the main link branding setup documentation and specifically covers the proxy and SSL termination steps.

On Google Cloud, a Global External Application Load Balancer with Cloud CDN is used to terminate SSL for the branded link domain and forward traffic to sendgrid.net. This replaces the Cloudflare or other CDN setup referenced in the main link branding documentation.

For the main link branding flow (steps 1 and 2 in the SendGrid UI, DNS records, and SSL verification), see the main Link Branding Setup page. This document covers the customer-side infrastructure step only.

Prerequisites

• A Google Cloud Platform project with billing enabled

• A registered domain with access to DNS management

• The gcloud CLI installed and authenticated, or access to the Google Cloud Console

• The branded link domain and CNAME records already generated in the InOne panel during step 2 of the link branding setup

• Familiarity with DNS, SSL certificates, and load balancing concepts, or a DevOps engineer who is

Part 1: Complete link branding setup in the InOne panel

Before configuring Google Cloud, complete steps 1 and 2 of the link branding setup in the InOne panel. This generates the CNAME records you will need in Part 3.

1. In the InOne panel, open the branded link management screen and select Use Custom Branded Link.

2. Add your branded domain. E.g., links.yourdomain.com. A custom subdomain is optional. If you do not provide one, SendGrid will assign one.

3. Complete the DNS records step. The panel will display two CNAME records.

Example CNAME records generated during this step:

Do not click the Check SSL button in the InOne panel yet. You will verify after completing the Google Cloud setup and DNS configuration. Revalidating more than once causes authentication to stop working.

Part 2: Configure the Google Cloud infrastructure

This section walks through setting up a Global External Application Load Balancer that terminates SSL for the branded link domain and forwards requests to sendgrid.net.

Step 2.1: Reserve a global static IP address

Reserve a global external IP address for the load balancer. You will point the branded link domain to this IP in Part 3.

gcloud compute addresses create sendgrid-link-ip --global --ip-version=IPV4

Retrieve the allocated IP address:

gcloud compute addresses describe sendgrid-link-ip --global --format="value(address)"

Note this IP. It is needed for the A record in Part 3.

Step 2.2: Create an Internet NEG and a backend service

An Internet Network Endpoint Group points to sendgrid.net so the load balancer can forward traffic to it. Create the NEG first:

gcloud compute network-endpoint-groups create sendgrid-neg \
  --network-endpoint-type=internet-fqdn-port \
  --global
 
gcloud compute network-endpoint-groups update sendgrid-neg \
  --global \
  --add-endpoint="fqdn=sendgrid.net,port=443"

Create the backend service and attach the NEG:

gcloud compute backend-services create sendgrid-backend \
  --global \
  --protocol=HTTPS \
  --port-name=https \
  --enable-cdn
 
gcloud compute backend-services add-backend sendgrid-backend \
  --global \
  --network-endpoint-group=sendgrid-neg \
  --global-network-endpoint-group

Step 2.3: Provision a Google-managed SSL certificate

Create a Google-managed SSL certificate for the branded link domain. Google will provision and renew the certificate once DNS points to the load balancer.

gcloud compute ssl-certificates create sendgrid-link-cert \

  --domains=links.yourdomain.com \

  --global

The certificate will stay in PROVISIONING status until DNS points to the load balancer IP. This is expected and resolves once DNS is updated in Part 3.

Step 2.4: Create the URL map and HTTPS target proxy

Create a URL map that routes all traffic to the SendGrid backend, and a target HTTPS proxy that uses the SSL certificate:

gcloud compute url-maps create sendgrid-link-map \
  --default-service=sendgrid-backend \
  --global
 
gcloud compute target-https-proxies create sendgrid-link-proxy \
  --ssl-certificates=sendgrid-link-cert \
  --url-map=sendgrid-link-map \
  --global

Step 2.5: Create the forwarding rule

Bind the reserved IP address to the HTTPS proxy on port 443.

gcloud compute forwarding-rules create sendgrid-link-rule \
  --global \
  --address=sendgrid-link-ip \
  --target-https-proxy=sendgrid-link-proxy \
  --ports=443

Step 2.6: Optional HTTP to HTTPS redirect

Google-managed certificates use HTTP-01 validation on port 80. Configuring this redirect also satisfies that requirement:

gcloud compute url-maps import sendgrid-http-redirect \
  --global \
  --source /dev/stdin <<EOF
name: sendgrid-http-redirect
defaultUrlRedirect:
  httpsRedirect: true
  redirectResponseCode: MOVED_PERMANENTLY_DEFAULT
EOF
 
gcloud compute target-http-proxies create sendgrid-http-proxy \
  --url-map=sendgrid-http-redirect \
  --global
 
gcloud compute forwarding-rules create sendgrid-http-rule \
  --global \
  --address=sendgrid-link-ip \
  --target-http-proxy=sendgrid-http-proxy \
  --ports=80

Part 3: Configure DNS records

Point the branded link domain to the load balancer and add the SendGrid CNAME records for verification.

Step 3.1: A record for the branded link domain

In your DNS provider (or Cloud DNS), create an A record pointing to the static IP reserved in step 2.1.

Step 3.2: SendGrid CNAME records

Add the two CNAME records generated by the InOne panel in Part 1. These are required for link branding verification.

Step 3.3: Wait for propagation

DNS propagation can take anywhere from a few minutes to 48 hours. Verify with:

dig links.yourdomain.com +short

The result should return the static IP you reserved.

Step 3.4: Verify SSL certificate provisioning

Check the status of the Google-managed certificate:

gcloud compute ssl-certificates describe sendgrid-link-cert --global --format="value(managed.status)"

Wait until the status changes from PROVISIONING to ACTIVE. This typically takes 15 to 60 minutes after DNS is correctly configured.

Part 4: Verify the setup

1. Return to the link branding screen in the InOne panel and click Check SSL for your branded domain.

2. If DNS has propagated and the certificate is active, verification will succeed. If it fails, wait longer for propagation and retry, but do not revalidate DNS records in the panel multiple times.

3. Send a test email from your Insider One account to confirm that tracking links use the branded domain and display a valid SSL certificate.

Final step: enable SSL click tracking

After verification, contact your Insider One CSM or the deliverability team to request SSL click tracking to be enabled on the SendGrid account. This step is handled by Insider and is required for HTTPS links to function correctly.

Reference: Cloudflare to Google Cloud component mapping

If you are comparing this setup against the Cloudflare instructions in SendGrid's documentation, this table maps each component.

Troubleshooting

SSL certificate stuck in PROVISIONING

• Confirm the DNS A record points to the correct static IP address.

• Ensure the forwarding rule on port 443 is active.

• Google-managed certificates use HTTP-01 validation. Confirm port 80 is also forwarded (step 2.6).

Verification fails in the InOne panel

• Confirm both CNAME records are added correctly to DNS.

• Wait for full propagation before retrying. Do not revalidate multiple times.

• Use dig or nslookup to verify CNAME resolution.

ERR_CERT_COMMON_NAME_INVALID in browser

• The SSL certificate domain must exactly match the branded link subdomain.

• Confirm the certificate status is ACTIVE, not PROVISIONING or FAILED_NOT_VISIBLE.

Links do not resolve over HTTPS

• Confirm with Insider that SSL click tracking has been enabled on the SendGrid account.

• Verify the HTTP to HTTPS redirect is functioning (step 2.6).

External Network endpoint option appears disabled in the load balancer UI

This usually means the Console UI is filtering by the wrong load balancer type. The Internet NEG must be attached to a Global External Application Load Balancer, not a regional or internal one. Using the gcloud commands above avoids the UI filtering issue entirely.

References

• Link Branding Setup

• SendGrid: Enabling SSL for click and open tracking

• SendGrid: Custom SSL configurations

• Google Cloud: Setting up a Global External Application Load Balancer

• Google Cloud: Using Google-managed SSL certificates

• Google Cloud: Internet NEG overview