Skip to main content

Link Safety

Cloud Feature

Abuse review, workspace restriction, and appeals are Cloud-only. Self-hosted Core deployments include the underlying link states but none of the enforcement or review process described here. See Cloud vs Self-Hosted for details.

Short links are useful because they hide their destination. That is also why they attract abuse, and why every link shortener has to take it seriously.

A shared link domain carries one reputation for everyone on it. When a phishing campaign runs on go.linkforty.com, mail providers and browsers do not distinguish that campaign from your product launch — they see the domain. So enforcement is not only about the customer being abused; it protects every other workspace's deliverability.

This page explains what enforcement looks like from the outside, and what to do if it lands on you.

Your own domain, your own reputation

A custom domain carries only your reputation. It is the single best protection against someone else's behaviour affecting your links.

A link that exists is in one of three states:

StateWhat a visitor sees
AllowThe normal redirect. Nothing changes.
WarnAn interstitial page showing the full destination, with a Continue anyway link they must click
BlockA 404, identical to a short code that was never created

Warn is deliberately not a block. It applies to a link that is suspected rather than confirmed. A false positive still lets the visitor through, while a genuine malicious link loses the one-click flow it depends on. The interstitial also offers a way to report the link.

The states have a fixed precedence. A restricted owner outranks everything, then an inactive link, then a warning. A link whose owner is restricted is unreachable even if it was only flagged to warn.

This is intentional and worth understanding before you file a bug about it.

A distinct "this link was disabled" page would confirm to whoever is probing that the code was real, and would leak that its owner is under a restriction. Both are useful to an abuser and to nobody else. So a blocked link returns exactly what an unknown code returns.

The same is true for expired links — an expired link is inactive, and inactive means blocked.

Destinations Are Checked When You Save​

Some destinations are not permitted. When you save a link pointing at one, the link is not saved and the response names the URL that was refused.

This applies whenever a destination is written — creating a link or editing an existing one — and on every route: the dashboard, the API, the MCP server, templates, and links your app creates through the SDK.

If a destination you control is refused and you believe that is wrong, contact support with the URL. Do not work around it by encoding it differently or redirecting through another host; that reads as evasion and will be treated as such.

Workspace Restriction​

When a workspace is restricted, its links stop resolving and it is queued for human review.

Restriction is reversible. It is a hold pending review, not a deletion, and nothing is destroyed while it is in place.

What You Can Still Do​

A restricted workspace is not locked out. You can still sign in — deliberately, because the restriction notice, your data, and the appeal form are only reachable from inside a session.

  • Read and export all of your data. Analytics and link history remain available to export for as long as the restriction lasts.
  • Read the statement of reasons. The notice names what was actioned rather than saying "contact support", so you can recognise the cause.
  • Appeal, and have a person read it.
  • Use your other workspaces. Restriction applies to one workspace. If you belong to others, they are unaffected and the notice links you to them.

Why a Legitimate Workspace Gets Restricted​

The most common cause is not malice. It is a destination that stopped being yours:

  • A page on your site was compromised and now serves something else.
  • A destination host expired and was re-registered by someone else.
  • A typo'd or copy-pasted URL points somewhere you never intended.
  • A shortened link from another service was used as a destination, and its target changed.

This is exactly why the notice names the specific destination. Check that URL first — in a large fraction of cases the finding is correct and something on your side has changed without you noticing.

Appealing​

The appeal form is on the restriction notice itself. Describe why you believe the restriction is wrong; that is the only required field. If you are signed in, we already know which workspace you are writing about.

A person reviews every appeal. Include anything that helps:

  • What the destination is, and what it is for
  • What changed, if a destination was compromised and you have since fixed it
  • Any context about your business that would not be obvious from the link alone

Appeals are rate-limited. Submitting the same appeal repeatedly does not move it up the queue.

If you have received a LinkForty link that looks like phishing, malware, or spam, report it at app.linkforty.com/abuse. No account is needed.

You will be asked for:

FieldRequired
The URLYes
A category — phishing, malware, spam, IP infringement, or otherDefaults to other
Any detail you can giveOptional
Your email, if you want a replyOptional

Reports are rate-limited per network address, generously — a duplicate report is much better than a dropped one.

The warning interstitial also carries a report link, so a link that made you suspicious can be reported from the page itself.

Work through these in order:

  1. Check whether it expired. An expiration date makes a link behave exactly like a blocked one. See Link Settings.
  2. Check whether the link is still active in your dashboard.
  3. Check the destination. Open it directly. If it redirects somewhere unexpected, that is very likely the cause.
  4. Check for a restriction notice. Sign in — if the workspace is restricted, you will land on the notice with the specific finding.
  5. Appeal or contact support, depending on which of the above applies.