A .link domain is not safe or unsafe merely because it ends in .link. IANA lists .link as a generic top-level domain. The useful question is whether the exact registered host, sender, redirect path, final destination, and requested action belong together.
Treat an unexpected link differently from one you requested. If a message asks for a password, payment, recovery code, wallet connection, download, or urgent account action, do not use its link. Open the known official site or app independently.
| Check | Reassuring evidence | Warning sign |
|---|---|---|
| Registered host | Exact organization-controlled domain | Lookalike spelling or unrelated owner |
| Message context | Link you requested through a known channel | Unexpected urgency, threat, prize, refund, or invoice |
| Redirect destination | Final host matches the claimed service | Short path lands on another unfamiliar host |
| Requested action | Low-risk public information | Password, card, recovery code, download, or wallet approval |
| HTTPS | Encrypted connection to the shown host | Missing or invalid certificate |
| Ownership proof | Official site, account, or known contact confirms it | Only the message itself claims legitimacy |
1) Judge the exact URL, not .link
The string after the final dot tells you the top-level domain. It does not identify the operator, prove the content, inspect a redirect, or approve a transaction.
IANA's record classifies .link as a generic TLD sponsored by Nova Registry Ltd. The delegation was registered on 9 January 2014, transferred from Uniregistry to Nova in 2022, and updated on 26 June 2026. Those are registry facts, not a security rating for every name beneath the extension.
Any open generic namespace can contain legitimate projects, inactive names, parked pages, compromised sites, and abuse. The same is true of older endings. A familiar suffix can appear in a deceptive address, while an unfamiliar suffix can belong to a real service.
Evaluate the full URL and the action it requests. example.link/report and example-link.com/report are different registered hosts. Neither spelling should be trusted until its ownership and context make sense.
The %%EDITORIAL_0%% profile explains the extension. Use WHOIS research or RDAP for the particular name.
2) Find the registered host
Read a web address from the first slash back toward the left. In https://login.accounts.example.link/reset, the host is login.accounts.example.link; the registrable name is usually example.link. The words farther left are subdomains controlled beneath that name.
Attackers exploit readers who scan from left to right and stop at a familiar word. Consider these structural examples:
bank.example.linkbelongs beneathexample.link, not beneath the bank's domain;example.link.bank.combelongs beneathbank.com;example.link@other.example/pathusesother.exampleas the host in URL syntax;example.link/brand.com/loginstill connects first toexample.linkbecause text after the slash is a path;examp1e.linkandexample-link.comare different names fromexample.link.
Do not rely on colour, logo, page title, or a familiar word placed somewhere in the address. Copy the host into a plain text field if the interface truncates it. Check every letter, hyphen, and label boundary.
Internationalized names can display non-ASCII characters. A browser may expose a xn-- form in some contexts. If a character looks unusual or resembles another alphabet, stop and navigate through the known official site.
3) Treat redirects as concealed destinations
A short .link path can be useful in a campaign, profile, QR code, printed card, podcast, or product handoff. It can also hide the final host until the browser follows one or more redirects.
That hidden destination is the central risk, not the number of characters. A redirect can lead to:
- the expected official page;
- a tracking service and then the official page;
- a different campaign host;
- an expired or reassigned destination;
- an open redirect modified to send visitors elsewhere;
- a credential form, malware download, or fraudulent payment page.
OWASP describes an unvalidated redirect as a redirect built from untrusted input. If a site accepts an arbitrary destination in a URL parameter, an attacker can make a link begin on a legitimate-looking host and end on a malicious site. OWASP notes that open redirects can support phishing and can sometimes bypass domain-based controls.
The visible short link is therefore only the first stop. The final host and every sensitive action still need verification.
4) Use context before clicking
The US Federal Trade Commission advises people not to click links or open attachments in unexpected messages. If the message appears to come from a known company or person, contact them through a website or phone number already known to be real, not through the details in the message.
Pause when a link arrives with:
- a threatened account closure or immediate deadline;
- an invoice, refund, tax notice, delivery problem, or prize you did not expect;
- a request to confirm a password, card, recovery phrase, one-time code, or identity document;
- a download described as a statement, voicemail, security update, or shared file;
- a sender address that does not match the organization;
- a private conversation abruptly moved to a new payment or login page.
A legitimate brand can have a real .link domain. That does not make an unexpected message legitimate. Conversely, a deceptive message can link to a compromised page on a familiar domain.
5) Preview what the interface reveals
On a desktop browser, hovering over a link commonly reveals its immediate target in the status area. On a phone, a long press may show a preview or URL. Email clients, messaging apps, and QR scanners differ, so inspect what your device exposes before opening the page.
Check whether the visible text and immediate target match. A button labelled “Open your bank” should not point to an unrelated .link name. Watch for missing letters, added words, deceptive subdomains, and a path designed to make another domain look prominent.
This check has limits:
- the visible target may immediately redirect;
- an app may truncate the middle of a long URL;
- a redirect can vary by device, location, time, or visitor;
- a compromised legitimate service can still lead somewhere harmful;
- a QR code hides the URL until a scanner decodes it.
Hovering or previewing reduces accidental clicks. It does not certify the final destination.
6) Inspect redirects without increasing the risk
For a low-risk public campaign from a sender you recognize, you can observe the address bar after navigation and before entering any information. Confirm that the final host is the expected official domain, then open the same page independently if the action is sensitive.
Do not visit a suspicious link solely to investigate it. Opening a page can expose your IP address and device information, trigger tracking, or begin a download. Never enter credentials while “testing” a page.
Public link scanners and redirect expanders can be useful for an ordinary public URL, but they create another disclosure. Do not paste a private invitation, password-reset link, account token, signed download, or unsubscribe URL into a public service. The token may grant access or identify you.
For workplace messages, send the original message and headers to the security team using the approved reporting channel. For a personal account, navigate to the provider through a saved bookmark, official app, or manually typed address and check notifications there.
If a redirect begins on a recognized host but ends elsewhere, verify the final host through the claimed organization's official documentation. A partnership or payment processor can be legitimate, but the redirect itself is not sufficient proof.
7) Verify ownership through an independent channel
Registration records can show the registrar, registry status, nameservers, important dates, and sometimes an organization. Privacy services and redaction are common, so a hidden registrant is not proof of abuse. Use records as one part of the check.
Compare the .link name with:
- a link published on the organization's known official site;
- the domain in its verified social profile or app-store listing;
- documentation inside an authenticated account;
- a known phone number or email address obtained independently;
- registration dates and nameserver history that fit the claimed service.
A newly registered domain can belong to a genuine launch. It also deserves more verification when it appears in an unexpected urgent message. An old registration date does not prove that the current page or redirect is safe; ownership, hosting, and content can change.
Do not phone the number printed on the suspicious page or reply to its sender for confirmation. That keeps the verification inside the same untrusted channel.
8) Treat HTTPS as transport protection
HTTPS protects data in transit between the browser and the host named in the certificate. A valid certificate helps prevent passive interception and tampering on that connection.
It does not prove that the operator is honest, that a redirect destination is appropriate, or that a login form belongs to the claimed brand. Automated certificate issuance is widely available. A deceptive site can use HTTPS, and a legitimate site with a broken certificate can still be misconfigured rather than malicious.
Use HTTPS as a minimum technical requirement, not a trust badge. If the browser reports a certificate error, stop. If the padlock is present, continue checking the host, ownership, context, and action.
The same distinction applies to visual polish. A copied logo, accurate colours, privacy-policy link, or professional design can be reproduced. Brand appearance is weaker evidence than an independently confirmed domain.
9) Keep price separate from safety
Low registration cost does not make a domain suspicious, and a high price does not make it trustworthy. Price matters to an owner choosing a branded redirect, but it is not a visitor safety signal.
Official registrar pages showed these standard non-premium .link scenarios on 16 August 2026:
| Registrar snapshot | First year | Renewal | Displayed three-year cost |
|---|---|---|---|
| Porkbun | $7.72 | $7.72 | $23.16 calculated |
| Namecheap | $4.48 sale | $11.98 | $22.44 |
Porkbun listed registration, renewal, and transfer at $7.72, with fees included. Its three-year arithmetic is 3 × $7.72 = $23.16.
Namecheap displayed a $4.48 first-year sale, an $8.98 reference registration price, $11.98 renewal, $8.98 transfer, and $22.44 for three years. Its page said a $0.20 ICANN fee may apply. Premium names, taxes, eligibility, promotion limits, and checkout can change the result.
An owner should save a dated quote and check renewal before launch. A visitor should ignore price speculation and verify the exact operator.
10) Build a safer branded redirect
Owning a concise .link name creates a responsibility to make every hop explainable. A safe redirect service should not accept arbitrary destinations from public URL parameters.
For example, avoid a pattern that forwards go.example.link/?url=anything. OWASP's guidance supports safer designs based on server-side mappings or allowlisted destinations. A short identifier such as /spring-report should resolve through a controlled record, not through an unchecked visitor-supplied URL.
Use these controls:
- keep the brand or project name visible in the registered host;
- use readable, stable paths when exposure permits;
- map short IDs to approved destinations on the server;
- allowlist hosts and schemes, and reject unexpected ports or credentials;
- show an interstitial warning before an external destination when appropriate;
- prevent nested redirects and test every hop;
- provide an abuse contact and a fast disable switch;
- expire campaign links deliberately rather than reassigning paths silently;
- log changes, destination history, and the staff account that approved them;
- protect the registrar, DNS, and redirect service with strong authentication;
- monitor for certificate, DNS, content, and destination changes.
Do not imitate another brand in the hostname or path. Publish the .link address on the main official site so recipients have an independent way to confirm it.
11) Act quickly after a harmful click
If you opened a suspicious page but entered nothing, close it, cancel unexpected downloads, update security software, and follow the device or workplace incident process. Check whether the browser downloaded a file and do not open it.
If you entered a password, change it from a clean device through the real service. Change any reused passwords, sign out other sessions, review recovery details, and enable phishing-resistant multi-factor authentication where available.
If you disclosed a card or bank detail, contact the provider through a trusted number and monitor transactions. If you shared a recovery code, API key, wallet approval, identity document, or workplace credential, use the relevant revocation and incident process immediately.
The FTC directs US consumers who disclosed information to IdentityTheft.gov and provides a phishing-reporting route. Readers elsewhere should use their national cybercrime, consumer-protection, bank, and service-provider channels.
For the next link, use this decision rule:
- expected sender and context;
- exact host verified;
- destination confirmed independently;
- no sensitive action through an unverified redirect;
- HTTPS valid but not treated as identity proof;
- ownership and purpose consistent;
- no unresolved warning sign.
One failed check is enough to stop. You do not need to prove that a URL is malicious before declining to use it.