A banned member is not a locked-out member. Discord removes the account from your server, not the person behind it. A new email address takes a couple of minutes, and the account that walks back in looks exactly like any other new join: no roles, no history, an avatar and a name. Everything a moderator can see says “new member” while the person behind it already knows your rules, your staff and your channels.
This guide covers what actually distinguishes an alt from a genuine new member, where most server-side setups get it wrong, and the order of operations that stops a raid instead of cleaning up after one.
Why a ban doesn’t stop an alt
Discord’s ban is scoped to an account and a server, so it has no knowledge of a second account on the same phone. Nothing about a fresh account is suspicious on its own, which is why detection has to compare the new join against what you already recorded about the people you removed. If you banned someone and kept no signals, there is nothing to compare with and the alt arrives invisible.
The gap is timing, too. Most raids are not fifty accounts at once; they are three or four accounts joining over an hour, dropping invite links and slurs, then leaving. By the time a moderator reacts, the accounts are gone and the damage is in your channels.
The three signals worth comparing around a ban
A reliable alt check compares the joining account with your ban list across independent signals. One signal is a guess; three that agree is a case.
- Device signatures. Browser and client details such as platform, screen metrics, fonts, timezone and language. Two accounts that agree on all of these are usually the same machine, even when the IP changed.
- IP intelligence. The address a member connects from, checked against VPN, proxy and hosting ranges so you can tell a residential connection from a datacentre one.
- Discord OAuth2 identity. A one-click verification that returns the account’s own identifier and creation date. Free and trivially made, but useful because it ties a verification record to a specific account instead of to whatever someone typed.
Age and history matter as much as the signals. An account created days ago, joining through a vanity invite at 3am, with no mutual servers, is a different risk from a two-year-old account. Weight the pattern, not one field.
Where anti-alt setups fail
The most common failure is banning on IP alone. Mobile carriers put thousands of unrelated people behind one address, and households share a router. A rule that bans on IP will eventually remove a family, an office or a whole campus network — and those are the reports that cost a server its reputation.
The second is ignoring VPNs entirely. A determined ban evader will not hide well, but a casual one using a free VPN will look like a new country every join. Treat a proxy as a reason to look harder, not as proof.
The third is verifying after access. If new members can read and post the moment they join and verification follows later, every alt gets its window. Verification has to gate the channels, not excuse them.
Check at the door, not after
The workable shape is: join, land in a holding state with no access to your channels, verify once through Discord, then receive the roles you chose. Cursor calls that holding state detainment. A member who passes is let through in one click; a member whose signals match someone on your ban list stays detained with the match shown to staff, including which signals agreed.
Because the check happens before access, an alt never reaches a channel. It also means a raid of new accounts is a queue of detainees rather than a queue of deleted messages.
What to do with a probable match
Separate the decision from the detection. A strong match — device and IP together, or device across several accounts — is a ban. A weak match is a conversation: ask a question only the original member would answer, or confirm in a ticket. Keep a short note on every ban you make, because the note is what makes the next match meaningful. Members do get caught wrongly when a sibling shares a laptop; an appeal path with a staff member on the other end is what keeps that from becoming a public complaint.
Restoring members afterwards
The scenario nobody plans for is losing the server itself. A compromised owner account, a mass report raid, a server wrongly terminated — and every verified member is gone at once. Keep a verified member list that is independent of the server, so a new server can be rebuilt and your verified members restored to it in bulk instead of asking thousands of people to rejoin by hand.
A checklist for this week
- Put new joins in a holding role with no channel access.
- Record at least device and IP signals for everyone who passes verification.
- Compare every new join against your ban list before granting roles.
- Stop banning on IP alone; require a second signal to agree.
- Write one line on why each ban was made.
- Export your verified member list somewhere you control.
- Test the whole flow yourself with a spare account.
Cursor does the first four automatically once it’s in your server and you’ve picked the role verified members receive. Add Cursor to Discord to set it up, or read what data verification collects first.