Different hostname behind a link: red flag or harmless?

Hover over enough links in your inbox and you will notice that the address behind a link rarely matches its text exactly. Your bank's email says www.harbourline.example and the link goes to login.harbourline.example. A newsletter link names a shop and points at a mailing service. A parcel notice names a carrier and points at something else entirely. Some of these differences are routine; one of them is how phishing works. The trick is knowing which part of the hostname to look at.

Read the hostname from the right

First find the part between https:// and the first /, ? or # (or the end of the address if none follows). That part can contain more than the hostname: anything before an @ is not the host, and neither is a port number at the end, such as :8443. In https://[email protected]/ the host is account-review.example.

A hostname is read from right to left. In mail.harbourline.example, .example is the top-level domain and harbourline.example is the registrable domain: the name a person or company registered and controls. Everything to its left (mail., www., login.) is a subdomain that the domain's owner sets up, or lets someone else run. So mail.harbourline.example and www.harbourline.example share a registrable domain, which usually, but not always, means the same party controls both (more on the exceptions below). Some country suffixes take two labels: in www.phpfreelance.co.uk the suffix is .co.uk, so the registrable domain is phpfreelance.co.uk.

The left-hand side is also where attackers dress up. In harbourline.example.account-review.example the familiar name is only a label on somebody else's domain: the registrable domain, on the far right, is account-review.example. A 2025 campaign against Booking.com used the same idea with a Japanese character that looks like a slash, so the attacker's registered domain www-account-booking[.]com sat behind text that read like a path on booking.com. I took that one apart in the Reveal URLs article.

When a different hostname is a red flag

A difference becomes a red flag when the link leads to a different registrable domain from the one its text names, and the destination looks like an imitation. The usual forms:

• Lookalike spelling. harb0urline.example with a zero for the "o", a doubled or swapped letter, or the brand plus a reassuring word: harbourline-secure.example, harbourline-support.example. A different spelling does not prove a different owner, but nothing in the name shows that the owner of harbourline.example registered it, so treat it as a reason to look closer.
• The brand as decoration. harbourline.example.account-review.example: the brand appears, but only as a subdomain label on a stranger's registrable domain.
• Letters from another alphabet. Internationalised domain names may contain letters from other scripts, and some of them look just like Latin letters. On 3 October 2026, Have I Been Squatted showed an apple.com lookalike whose five letters were all Cyrillic, and which Chrome 154 still displayed in Unicode, with a valid certificate. Webmail varied too: in their test with 20 internationalised sender domains, "Gmail decoded everything, and Outlook Web decoded nothing": Gmail Web showed the sender domains in Unicode, Outlook Web their xn-- form. That test covered how the sender address is displayed, not links or either service's phishing filters. In the .com zone they counted 733,509 internationalised domains and 161,894 lookalike pairs, and they point out that a lookalike name is not necessarily malicious. Their own 20 test domains were research, not a live campaign.
• A visible address that leads elsewhere. The text itself reads https://www.harbourline.example/account but the link goes to an unrelated domain. Newsletters sometimes do this for tracking (see the next section). A mailing or tracking service you recognise explains why the hostname differs, but does not make the link safe, as the SendGrid and Trezor cases below show. If you do not recognise the destination, treat it as a mismatch.

When it is usually harmless

Plenty of differences have an ordinary explanation. Knowing them keeps you from treating every newsletter as an attack, and tells you where some care is still needed.

• Subdomains of the same registrable domain. Text harbourline.example, destination mail.harbourline.example or login.harbourline.example: the same registrable domain, which is usually harmless. It is not proof that the same party controls the page, though: an owner can point a subdomain at a service run by another company, and if that DNS record stays in place after the service is shut down (a "dangling" DNS record), someone else can take the subdomain over. Microsoft documents this subdomain takeover and notes that it is used in phishing campaigns.
• Newsletter link tracking. Mailing services commonly send each click through their own tracking address first, which then forwards you to the real page. A link whose text says www.harbourline.example may therefore point at something like click.mailer.example/…. That is normal for newsletters, and, as I noted in the policy article, tracking URLs look suspicious even when they are harmless. It also means the link's own destination is not where you will end up, and a trusted sending platform can carry phishing too: in January 2026, attackers reportedly used compromised SendGrid customer accounts to send it.
• Redirect and link-rewriting services. Search engines, advertising click tracking and some business email security services (which rewrite links so each click passes through their scanner) all put their own hostname in front of the real one.
• URL shorteners. A link such as short.example/a1B2 is not phishing in itself, but it hides the destination completely, so there is nothing to compare the text against. Treat shortened links with care: when a message is about money, passwords or your account, do not click; go to the site yourself.

When every hop looks trusted

The hardest cases are links where nothing looks different at all. Three 2026 examples:

• A chain of Google addresses. On 4 September 2026, the KnowBe4 Threat Lab described a campaign that routed phishing links through Google services, such as meet.google.com/linkredirect, google.com/url?q= and DoubleClick click tracking, so the email gateway saw "trusted Google domains at every hop" before the link reached the attackers' own infrastructure.
• A real sign-in page that sends you on. On 2 March 2026, Microsoft described OAuth redirection abuse: links that start on login.microsoftonline.com or accounts.google.com, built to fail on purpose, after which the sign-in service redirects the browser to an address registered by the attacker.
• A genuine sender. On 9 September 2026, an attacker who had gained access to Brevo, the newsletter platform Trezor uses, sent a phishing email from Trezor's own account. Its link prompted readers to download an app that asked for their wallet backup (Trezor's post of 10 September 2026, updated 17 September).

The lesson: a trusted first hostname, or a genuine sender, says nothing about the final destination. When a trusted address carries a second address inside it, for example after url=, q=, dest= or redirect_uri=, that second address may indicate where you will be sent later. It does not show where the chain ends: the parameter name proves nothing about what the service does with it, and the embedded address can be just another hop, as in the chain KnowBe4 described. For anything that asks you to sign in or pay, the safest link is the one you type yourself, or the official app. A wallet backup is different: never enter it because a message asks you to. Trezor says it will never ask for your wallet backup; follow your wallet maker's own recovery instructions.

How Reveal URLs decides what to flag

Reveal URLs is my own free and open source tool, so read this section as me describing my own work. Its rule is deliberately narrow and predictable:

1. For the web links it annotates, it shows the link's actual immediate URL: inline, directly above the link, in Chrome, Edge, Firefox, Safari and Thunderbird; as a card in Gmail's sidebar; and in a task pane in Outlook.
2. When the link's visible text itself contains a URL or host, it compares that address with the actual immediate URL at the registrable-domain level.
3. If they belong to different sites, it highlights the destination, red by default (a setting you can change). An ordinary subdomain such as mail.example.com against example.com is left alone; a lookalike is flagged.
4. When the text contains no address at all, such as a "Pay now" button, the destination is still shown, just not reddened: there is no host in the text to compare it with.

These are the hostname-comparison rules for ordinary web links. Site settings and excluded hosts can switch the annotation off, and the browser and Thunderbird versions apply separate rules to some non-web links: a javascript: or data: link is always flagged.

The table below uses the reserved example domains example.com, example.net and example.org, because Reveal URLs only recognises an address in link text when it ends in a real public suffix. The made-up harbourline.example names elsewhere in this article illustrate the reasoning, not the product's output.

Two things it deliberately does not do. It does not follow redirects: it shows where the link itself points, not where a tracker, shortener or sign-in service will send you next. And it does not judge whether a site is safe. A link with no mismatch is not automatically safe. No red highlight only means that no mismatch was highlighted: the text and the destination may share a registrable domain, but Reveal URLs may also not have recognised the address in the text, or a setting may have switched it off for that site. Even matching domains do not show that a page is safe. When the text is a button or words without an address, there is nothing to compare, so look at the destination Reveal URLs prints instead.

Hosting platforms can give different people subdomains of one platform domain, such as alice.github.io and bob.github.io. Reveal URLs compares at the registrable-domain level of the ICANN list, so it does not flag one against the other, although different people may control them. A shared platform domain does not mean the same person controls both pages.

Long URLs are shortened inline, to 100 characters by default; the settings let you show more. If you see an ellipsis, look at the full address before deciding: the browser and Thunderbird versions also show it when you hover over the shown URL. The comparison always uses the full URL, but does not follow it.

That is why some of the harmless cases above can still turn red: a newsletter link whose text names www.example.com but points at a mailing service's tracker such as click.example.org really does lead to a different site first. The red box does not say "phishing"; it says "the text and the destination disagree, take a look". In the same way, the hard cases from the previous section may not turn red at all, because the immediate URL really is Google's or Microsoft's. Reading that full URL is still what lets you notice the second address tucked inside it.

Domain age: an extra signal to weigh

The rule Reveal URLs applies compares a link's visible text with the domain of its own destination. Domain age is a separate signal, one for you as the reader to weigh.

A bank, a carrier or a large web shop has usually held its domain for years. If a link that claims to come from such a long-established name leads to a domain registered last week, that is suspicious, even when the name looks plausible and even when the text and the destination agree. In a 2019 analysis, Palo Alto Networks' Unit 42 found that more than 70% of newly registered domains (which it defines as registered or changed ownership within the last 32 days) were "malicious" or "suspicious" or "not safe for work", and that such domains are frequently used by phishing campaigns. The same report also lists perfectly ordinary reasons for a new domain: launching a new product, a new brand or campaign, a conference or a personal site.

So age is a signal, not a verdict, in either direction. A new domain can be entirely legitimate, and an old one can be compromised: the Google-chain campaign above landed its victims partly on compromised .de subdomains. Age adds context to what you already see; it does not decide on its own.

To check, a registration data lookup such as ICANN Lookup shows the current registration data for a domain name, which usually includes when it was created. And if you scan QR codes: my own app QR Quishing Detector, coming soon to Google Play and the App Store, has an optional domain registration-age lookup. It is off by default, and the age it reports is information for you: it does not change the app's risk score.

See the destination before you click

Reveal URLs is free and open source (AGPL-3.0-only). It is available now for Chrome, Edge, Firefox, Safari and Thunderbird, as a Gmail add-on, and as an Outlook add-in for Outlook on the web and desktop. The browser extensions and the Thunderbird add-on do all their work on your own device; the Gmail add-on runs on Google's servers, because that is where Gmail add-ons run.

A different hostname behind a link is a question, not an answer. Read it from the right, find the registrable domain, and ask whether that domain belongs to whoever the text names. For more on how Reveal URLs works, see Reveal URLs: spot phishing links before you click; for why email apps should always show the URL, see Email link phishing: why your email app should always show the URL; and for why a genuine-looking sender is not enough, see Anti-phishing codes: a useful signal that won't check your links.