Why are my tracking links not working in Chrome and showing an error?
Updated on 19 Oct 2026: We updated our troubleshooting steps for Chrome blocking rules, HTTPS tracking setup, and redirect checks.
Tracking links usually stop working in Chrome because the click-tracking domain has a web-layer problem, not because the email HTML itself is broken. Common causes include a missing or stale CNAME record, an expired or mismatched TLS certificate, HSTS or HTTPS-upgrade behavior reaching a host that cannot serve HTTPS, a bad redirect, a malformed wrapped URL, or backend servers returning different certificates. An ad blocker or workplace policy can also block an otherwise working tracking URL.
For DNS or TLS errors, make the tracking domain load cleanly over https, renew or replace the certificate, remove any broken redirect hop, and confirm every DNS answer for the tracking hostname lands on a correctly configured server. Also send a real message through an email tester because the inbox click path often differs from a link pasted into a browser.
- HTTPS: HSTS requires HTTPS; Chrome also attempts HTTPS upgrades and can warn before allowing HTTP.
- Certificate: An expired, wrong-name, incomplete-chain, or weak certificate stops the click before the redirect finishes.
- DNS: A missing CNAME, stale record, or mixed backend pool can make the hostname fail or behave intermittently.
- Browser: A cached HSTS rule, extension, corporate proxy, or Safe Browsing decision can affect one machine first.
- Tracking setup: Click tracking adds redirect hops, so one bad hop makes the final destination look broken.
Why Chrome shows the error
Chrome evaluates every hostname in the click path. A link inside an email can look like it points to a normal website, but the actual href often goes to a tracking hostname first. That hostname records the click, then redirects to the final page. If Chrome cannot resolve, connect to, or trust the tracking hostname, the browser stops there and the recipient never reaches the destination.
Chrome tracking-link privacy warning with NET::ERR_CERT_DATE_INVALID.
Common failure pattern
An HSTS policy for the tracking hostname, including a parent policy with includeSubDomains, changes HTTP requests to HTTPS before they reach the server. HSTS prevents fallback to HTTP. Without HSTS, HTTPS-upgrade behavior depends on Chrome settings; "Always use secure connections" can show a warning before HTTP access. A link explicitly using HTTPS does not fall back to HTTP when the secure connection fails. Check every redirect hop, even if the final landing page supports HTTPS. Chromium's HTTPS-upgrade guidance explains this distinction. A link can start failing after a certificate renewal, DNS change, CDN change, or tracking-domain migration.
- HSTS: The browser has a cached or preloaded policy that requires HTTPS for the hostname.
- Expired TLS certificate: Chrome rejects the certificate because its validity period has ended.
- Mixed nodes: Some resolved IPs are configured correctly while others return the wrong certificate.
- Bad redirect: The click host redirects to a malformed, blocked, or unreachable URL.
What the recipient sees
- Security page: Chrome shows a certificate, privacy, or unsafe-link warning.
- Blank redirect: The tab opens but never reaches the landing page.
- Different devices: One laptop works while another fails because they use different network paths or local browser state.
- Specific emails: One campaign fails because it used a different click domain, old link wrapper, or stale template.
What the sender should check
- Trace: Follow each redirect hop until the final landing page loads or fails.
- Certificate: Check validity dates, hostname coverage, issuer chain, and server name handling.
- DNS answers: Verify the CNAME target and test resolved IPv4 and IPv6 addresses, not just the first answer.
- Email path: Click the real delivered email because link wrapping can change after send time.
Common causes of broken tracking links
Treat Chrome tracking-link failures as a redirect-chain investigation. The href in the HTML, click-tracking host, certificate on that host, and final landing page all have to work. One weak point breaks the whole click.
|
|
|
|---|---|---|
HTTP tracking URL | HTTPS upgrade reaches an endpoint without working TLS | Open HTTPS version |
Expired certificate | Privacy error page | Check dates and clock |
Wrong hostname | Name mismatch | Inspect SAN entries |
Missing or stale CNAME | Host fails or reaches old service | Verify DNS target |
Mixed DNS backends | Intermittent clicks | Test all IPs |
Bad redirect | Final URL never loads | Run redirect trace |
Common Chrome tracking-link failures and the first check to run.
Redirect and DNS checksbash
# Use a test campaign URL; GET requests can record clicks or consume one-use links. curl -sS -L --max-redirs 10 --connect-timeout 10 --max-time 30 -D - -o /dev/null 'https://trk.example.com/click/abc123' curl -sS -L --max-redirs 10 --connect-timeout 10 --max-time 30 -D - -o /dev/null 'http://trk.example.com/click/abc123' dig CNAME trk.example.com +short dig A trk.example.com +short dig AAAA trk.example.com +short # Repeat with each resolved address; replace this documentation-only example IP. curl -sS --resolve 'trk.example.com:443:192.0.2.10' -D - -o /dev/null 'https://trk.example.com/click/abc123' openssl s_client -connect 192.0.2.10:443 -servername trk.example.com -verify_hostname trk.example.com -verify_return_error </dev/null
These curl commands use GET requests and show each HTTP status and Location header. A HEAD-only check can return a different response or HTTP 405 even when a normal click works. Quoted URLs preserve query-string characters. The per-address probes keep the tracking hostname for certificate checks and Server Name Indication (SNI); repeat them for IPv6 addresses too. A CNAME lookup alone does not confirm that HTTPS is ready.
If the HTTP version fails but the HTTPS version works, update the email platform or template so new messages use secure tracking links. If HTTPS fails, fix the certificate or hosting first. The question of whether HTTP tracking links affect deliverability is separate, but broken HTTP-to-HTTPS behavior creates a user-facing failure before deliverability analysis matters.
Checks by failure type
Choose the next check using the exact error. Urgency depends on the number and importance of affected clicks.
TLS or HTTPS failure
Repair endpoint
Certificate expired, wrong hostname, or HTTPS unavailable.
HSTS requirement
Enable HTTPS
A cached or preloaded HSTS policy requires HTTPS, but the host only supports HTTP.
Inconsistent DNS answers
Trace all
Different DNS answers reach different backend configurations.
Browser or network blocking
Compare environments
Only one Chrome profile or network blocks the click; check local controls and affected recipients.
How to isolate the break
The fastest way to avoid guessing is to separate browser behavior, web hosting, DNS, and email rewriting. Use a fixed order so a certificate problem does not get blamed on Chrome and a local extension does not get blamed on the email platform.
- Copy: Copy the real href from the delivered email, not the visible button text.
- Capture: Record the exact Chrome message and error code before changing the link.
- Trace: Open Chrome DevTools in the tab you will test, select Network, enable Preserve log, then open the delivered href and note the first failing request.
- Compare: Test another browser, network, and clean Chrome profile.
- Resolve: Check the CNAME chain and list every A and AAAA answer for the tracking hostname.
- Probe: Check the certificate returned by each backend or edge node.
- Retest: Test a newly delivered email and a previously sent campaign link after the fix; they can use different wrappers.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
A real sent message matters because click tracking is often applied after the campaign is assembled. A link that looks fine in a template preview can become a different tracking URL after send processing, personalization, unsubscribe handling, or UTM tagging. When the sent message fails, save the full href and exact Chrome error code before editing anything. Chrome's Network panel documentation explains how Preserve log retains requests across page loads.
Match the Chrome error to the cause
The exact Chrome error narrows the problem and identifies who should own the fix. Capture it before clearing browser data or changing DNS. A command-line redirect trace can confirm server behavior, but it will not reproduce every extension, workplace proxy, or browser security decision.
|
|
|
|---|---|---|
NET::ERR_CERT_DATE_INVALID | Expired or not-yet-valid certificate, or wrong device time | Compare certificate dates with the device clock |
ERR_CERT_COMMON_NAME_INVALID | Certificate does not cover the tracking hostname | Inspect SAN entries and SNI handling |
NET::ERR_CERT_AUTHORITY_INVALID | Untrusted chain, missing intermediate, or HTTPS-intercepting proxy | Inspect the chain and compare a different network |
ERR_NAME_NOT_RESOLVED | Missing, mistyped, or stale DNS record | Verify the CNAME target and its DNS answers |
ERR_TOO_MANY_REDIRECTS | Redirect loop or cookie-dependent routing | Trace Location headers, then test a clean profile |
HTTP 400, 404, 410, or invalid-link page | Damaged query string, expired token, deleted campaign, or missing redirect mapping | Check the exact token, campaign status, and destination encoding with the ESP |
ERR_SSL_VERSION_OR_CIPHER_MISMATCH | No shared TLS version or cipher, or incomplete HTTPS provisioning for the tracking hostname | Confirm HTTPS provisioning and TLS 1.2 or TLS 1.3 support on every edge |
ERR_CONNECTION_REFUSED or ERR_CONNECTION_TIMED_OUT | No HTTPS listener, firewall block, or backend outage | Probe each resolved address on port 443 |
ERR_BLOCKED_BY_CLIENT | Browser-side blocking, often an ad-blocking or privacy extension | Compare a clean Chrome profile without extensions |
ERR_BLOCKED_BY_ADMINISTRATOR | Managed browser URL policy blocks the tracking hostname | Ask IT to review the blocked hostname and applied policy |
Dangerous site or deceptive site warning | Browser security classification or compromised redirect | Pause sends and inspect the complete redirect path |
Chrome tracking-link errors, likely causes, and first checks.
Do not bypass the warning
Do not tell recipients to click through a privacy or security warning. Chrome does not offer a normal certificate-error bypass when HSTS applies. Repair the tracking endpoint, verify the complete redirect path, and send a fresh test message.
When Chrome blocks a working tracking link
A tracking URL can have valid DNS and TLS and still be blocked in Chrome. ERR_BLOCKED_BY_CLIENT indicates client-side blocking, while ERR_BLOCKED_BY_ADMINISTRATOR indicates an administrator URL policy. These are separate cases in Chromium's network error definitions. A certificate renewal will not remove either rule.
- For client blocking, compare the exact URL in a clean profile without extensions. An ad blocker or privacy extension can block the tracking domain before it redirects.
- For administrator blocking or an office-only failure, give IT the hostname and error code so they can inspect browser policy or network filtering.
- For a red dangerous-site warning, pause affected sends and investigate the tracking host and every destination for unwanted redirects or compromised content. Fix the cause before requesting a classification review.
- If the recipient environment deliberately blocks tracking, use direct HTTPS links in affected messages and accept the loss of click reporting.
Incognito is not a complete extension test because Chrome permits extensions with Allow in incognito enabled. A clean email blocklist (blacklist) result also does not establish that Chrome will permit the URL. Google's Chrome security guidance distinguishes a dangerous-site warning from a connection privacy error.
How to fix it
The durable fix is to make the tracking path secure and consistent end to end. The tracking domain needs correct DNS, a valid certificate for the exact hostname, a working HTTPS listener, and a clean redirect to the final page. Do not ask recipients to bypass Chrome. A CNAME does not by itself guarantee a certificate for a custom tracking domain. Enable HTTPS tracking in the ESP and confirm certificate provisioning before changing the link scheme.
Clean fix pattern
Use secure tracking links in new emails, keep ownership of the click-domain certificate explicit, and monitor the click host before large sends. If the tracking provider manages the click domain, give its support team the failing URL, resolved IPs, certificate details, and Chrome error code.
Tracking link patterntext
Legacy HTTP tracking link: http://trk.example.com/c/abc123 HTTPS tracking link, after ESP certificate provisioning: https://trk.example.com/c/abc123 Final destination: https://www.example.com/product?utm_source=email
Short-term workarounds
- Disable tracking: Disable click tracking for urgent new sends until the host is fixed; this does not change links already delivered.
- Use direct URLs: Link straight to the landing page for critical transactional paths.
- Send a correction: Use a fixed URL if the original campaign already reached users.
- Limit sends: Pause high-volume campaigns that depend on the broken click host.
Durable fixes
- Renew the certificate: Replace expired certificates and verify the full chain.
- Enforce HTTPS safely: Configure the click host to serve HTTPS before enabling HSTS.
- Fix DNS: Remove stale records and confirm every target is configured.
- Monitor changes: Monitor HTTPS availability and certificate expiry on the click host, and track authentication and sender reputation separately.
Email tester sample report showing total score, email preview, issue summary, and per-section results
Suped's email tester checks the authentication and sending setup of a real delivered message. Its TLS result describes the SMTP connection that delivered the test to Suped, not the tracking domain's HTTPS certificate. Pair the report with a manual click test and the redirect checks above after the ESP rewrites links.
Where authentication and reputation fit
DMARC, SPF, and DKIM do not fix an expired tracking-link certificate. They check email authorization and signing identities; a passing result does not establish that a tracking URL is safe. Check authentication beside link health because recipients and filters experience the whole message, not isolated parts.
Suped's DMARC monitoring shows whether legitimate sending sources pass authentication, while blocklist monitoring helps catch domain or IP blacklist problems. Email blocklist results and Chrome's browser security decisions are separate signals, so a clear result does not rule out a browser warning.
Where Suped fits
Use Suped's DMARC reports to identify authentication failures when a campaign also has sending problems, and use its blocklist (blacklist) monitoring to investigate listed domains or sending IPs. Give the website or ESP team the separate Chrome error evidence for the tracking host.
Security filters can also rewrite or prefetch links before a human clicks. That creates a different class of failures than Chrome certificate errors. If the redirect works in a normal browser but fails only after a gateway touches it, review how filters break links and compare the raw delivered href with the URL the email platform generated. Preserve signed tokens and query parameters; truncated or double-encoded destination URLs can break the redirect. For one-use or expiring links, check whether a scanner consumed the token before the recipient clicked.
What to tell IT or your ESP
A clear escalation saves time. Website and DNS teams often own different parts of the path, while the email team controls link wrapping. Give each team the same evidence packet so nobody has to reconstruct the failure from screenshots alone.
Example ticket details to includetext
Failing href: https://trk.example.com/click/abc123 Chrome error: NET::ERR_CERT_DATE_INVALID Chrome version and OS: [copy from the affected device] Failure time and timezone: [record the observed time] Works on: Firefox on home network Fails on: Chrome on office network Resolved IPv4 addresses: 192.0.2.10, 192.0.2.11 Resolved IPv6 addresses: [include AAAA answers, if present] First bad hop: https://trk.example.com/click/abc123 Certificate issue: [record the actual expiry date and hostname] Campaign: [affected campaign and send time] Link scope: [new test links, previously sent links, or both]
Ask for these confirmations
- Certificate: Confirm the tracking hostname has a valid certificate on every edge node.
- Redirects: Confirm each hop returns a valid status and points to the intended next URL.
- DNS: Confirm the CNAME target and all A and AAAA answers reach the intended service without stale records.
- HSTS: Confirm the host can serve HTTPS before enforcing it with browser policy.
- Retest: Confirm the fix with a newly sent email and a previously sent campaign link.
Views from the trenches
Best practices
Test the full redirect chain over HTTPS before a campaign uses a new tracking domain.
Keep the tracking hostname on HTTPS even when the final website handles the click.
Monitor every IP behind the tracking hostname for certificate and redirect consistency.
Common pitfalls
Assuming one successful click proves all DNS answers and backend nodes are healthy.
Renewing the main site certificate while the tracking certificate remains expired.
Blaming Chrome before checking HSTS, certificate expiry, redirects, and extensions.
Expert tips
Trace the redirect and test each resolved IP so inconsistent servers appear quickly.
Compare Chrome, another browser, and a clean network to separate local issues clearly.
Fix the click domain before retesting placement because broken clicks skew signals.
Marketer view
Marketer from Email Geeks says Chrome can reject a tracking link when HSTS requires HTTPS and the click host cannot provide a valid secure response.
2021-12-10 - Email Geeks
Marketer view
Marketer from Email Geeks says an expired TLS certificate on the tracking domain is enough to stop Chrome before the redirect reaches the final page.
2021-12-10 - Email Geeks
