Currently accepting clients
securityimpersonationmoderationtrustsupport

How to Stop Discord Impersonation Scams Before They Reach Your Members

Faster takedowns do not fix impersonation. Verifiable staff identity, one link source, and a standing promise remove the conditions the attack depends on.

Daniel Jeong
Daniel Jeong
Author
September 4, 2026
6 min read
How to Stop Discord Impersonation Scams Before They Reach Your Members
How to stop Discord impersonation scams: make your team verifiable rather than chasing takedowns. A distinct staff role, a pinned roster with exact usernames, one locked channel that is the only source of links, a standing promise that staff never message first, and name similarity checks at the door.

What the attack looks like from the member's side

A member posts a question in a support channel. Within a few minutes, a direct message arrives from an account with the same display name as your support lead, the same avatar, and a helpful tone. It offers to sort the problem privately. It asks for a login, a payment, or a recovery phrase. The member has no way to check. Your support lead's exact username is not published anywhere they can find quickly, the profile looks correct, and the message arrived immediately after they posted, which reads as attentive service rather than surveillance. This is the failure. The member is not careless. They were given nothing to verify against.

The symptoms that mean it is already happening

Four signs, in the order they usually appear:

  • Members apologising in public for a mistake you have not heard about yet
  • Questions in general chat asking whether a particular account is really staff
  • A rise in joins from accounts created within the last month, clustering after your busy posts
  • Long time members quietly turning off direct messages from server members That last one is the expensive symptom. It means people have stopped trusting the room, and closed direct messages also close the private support channel you rely on.

Why deleting the fakes does not work

Banning an impersonator takes about a minute. Creating a new one takes about the same, and the attacker can do it repeatedly while your moderators sleep. More importantly, every takedown happens after contact. The member has already been messaged by the time you act. A defence that only operates after the attempt is not a defence, it is cleanup.

The goal is not to make impersonation impossible. It is to make it useless, by giving every member a ten second way to check.

Fix one: three places to verify identity

Staff identity has to be checkable in three fixed locations, and every member has to know all three exist.

  1. A distinct staff role, displayed separately in the member list, held by nobody who is not staff. Not a colour on a general role, a separate visible group.
  2. A pinned roster in a locked channel listing exact usernames, not display names, because display names are the thing being copied.
  3. A line in the server description saying where the roster lives, so someone who arrived thirty seconds ago can still find it. The reason for three rather than one is that impersonators attack whichever single proof you rely on. Three independent checks cannot all be faked at once by an account with no permissions.

Fix two: one source for links

Create a single locked channel that is the only place your team ever posts links. Announcements, launches, forms, payment pages, everything. Then state the corollary plainly: any link that appears anywhere else is unverified, including a link that appears to come from staff. This is the rule that protects members during a launch, which is precisely when impersonators arrive, because that is when unusual links are expected.

⚠️ The rule only works if your own team follows it without exception. One convenient link dropped into general chat by a real staff member teaches everyone that links can appear anywhere.

Fix three: the standing promise

One sentence, repeated until it is boring: We will never message you first, and we will never ask for a password, a recovery phrase, or a payment in a direct message. Put it in the onboarding sequence, in the rules, in the pinned roster, and repeat it after every incident. The promise is only useful if it is known before the attack, which means repetition is the whole mechanism. It also imposes a discipline on your own team, which is the hidden benefit. If staff genuinely never initiate direct messages, then every unsolicited message claiming to be staff is provably fake, with no judgement call required from the member.

Fix four: friction at the door

Three settings, all of which cost you a small number of legitimate joins and are worth it:

  • A minimum account age for posting or messaging
  • A verification requirement before a new account can send direct messages to members
  • A watch list of usernames that closely resemble your team's, flagged for review rather than auto-approved That third one is the highest value and the least common. Names one character off a moderator's name are not coincidences, and a flag on join gives you the chance to act before contact rather than after.

Fix five: a ten second report path

Members report what is easy to report. If reporting requires finding a moderator, explaining the situation, and waiting, most people will simply block and move on, and you will never learn the attack happened. Make it one obvious action in one obvious place, and give moderators a single written response line so the reply is identical regardless of who is on shift. Consistency here matters more than speed, because an inconsistent response makes members unsure which reply was the real one.

The first hour of an incident

When a member reports being messaged, the order is: confirm the account is fake using the roster, ban and report it, post a short public notice naming the tactic, and repeat the standing promise. Then check whether anyone else received the same message. The public notice is the part teams avoid because it feels like admitting a problem. It is the part that prevents the next twenty attempts, because members who read it will not be surprised the next time.

What this does not cover

Identity defence is one layer of a safety system. Around it sit the automated gate that handles volume at the door, moderator staffing and coverage across time zones, escalation design for incidents that need someone senior, and the incident log that turns individual events into a pattern you can act on. What this layer does is remove the conditions the attack depends on. An impersonator needs a member who cannot check. Give every member three ways to check and one place where links live, and the attempt stops paying for itself.

Trust is not a feeling in a community, it is a set of things a member can verify quickly. Build those. More at danieljeong.org.