Check SendGrid branded links for HTTPS before Gmail warns

The onboarding email goes out, the customer opens it, and the reset link lands in a warning box instead of the app. That is the failure mode a small team can fix before it becomes a support ticket.

The warning turns a missing certificate into lost clicks

Gmail will start flagging links without HTTPS by late October 2026. For a company whose onboarding, password reset, and billing emails rely on a SendGrid branded tracking domain, that warning sits directly in the path of the click. Tracking links that lack SSL are expected to suffer lower click-through because of Gmail's non-HTTPS warnings. The links still work, but the inbox treats them with less trust.

The fix is a single-owner DNS checklist

The platform side is small, but the company side is a document. Someone owns the domain, someone owns the onboarding flow, and the note they leave should be short enough to read in a meeting. Put the checklist in the same place you keep the domain inventory, the email provider login, and the onboarding runbook. Each step should be testable in a minute, and the last step should leave a date in the log.

• Check the branded link domain in a browser and confirm it serves HTTPS. If it does, record a no-op and stop.
• If it does not, name one owner and set a date for the DNS change.
• SendGrid's Link Branding API added an auto_ssl parameter for use when creating a branded link. Set it to true.
• When auto_ssl is set to true, SendGrid provisions the certificate and supplies the extra DNS records needed to complete setup.
• Turning on automatic SSL needs two more SendGrid DNS records, on top of existing CNAME entries for link branding. Add those records.
• Verify the domain resolves and the certificate is active before you send another onboarding email.
• Log the shipped date in the operations note so the next person can see the fix was done.

The domain check keeps a solved problem from becoming a stale task, and the owner keeps the DNS change from becoming a nameless note. The certificate and record steps keep the SSL setup separate from link branding, and the log keeps a future reset from requiring archaeology.

The decision stays out of the support queue

When the owner is named, the next step is a short meeting with the person who controls the domain records and the person who owns the onboarding flow. The agenda should fit on a single page: the domain, the current state, the owner, the date, and the verification step. The meeting ends with a no-op note when the domain already serves HTTPS, and with a task and a date when it does not.

The document should record the decision, not explain the platform. A few lines are enough: the branded domain, whether it serves secure links, the owner, the date the records were added, and the date the link was verified. If the company later changes email providers, that note is the only thing the next team needs to find.

If the domain record access is controlled by another team, the owner should write the request as a decision, not a favor. The request names the domain, the reason, the records, and the date the onboarding flow needs it. That makes the work easier to schedule, easier to audit, and easier to hand off when the person who started it leaves.

The onboarding warning becomes a non-event

Before the next onboarding batch, send a test email to an internal account and open it in the inbox that matters. The test should be a click, not a guess. If the reset link opens the app without a warning, the domain is doing its job. If it does not, the owner should not wait for a customer to find the problem. Keep the test result and the owner in the operations note next to the shipped date. The same test can be run after any change to the branded domain, the link template, or the onboarding flow.