Why does Gmail show a 'Suspicious Link' notification for HTTPS websites?
Published 29 Apr 2025
Updated 18 Oct 2026
13 min read
Summarize with
Updated on 18 Oct 2026: We clarified Gmail link warnings, corrected CNAME and TLS checks, and added a controlled test for tracking links.
Gmail shows a "Suspicious Link" notification for an HTTPS website when it identifies the link as unsafe or untrusted in that message. With a valid TLS certificate, HTTPS encrypts the connection and verifies the hostname. It does not prove the URL is safe, the tracking domain has a clean reputation, the certificate covers every HTTPS hostname in the redirect path, or the final landing page is free of risky content.
The click-tracking domain deserves separate inspection because it sits between the email and the visible landing page. Google's published guidance confirms that Safe Browsing identifies dangerous links in Gmail and that checks can happen when a user clicks. Google does not publish the full scoring formula, so treat redirect behavior, destination safety, and sender context as diagnostic leads. Check DNS and certificate validity separately for connection problems. A clean HTTPS product page can still sit behind a tracking URL that Gmail distrusts.
Fast answer
If the website loads over HTTPS but Gmail still warns, check these items first:
- Tracking host: The real email href often points to a click-tracking subdomain before it redirects to the final page.
- Certificate match: Each HTTPS URL needs a valid certificate for its hostname. A browser certificate error is a separate warning from Gmail's link verdict.
- Reputation: Shared redirect domains can carry reputation problems caused by other senders using the same infrastructure.
- Destination mismatch: Gmail can warn when link text, the href host, and the final destination do not make sense together.
Why HTTPS is not enough
HTTPS is a transport signal. Gmail's warning is a trust signal. Those two checks overlap, but they are not the same check. A site can have a valid TLS certificate and still host unsafe pages, compromised redirects, deceptive login pages, malware downloads, or old campaign URLs that were abused after launch.
The visible text is not always the clicked URL. In a marketing or transactional email, the visible text can be a friendly URL while the href points to a tracking domain. A CNAME resolves that hostname to infrastructure run by an email service provider (ESP); it does not redirect the browser or change the URL hostname. The tracking server records the click and returns an HTTP redirect to the final HTTPS page. Inspect each URL in that route.
What HTTPS proves
- Encryption: The browser can encrypt traffic to the hostname it reached.
- Certificate scope: The certificate covers that exact hostname or a valid wildcard.
- No content verdict: HTTPS does not say the page content is safe or trusted.
What link protection considers
- Known threats: Safe Browsing checks for dangerous links and harmful destinations.
- Message context: Authentication, sender history, and content patterns can affect trust.
- Redirect safety: A broken, deceptive, or abused redirect path can create risk before the final page loads.
Common email link path
Visible text: https://www.example.com/sale Email href: https://links.example.com/c/abc123 DNS: links.example.com CNAME click.esp.example Redirect: https://www.example.com/sale
In that example, the certificate must cover links.example.com. A certificate for click.esp.example alone is insufficient. The CNAME target needs its own URL-hostname check only if a redirect actually sends the browser to that hostname. A valid certificate still does not establish that the tracking URL is safe.
Gmail Suspicious Link troubleshooting flow covering the email href, tracking host, TLS certificate, redirects, and final HTTPS page.
Identify which warning you are seeing
Record the exact wording and where it appears before changing DNS or certificates. A Gmail click warning, a message banner, and a browser error require different investigations.
|
|
|---|---|
Gmail prompt after clicking, such as "Suspicious link" or "untrusted site" | The original email href, tracking redirects, and the recipient's Workspace link policy. |
Warning banner above the email | The message's authenticity and content, including sender authentication. |
Browser certificate or privacy error | The URL hostname, certificate validity, and TLS configuration at that hop. |
Browser dangerous-site warning | Unsafe or deceptive content on the destination or an intervening redirect. |
Warning wording varies by client; record the location as well as the text.
If you are the recipient, open the organization's known website directly rather than proceeding through a warned link. Google Account sign-in alerts concern account activity and are a separate issue.
Link safety and infrastructure checks
Inspect the link infrastructure as well as the landing page. These checks cover URL safety and connection faults; they are not a published list of Gmail warning triggers.
- Shared redirector: A shared ESP click domain can carry reputation noise from other senders, especially if they sent links to abusive pages.
- Tracking certificate: The tracking hostname needs a valid certificate for the exact name reached over HTTPS. A final-page certificate does not fix a bad first hop.
- HSTS behavior: A browser with a stored or preloaded parent-domain HSTS policy containing includeSubDomains upgrades HTTP requests to the tracking subdomain to HTTPS. Missing TLS then causes a browser connection error, not proof of Gmail's warning trigger.
- Unsafe content: One risky page or old redirect on the same host can hurt the domain's safety signal.
- Misleading link text: A link that appears to go to one brand but redirects through unrelated hosts can look deceptive.
- Shortened URL: A URL shortener hides the destination and adds another redirect host for Gmail to evaluate.
- New domain: Check a new tracking domain's DNS, TLS provisioning, and redirect behavior. Google does not publish a minimum domain age that removes this warning.
- Blocklist hit: A blocklist or blacklist listing for a sending IP, redirect host, or linked domain is a reason to investigate reputation, but it does not prove what triggered Gmail. Suped's blocklist monitoring helps track that signal separately from authentication.
- Weak authentication: SPF, DKIM, and DMARC failures warrant a separate message-authentication check. Passing authentication does not establish that a URL is safe.
Google's Safe Browsing status is useful when the final domain or tracking domain has a visible safety issue. It will not explain every Gmail decision, but it gives a clear first check for known unsafe URL signals.
Do not switch tracking links to HTTP to work around a certificate error. HTTP leaves that hop unencrypted, and HSTS can upgrade it back to HTTPS anyway. Configure HTTPS on the tracking hostname; the final page's certificate does not secure an earlier HTTP hop. For more context, see HTTP versus HTTPS.
Link troubleshooting priorities
Editorial troubleshooting priorities, not Google risk scores or a guarantee that Gmail will trust a link.
Checks pass
Retest message
HTTPS and redirects work as expected. Continue testing the exact email in the affected account.
Needs investigation
Inspect route
A shared or shortened tracking URL adds hosts to inspect; its presence alone does not prove a problem.
Confirmed fault
Fix first
A certificate error needs TLS repair; unsafe content needs cleanup. Diagnose the two separately.
How to diagnose it
Inspect the actual email href and test the message as Gmail receives it. Do not copy the visible URL from the email body and assume that is the URL Gmail judged. In Gmail on the web, open the message and select More beside Reply, then Show original. Inspect the decoded HTML anchor href and save the original message. A mail client can wrap links for protection, so distinguish that wrapper from the sender's tracking URL.
For a live test, send the same campaign to Suped's email tester and compare its authentication and content findings against the affected Gmail message. That gives you a repeatable baseline before changing DNS or ESP settings; it does not reproduce Gmail's private link verdict.
Email tester
Send a real email to this address. Suped shows a results button when the test is ready.
?/43tests passed
Check the sending domain and link domain together. Suped's domain health checker reviews DMARC, SPF, and DKIM DNS configuration. Check the received message headers as well, because published records do not prove a specific message passed authentication or that a link is safe.
- Capture the href: Record the exact link inside the email, including scheme, host, path, and query string.
- Resolve the CNAME: Look up the tracking subdomain and identify the platform host behind it.
- Test HTTPS first: Check the complete tracking URL, including its path, over HTTPS. Confirm the certificate covers that host and is current and trusted.
- Follow redirects: Trace each hop on the exact URL, including scheme changes and Location destinations. A tracking host's root page alone does not test the campaign link.
- Check content: Inspect login forms and downloads for deceptive or compromised content. Check open redirects and expired campaign pages; a legitimate login page alone is not a fault.
- Verify authentication: Read Gmail's Authentication-Results. SPF checks the MAIL FROM domain; DKIM uses the signing d= domain. DMARC needs either SPF or DKIM to pass with a domain matching the visible From under DMARC's rules.
For a controlled test of a URL you own and have checked, send two otherwise identical messages to the same affected account: one with the tracked link and one with the direct HTTPS destination. Keep the sender and content constant. If only the tracked version warns, focus on the tracking route. Include footer and signature links in the review. Use test tokens for activation or password-reset links, since opening them can consume a one-time token.
Email tester sample report showing total score, email preview, issue summary, and per-section results
What to fix
Fix each confirmed fault in the click path. If testing isolates the tracking URL, changing copy on the final website does not repair that route. The tracking hostname needs correct DNS, a valid certificate, a simple redirect path, and no unsafe URLs left behind from older campaigns.
If Google Search Console lists a security issue for a host you control, clean every affected page and request a security review after confirming the fix. Its sample URLs are not a complete list of affected pages. Google says reviews take several days or weeks, with some link-related reviews taking longer. Wait for a decision before resubmitting. If Gmail marks the message itself as phishing but the message is legitimate, the recipient can use "Report not phishing" as feedback. That feedback does not replace technical cleanup or request a review of the website.
Preferred tracking setup
links.example.com CNAME tracking.esp.example Required: Valid, trusted TLS certificate covers links.example.com Exact campaign URL returns the intended redirect Final URL loads the expected page over HTTPS Old campaign paths do not redirect to risky pages
Best practical setup
- Dedicated host: Use a branded tracking subdomain instead of a generic shared click host.
- Valid TLS: Make sure the certificate covers the tracking hostname exactly.
- Short route: Keep the redirect path simple and send users to the expected final page.
- Clean archive: Remove or safely retire old campaign paths, especially download and login URLs.
Shared redirector
A shared redirector is quick to launch, but it mixes your link reputation with other senders on the same infrastructure.
- Setup: Fewer DNS steps and less certificate work.
- Risk: Other senders can affect how the shared host is judged.
Dedicated tracking domain
A dedicated tracking domain takes more setup, but it gives you control over the branded hostname and its certificate. It can still use shared ESP infrastructure and does not guarantee Gmail trust.
- Setup: Requires DNS, SSL, and ESP validation.
- Risk: Your campaigns and the provider's infrastructure still need review.
If the warning appears around login pages, payment pages, or account-update calls to action, reduce ambiguity. Use brand-consistent domains, avoid generic button text, and keep the visible destination consistent with the actual destination. The related guidance on Gmail security warnings covers broader content and sender-side checks.
Where DMARC and sender trust fit
A Gmail Suspicious Link notification is not a DMARC failure message. Sender authentication is a separate check on the message's claimed origin. Passing DMARC does not certify a website or clear a dangerous link, and a failing result does not identify which URL caused the warning.
Suped's DMARC monitoring helps review sending sources and SPF/DKIM results so authentication faults can be investigated separately. DMARC aggregate reports do not contain the email's links or Gmail's link verdict; keep that evidence from the affected message alongside the authentication findings.
Issues page showing top issues, verified sources, unverified sources, and authentication pass rates
Suped workflow
- Confirm authentication: Check whether SPF, DKIM, and DMARC pass for the real sending sources.
- Find issues: Use automated issue detection and fix steps instead of reading raw aggregate reports.
- Watch reputation: Monitor blocklist and blacklist changes alongside authentication health.
- Keep URL evidence: Save the original href and warning text with the affected message; DMARC aggregate reports do not include them.
Why the warning can differ by account
Google uses click-time link protection in official Gmail clients. Google Workspace administrators can enable "Show warning prompt for any click on links to untrusted domains" under Apps > Google Workspace > Gmail > Safety > Links and external images. With that setting enabled, prompts apply to untrusted links in any email; without it, Google says these prompts apply to untrusted links in suspicious messages. The setting does not apply to IMAP/POP clients, which have separate link protections.
Use a controlled comparison to separate a broad URL problem from an account-specific policy:
- Send the same message: Deliver one unchanged message to a personal Gmail account and the affected managed account.
- Keep the href identical: Confirm both copies contain the same original tracking URL and were not rewritten differently.
- Compare the browser result: For a destination you control and have checked, compare direct navigation in a clean browser profile. Record browser warnings separately from Gmail prompts.
- Check Workspace policy: Ask which Links and external images settings apply to the recipient's organizational unit. Adding a sender to a spam allowlist does not necessarily override these protections.
If the warning appears only in one managed organization, record the account type, exact href, time, and warning text. The recipient's Workspace administrator owns the policy review, while the sender still owns the safety of every host in the click path. Do not ask an administrator to weaken link protection to hide an unresolved URL problem.
Who should investigate and when to retest
When the warning persists after a fix, retest the exact message in the affected account and client. DNS cache expiry, certificate deployment, and Google's security review are separate processes; waiting for DNS alone does not clear a URL verdict. There is no published fixed waiting period that guarantees a Gmail warning disappears.
Google's own Gmail phishing guidance tells users to treat suspicious links cautiously. Gmail also accepts phishing and not-phishing reports as feedback. Treat recipient reports as a signal to investigate, not a guaranteed way to change a link verdict.
|
|
|
|---|---|---|
Certificate error | ESP or TLS administrator | Repair TLS for the URL hostname |
Shared host | ESP | Check host status |
Unsafe page | Website | Remove risk |
DMARC failure | Sender or ESP | Check signing, SPF authorization, and From-domain matching |
Workspace-only | Recipient admin | Review policy |
Use this table to decide who needs to act first.
If the ESP owns an affected redirect host, provide the exact URL and warning evidence so it can investigate its infrastructure. A branded tracking hostname is an option after the underlying issue is fixed. For a clean link that still warns only in one managed organization, the recipient's administrator can escalate with the message and test results; switching hostnames to bypass a warning leaves the original issue unresolved.
Views from the trenches
These dated community observations are anecdotal, rather than confirmation of Gmail's current warning criteria. Use them as investigation leads and verify findings against the affected message.
Best practices
Inspect every redirect hop before judging the visible HTTPS landing page as safe in Gmail.
Use a dedicated tracking subdomain with a certificate that covers that exact hostname.
Retest with the affected Gmail account after DNS, certificate, and redirect changes settle.
Common pitfalls
Assuming HTTPS on the final page proves Gmail trusts every tracking URL in the email.
Leaving old redirect paths live after campaigns end gives scanners more risky URLs to review.
Ignoring unsafe URLs on a shared ESP redirect host leaves a separate safety issue unchecked.
Expert tips
Check the certificate name, redirect host, and final host as separate risk points first.
Keep link text honest, so Gmail does not see a mismatch between promise and destination.
Monitor blocklist and blacklist hits on tracking domains, not only sending IPs, daily.
Marketer view
Marketer from Email Geeks says a site can trigger the warning when other content on the same host has a poor safety signal.
2020-04-03 - Email Geeks
Marketer view
Marketer from Email Geeks says shared ESP redirect domains can pass reputation problems between senders when the same hostname handles risky URLs.
2020-04-03 - Email Geeks
