Why are my SendGrid links broken and how do I fix it?
Updated on 24 Oct 2026: We added SendGrid Auto SSL setup and corrected the steps for repairing tracking links in new and previously delivered emails.
Broken SendGrid links often involve click tracking, which rewrites the original links into tracking URLs on a subdomain such as url1234.example.com. The tracking host can fail because of DNS, an SSL certificate error, proxy routing, or URL reputation blocking. The failure often appears as a URL containing /ls/click, a /ss shortened tracking path, a 404 page, a browser privacy warning, a dangerous-link warning, a 525 SSL handshake error, or an HTTPS timeout. If the path starts with /ss, SendGrid Link Shortening is enabled, but the same tracking hostname and redirect checks still apply. If the original destination opens directly, disable click tracking, send a new test email, and confirm that its links keep the original URLs.
If you need click metrics, repair the branded link setup before restoring tracking. Check the tracking subdomain, its assigned CNAME target, HTTPS, and the account or per-message setting that controls rewriting. For a manually managed proxy or CDN, also check the forwarded Host header. DMARC does not rewrite links. DMARC, SPF, and DKIM check email authentication.
If the message was sent through Zapier, a CMS, an app backend, SMTP, or API, still start with the delivered message. Those tools can pass correct HTML to SendGrid, then SendGrid rewrites the link after handoff, which is why a hardcoded URL can become a long, jumbled /ls/click URL in the inbox.
If the same tracked URL fails only on one device, one mailbox, one company domain, or one network, test it somewhere else before changing DNS. Corporate security tools can wrap or block tracking URLs, and device privacy settings can affect access even when the SendGrid tracking hostname works.
When broken links in a SendGrid email contain /ls/click or /ss, check click tracking first. A single bad link also calls for a template check. Rewritten links confirm that the sending path has tracking enabled.
- Fast check: Copy the link from the received email, not the editor preview.
- Pattern: Look for a host like url1234 plus /ls/click or /ss.
- Meaning: SendGrid rewrote the link; test the tracking host and the destination to locate the failure.
- Scope: If only one user reports the issue, test the same link on another device, browser, and network.
- Reputation: If the warning says dangerous or suspicious, capture the full redirect chain before changing DNS.
Why SendGrid changes links
SendGrid click tracking replaces destination URLs in HTML href attributes with tracking URLs; the visible link text can stay unchanged. The tracking URL records the click, then redirects the visitor to the original destination. The rewrite also applies to plain text URLs when plain text click tracking is enabled. SendGrid's SSL tracking setup explains that click tracking rewrites links and that branded link tracking uses your own domain instead of SendGrid's default domain.
That rewrite is normal when click tracking is intentional. It becomes a problem when the branded tracking host has no DNS record, points to the wrong target, lacks a valid certificate, or sends the request to a proxy that does not preserve the host expected by SendGrid. Security products also score the tracking host and redirect path, not just the final page, which is why a clean website can still sit behind a blocked tracking URL. If a recipient security system later wraps the SendGrid URL again, the recipient can see two layers of rewriting before the browser reaches the final page.
Original link versus SendGrid tracking linktext
Original link: https://www.example.com/account Rewritten with SendGrid HTTPS click tracking enabled: https://url1234.example.com/ls/click?upn=...
Flowchart of a SendGrid click tracking link through DNS, redirect handling, and the landing page.
The ls/click path is a useful clue because it tells you the link is going through SendGrid's link tracking layer. A /ss path means SendGrid Link Shortening is on, not that tracking is off. If the hostname itself fails, the browser never reaches the redirect step. If the hostname works over HTTP but fails over HTTPS, the problem is certificate or SSL tracking setup. If plain text links are also rewritten, check whether SendGrid's plain text click tracking option or API tracking settings are enabled for that send. If both HTML and plain text tests break in the same way, check account-level tracking and API-level tracking settings before editing the template. If the redirect works for some destinations but not others, inspect the final URL, redirect chain, and query parameters.
Disable SendGrid click tracking
The fastest fix is to disable SendGrid click tracking for the sending path that is breaking links. This stops SendGrid from rewriting the href values, so recipients receive the original links. Use this as the first recovery step when broken links affect active customer journeys, password resets, invoices, account pages, or payment update pages.
After the urgent issue is stable, decide whether click tracking is needed. If it is not needed, keep it off. If reporting depends on click data, rebuild the branded link setup and test the full redirect path before turning it back on for production mail.
- Confirm the pattern: Open a delivered email and copy a broken link. Look for /ls/click or /ss.
- Disable tracking: Go to Settings > Tracking > Click Tracking, disable it, and save. For API sends, also inspect the outgoing message configuration.
- Send a fresh test: Turning tracking off affects new sends; it does not remove tracking URLs from old messages.
- Use the same path: If the email normally comes through Zapier, a workflow tool, or your app, test that same route.
- Inspect the source: Check the received HTML and verify the href is the original URL.
- Restore carefully: Only re-enable tracking after the tracking host, DNS, SSL, and redirects pass testing.
For the Mail Send API, set both click tracking flags to false in the outgoing request. Check the final request produced by your integration, rather than relying only on the account toggle.
Mail Send API request fragment to disable click trackingjson
{ "tracking_settings": { "click_tracking": { "enable": false, "enable_text": false } } }
For one critical link, bypass tracking at the anchor level instead of disabling click tracking for the whole send. In the HTML, place clicktracking=off before the href, then send a new test and confirm that specific URL stays direct.
Disable tracking for one HTML linkhtml
<a clicktracking=off href="https://www.example.com/account">Open your account</a>
Turning off tracking bypasses the broken redirect layer for newly sent emails. To restore links in emails already delivered, repair the original tracking hostname and its SSL or proxy configuration, then test an older tracked URL.
For a realistic confirmation, send the same template through the same website or SMTP integration and inspect the delivered message with the email tester. The important part is testing the real send path, not a preview inside SendGrid or your CMS.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A passing test should show the original href values when tracking is off, or a tracking URL that resolves cleanly when tracking is on. If the message authenticates but links still break, keep the troubleshooting focused on link branding, SSL, proxies, redirects, and template output.
Fix SendGrid link branding
If the team needs click reporting, fix SendGrid link branding before restoring tracking. The exact CNAME values belong to the SendGrid account setup, so do not guess them. Get the required hostnames and targets from Settings > Sender Authentication > Link Branding in the sending account or subuser.
Check both the account-level setting and the setting used by the actual sending path. Marketing Campaigns, transactional API sends, SMTP mail, and subusers can apply different tracking configuration, so disabling one control does not prove that every future SendGrid email will stop rewriting links. Also compare the selected link branding with the From domain because a matching branding can take precedence over the entry marked as default.
Link shortening is separate from repairing a broken tracking link. SendGrid Link Shortening can reduce wrapped link length after SendGrid Support enables it on a parent account or subuser, and enabling it can automatically activate click tracking. Shortened links show /ss instead of /ls. It still depends on click tracking and the branded tracking hostname, and SendGrid's click data window drops to 60 days from link creation. After that, the link should still work but the click is not recorded.
The branded tracking subdomain must resolve through the DNS records assigned by SendGrid. Auto SSL manages the HTTPS certificate; manually managed SSL uses a prepared proxy or CDN. If the hostname does not resolve, the browser cannot reach the tracking service. For a manual proxy, forward the full path and query string and set the HTTP Host header to the branded tracking hostname. SendGrid's Wrong Link troubleshooting also recommends checking the upstream protocol, including an HTTP origin at http://sendgrid.net/ for the affected manual CDN setup.
Typical link branding DNS shapedns
# Standard link branding: use the exact target shown in SendGrid. url1234.example.com. CNAME assigned-target.sendgrid.net. # Manual SSL alternative: replace only the first CNAME target. # These are alternatives, not two records for the same hostname. url1234.example.com. CNAME proxy.example.com.
Some DNS hosts append your domain automatically. Check that the stored hostname is url1234.example.com, rather than url1234.example.com.example.com. SendGrid's DNS setup instructions explain this record-name error.
|
|
|
|---|---|---|
Host missing | No CNAME | Add the exact DNS target |
Connection not private | Certificate missing, expired, or issued for another hostname | Check Auto SSL status or renew the manually managed certificate |
525 or timeout | Proxy, CDN, or certificate path | Check the proxy's upstream TLS settings and routing |
Not found | Public shortener, redirect chain, or heavy UTM path | Use the final URL directly |
Dangerous warning | URL reputation or unsafe destination | Check host, final URL, and blocklist status |
Shortened link fails | Same host or SSL issue | Check DNS and HTTPS; redirects continue after the 60-day reporting window |
Wrong link | Proxy routing or failed branding revalidation | Check the forwarded Host header and restore validation if needed |
Only http | SSL not enabled | Complete Auto SSL or manual SSL setup |
Common SendGrid link failures and the practical fix
Disable click tracking
- Best for: Urgent customer-facing link failures.
- Benefit: Original links go out without a tracking redirect.
- Tradeoff: SendGrid click reporting stops for those emails.
Fix link branding
- Best for: Teams that need click metrics and branded domains.
- Benefit: Tracking works while links use your domain.
- Tradeoff: Allow time for DNS verification and certificate issuance.
SendGrid's Not Found guidance covers failures involving public shorteners, redirect chains, or heavy UTM use. Start with the tracking host because a missing host prevents the redirect from reaching any destination.
For manual SSL, prepare every link branding in the sending account before asking Support to enable HTTPS rewriting. Check subusers separately because the parent account's SSL setting does not enable theirs. These manual requirements differ from the per-branding Auto SSL setup described below. See SendGrid's SSL instructions.
Enable HTTPS tracking with Auto SSL
SendGrid can provision and renew certificates for branded tracking links through Auto SSL, without a separately managed CDN. Use the link branding setup to enable it for the intended tracking hostname.
- Open Settings > Sender Authentication > Link Branding and start the setup flow. In Advanced Settings, select Auto provision SSL Certificate, also described as "Make link Auto SSL" in the support instructions.
- Publish all generated DNS records, including the additional _acme-challenge CNAME and _cf-custom-hostname TXT record used for certificate issuance and ownership verification.
- Verify the records in SendGrid and wait for certificate issuance. DNS verification takes up to 48 hours; publishing records alone does not confirm that HTTPS is ready.
- Send through the actual account or subuser and open a complete tracking link. Confirm HTTPS, a certificate valid for that hostname, and a redirect to the intended destination.
For Link Branding API creations, set auto_ssl to true. The auto_ssl_available field reports certificate readiness. Auto SSL must be selected at creation rather than enabled later on the same entry. See SendGrid's Auto SSL announcement.
To convert an existing branding, save its original subdomain and DNS configuration, then follow SendGrid's migration steps to recreate it with Auto SSL and the same custom link subdomain. Schedule the migration because removing its DNS records interrupts previously delivered links. After the replacement records are live, test an older tracked URL as well as a fresh email.
Why the wrong link branding appears
A working SendGrid link can still use the wrong branded hostname. SendGrid's default link branding behavior gives a matching branding for the From domain priority over the entry marked as default. When several brandings match the same domain, SendGrid can select the oldest one. The default branding is used when no branding matches the sender's domain.
This explains incidents where DNS and SSL look healthy but the delivered email uses an unexpected tracking host. The setting marked default is not enough evidence. Audit the link brandings that belong to the account or subuser that performed the send.
- Match the sender: Record the exact From domain used by the delivered message.
- Inventory brandings: List every link branding on the sending account and relevant subuser.
- Check creation order: Identify the oldest branding that matches the sender's domain.
- Remove conflicts carefully: Document DNS and ownership, then delete only an unwanted branding that conflicts with the intended one.
- Retest each path: Send through the same account or subuser and confirm the hostname in the delivered href.
Before deleting a conflicting branding, confirm which sender domains, subusers, live mail streams, and previously delivered tracking links depend on it.
Safer SendGrid tracking setup
Once the links work again, treat the SendGrid tracking host as part of your email reputation, not disposable analytics plumbing. A branded tracking hostname should be HTTPS-only, tied to the sender's domain, and monitored like any other domain that appears in email.
Click tracking is normal when it records the click and sends the visitor to the expected page. Risky link cloaking starts when the tracking layer hides an unrelated destination, masks a public shortener, or depends on a redirect chain that the sender cannot explain.
- Use branded HTTPS: Do not leave customer-facing mail on plain HTTP tracking links. Finish SSL tracking before sending at volume.
- Confirm consent: Check the rules that apply to each recipient country before using click or open tracking, because some jurisdictions require clear consent.
- Avoid open redirects: Do not build links where untrusted input controls the final destination after SendGrid redirects the click.
- Keep destinations clean: Use the final URL directly where practical, and avoid public shorteners, deep redirect chains, and sensitive data in query strings.
- Shorten only after repair: Use SendGrid Link Shortening for raw URL length problems, not as a substitute for working DNS, HTTPS, host preservation, and redirects.
- Log enough context: Keep message IDs and redirect details for support, and share recipient-specific URLs only through private support channels.
- Monitor the host: Check the tracking subdomain for DNS, certificate, reputation, and blocklist (blacklist) issues when campaigns fail after click.
Suped's product fits this workflow when the SendGrid issue overlaps with authentication or reputation. Teams can track DMARC, SPF, DKIM, sender sources, and blocklist (blacklist) signals while the SendGrid owner fixes link branding.
Where DMARC fits
DMARC does not rewrite URLs, but it often appears in the same incident because teams change email authentication and sending platforms at the same time. A domain can pass DMARC and still have broken SendGrid tracking links. A domain can also have working links while SPF, DKIM, or DMARC is misconfigured. Treat these as two connected checks, not one root cause.
Use Suped's DMARC monitoring to confirm which services are sending mail for the domain, then check DNS health separately with a domain health checker. Authentication checks and tracking URL checks answer different questions, and both can affect delivery.
DMARC record detail view showing SPF, DKIM, DMARC, rDNS diagnostics, and DNS records
Suped's DMARC reporting and email authentication platform helps teams review SendGrid's SPF and DKIM results and investigate DMARC failures alongside the link repair. Use message headers and DMARC reports for authentication, then test tracking URLs directly for link errors.
A practical Suped workflow for this issue is to verify that SendGrid is authenticated, confirm that unrelated senders are not failing DMARC, and then keep the link-branding work focused on the SendGrid tracking hostname.
- Confirm sender: Check SendGrid's DMARC results for the domain in actual reports.
- Separate issues: Keep authentication failures apart from click redirect failures.
- Use alerts: Use authentication alerts to investigate sudden changes in SendGrid's results.
- Confirm results: Review SPF and DKIM results for the actual sending domain before treating SendGrid as authenticated.
This matters during handoffs with IT. If the request is simply "fix SendGrid links," the DNS owner lacks enough detail. A better request names the broken host, the expected CNAME target, whether SSL tracking is required, and the business impact if links remain broken.
Other causes to rule out
Click tracking is the first place to look when every SendGrid link becomes a tracking URL, but it is not the only reason email links fail. Check these causes after the tracking host and SSL path are understood.
If the browser or endpoint product labels the SendGrid tracking URL as dangerous, treat it as a URL reputation incident as well as a broken-link issue. Capture the full tracking URL, final URL, warning text, screenshot, browser, device, network, and timestamp. Then check the tracking host, destination, redirect chain, and any blocklist (blacklist) signals before asking for recategorization.
- Shorteners: Public link shorteners can trigger blocking, branded link errors, or 404s after SendGrid rewrites the URL. If length is the issue, use SendGrid Link Shortening after branded tracking works instead of stacking another redirect.
- Redirect chains: Long chains, HTTP-to-HTTPS hops, or heavy UTM parameters can fail before the final page loads.
- Security filters: Some filters wrap a SendGrid tracking URL inside a second security URL, then scan it at click time. That can expose fragile encoding, long redirect chains, expired tokens, a tracking domain with weak reputation, or a destination URL that has been classified as unsafe.
- Scanner clicks: If the link works in manual testing but SendGrid reports sudden clicks, pull event data before changing DNS. For one-time links, check whether a security scan consumed the token before the recipient opened it.
- Device privacy settings: If one person sees the failure on iOS, macOS, or iPadOS, test the same tracked URL on another network and browser before changing DNS.
- Unsubscribe logic: A tracked click alone does not prove that a custom unsubscribe endpoint recorded an opt-out. Test the resulting suppression in the system that controls future sends. For marketing mail, group-level unsubscribe handling keeps one topic opt-out from turning into a global suppression.
- HTTP only: Plain HTTP tracking can create browser warnings, trust problems, and weaker link reputation signals. Use branded HTTPS tracking when click metrics must stay on.
If manual testing shows the link works but SendGrid reports a click or unsubscribe spike, use non-human click guidance as an investigation path. SendGrid includes bot and security-software activity in reporting, so a spike is not proof of human engagement. Compare event type, timestamp, URL, IP, user agent, message ID, recipient, and campaign ID. Investigate scanner activity when clicks occur immediately after delivery, many events share an IP, or one recipient appears to click many links.
For manually managed proxy or CDN tracking, complete the initial link-branding validation while the CNAME points to the target SendGrid expects. After changing the first CNAME to the final SSL proxy or CDN, do not revalidate it in the SendGrid UI. That second validation fails because the record no longer points directly to SendGrid. If revalidation has already broken the setup, restore the SendGrid target, validate again, then repoint the first CNAME to the proxy.
Template bugs also matter. If only one link breaks, compare the raw HTML before SendGrid processes it and after the email is delivered. Missing schemes, unescaped ampersands, malformed Liquid or Handlebars variables, and CMS filters can create a bad original URL before SendGrid touches it. Use a fully qualified HTTPS URL in a quoted href, and check that the destination query string survives template rendering without double encoding.
If the broken link appears only for some recipients, test across mailboxes, devices, corporate networks, home networks, and privacy settings. A security gateway can block a tracking domain that works elsewhere. That does not clear SendGrid or DNS, but it changes the fix from "tracking domain is dead" to "tracking domain has a reputation or filtering problem."
A practical troubleshooting checklist
The fastest way to avoid circular troubleshooting is to test each layer in order: message HTML, SendGrid rewrite, DNS, HTTP response, HTTPS response, redirect, final destination, and authentication. Skipping straight to DMARC wastes time when the browser error is happening at the tracking host.
Start with the delivered email because it proves what recipients received. A SendGrid preview, website CMS preview, or template editor does not prove what arrived in the mailbox.
DNS and response checksbash
dig url1234.example.com CNAME dig url1234.example.com A # Paste the complete URL from a fresh test email. read -r -p "Full tracking URL: " sendgrid_tracking_url curl --silent --show-error --location --max-redirs 10 \ --dump-header - --output /dev/null "$sendgrid_tracking_url"
Replace the example hostname with the one in the delivered link. Keep the complete tracking path and query string when testing: a bare /ls/click path has no tracking payload and can return an error even on a healthy host. The curl command makes a GET request and follows redirects. Use a fresh test email with a non-sensitive destination, since the request counts as a click.
- Copy the link: Use the actual link from the delivered email.
- Capture the warning: Save the screenshot, warning wording, browser, device, network, and timestamp when the issue is a dangerous-link block.
- Check the scope: Test another browser, network, and device when the report is device-specific.
- Compare inboxes: Save the message source from one working mailbox and one affected mailbox when the failure is limited to certain recipients.
- Identify the host: Separate the tracking hostname from the long query string.
- Check DNS: Confirm that the hostname resolves through the expected CNAME.
- Check HTTPS: Confirm the certificate matches the tracking hostname.
- Follow redirects: Verify the final destination returns a normal page.
- Retest sending: Send a new email after each change; also retest an older tracked URL after DNS, SSL, or proxy repairs.
Twilio SendGrid tracking settings showing click tracking turned off to fix broken links.
For the DNS request, include the exact hostname that appears in the broken link. Asking IT to "fix SendGrid" is too vague. Asking for a CNAME check on the tracking host, plus an SSL check for that same host, gives them a concrete task.
Views from the trenches
Best practices
Capture the delivered link first, then compare it with the source template before editing DNS.
Disable click tracking for urgent sends, then rebuild branded link DNS and SSL in staging.
Give IT the exact tracking hostname, desired CNAME target, and business impact in one ticket.
Common pitfalls
Assuming DMARC rewrote links sends teams down the wrong path and slows customer fixes.
Changing CNAME records without SendGrid's expected target can create more failed clicks.
Expecting tracking settings to rewrite old emails misses DNS and SSL repairs that restore old links.
Expert tips
Treat every link changing to an ls/click URL as platform tracking until proven otherwise.
Check HTTPS manually because a tracking domain can resolve while the certificate still fails.
Keep authentication monitoring separate from redirect testing so each owner gets clear work.
Marketer view
Marketer from Email Geeks says rewritten SendGrid links that use ls/click usually point to click tracking being enabled for the sending path.
2024-03-12 - Email Geeks
Marketer view
Marketer from Email Geeks says a missing tracking hostname points to link tracking being enabled before the needed DNS was finished.
2024-03-12 - Email Geeks
Confirm recovery before restoring tracking
If every SendGrid link is broken and the URL contains /ls/click or /ss, disable tracking or bypass it on the critical anchor for new emails. Restore tracking only after the branded hostname passes DNS, HTTPS, and redirect tests. Include previously delivered links in the recovery check.
If the problem persists, send IT or SendGrid Support the exact hostname, a complete test tracking URL, the expected DNS target, the error text, and whether the problem affects every recipient. Include whether the branding uses Auto SSL or a manual proxy, and identify the sending account or subuser.
