Domains and links
How the allowlist exempts a domain completely, what it does not exempt, and how to build a list without breaking your server.
Links are where most real attacks live, so this is the part of your configuration worth getting right first.
The allowlist exempts, completely
A domain on your allowlist is removed from the message before anything scores it. Not skipped by the link checker, not scored and then forgiven: removed. Nothing else in the engine ever sees it.
That matters more than it sounds. Rules match text, and a domain you approved is text. Without this, a pattern written to catch disguised links could match part of a legitimate domain, and no amount of allowlisting would stop it, because the allowlist and the rule were looking at different things.
Two consequences worth knowing:
Only the link is exempt, not the message around it. "Send me your seed phrase, details at yoursite.example" is still caught on the sentence. If allowlisting a domain exempted everything near it, appending an approved link would switch off every rule you have.
Blocking always wins. A domain on both lists is blocked. An allow entry is usually older configuration nobody cleaned up, and between the two readings, the safer one is the one that keeps blocking.
Enter a domain, not a URL
The field wants a host:
onvanar.com
Pasting the whole address from your browser also works. It is trimmed to the
host on save, so https://onvanar.com/some/page and onvanar.com end up
identical.
Subdomains are included by default, so allowing example.com also allows
help.example.com. It never allows example.com.attacker.net, which is a
different domain wearing a familiar prefix and is exactly the trick that makes
naive matching dangerous. Subdomain coverage is a single switch for the whole
allowlist on the Links page; turn it off and every entry there requires an exact
host. Domain rules carry their own per-rule version of the same setting.
Blocking is deliberately broader than allowing: blocking a domain always covers its subdomains, because whoever controls a domain controls those too.
Choosing a link policy
Allow everything except what you block. The default, and right for most communities. Links flow; the blocklist and the detectors handle the rest.
Block everything except what you allow. Strict, and genuinely appropriate for an announcement-only or support server. Be aware of what it means in practice: every link anybody posts that you have not approved is a high-severity event, so your allowlist has to carry the domains your community legitimately uses. Build it in monitor mode first and watch what your members actually post.
Block every link. Means what it says, and outranks the allowlist. A blanket control whose label was quietly untrue would be discovered during the incident it was meant for, so this one is absolute.
Building an allowlist without breaking your server
Run in monitor mode for a few days with logging turned up, then read the log for the domains your members post normally. That list is your allowlist. Adding it from memory produces a list that matches what you think your community links to, which is never quite what it does.
Lookalikes
Domains you have approved do a second job: they become the reference set for spotting imitations. A host that is one character away from something you trust is more suspicious than an unfamiliar host, precisely because it is trying to be one of yours.
Allowlisting a domain is enough. If you want the comparison to use a different set, fill in Protected domains on the Links page, under "Look-alike domain", and that list is used instead. Domain rules set to allow are always included.
This never flags the trusted domain itself, or its subdomains. An allowlisted
link is removed from the message before anything scores it, and the comparison
works on the registrable domain, so docs.example.com is recognised as part of
example.com rather than as something imitating it.
What it does flag is the same name on a different ending: with example.com
trusted, example.xyz reads as an imitation, because in a Discord message it
usually is. If your project genuinely owns several, allowlist all of them. An
allowlisted domain joins the reference set instead of being measured against it.
That is a reason to allowlist your own project's domain even in a server that allows all links.
Shorteners
A shortened link is a destination you cannot see, which is most of why they are used in scams. Wardnox ships a list of the well-known services, and you can edit it freely: treat it as a starting point rather than a complete list, because anybody can run one.
There are four things it can do with them:
- Allow. Treat a shortener as an ordinary link.
- Treat as suspicious. The default. Being shortened counts as evidence in itself, without blocking anything on its own.
- Block. No shortened links at all. Defensible in a server where nobody has a reason to post one.
- Follow it and check where it goes. The strongest option, and the one with a condition attached: following links is a capability that has to be switched on for the whole service, not only in your settings, because it means Wardnox makes a request to somewhere a member chose. It stops after a set number of hops and gives up rather than hanging.
If you have no strong feeling, leave it on suspicious. A shortener is worth noticing and is rarely worth acting on alone.
Invites
Invites to other servers are handled separately from ordinary links, because they are ordinary in some communities and the main scam vector in others. There are five choices: allow them all, allow only invites back to your own server, allow only invites to servers you name, block them all, or watch without acting. The default is invites to your own server only.
Whatever you choose, an invite disguised to avoid detection is treated as evidence in itself. Nobody spaces out an invite link they are allowed to post.