You make someone react to rules before joining Discord by enabling Rules Screening in Server Settings > Safety Setup, which forces every new member to click through your server rules and accept them before they can send messages or see channels. Discord calls this Membership Screening; members must react by clicking the accept button, and you can require them to read a full rules page first. The gate applies to humans joining through invites, but it does not stop bots added by admins, and it does not verify that anyone actually read the rules.
That single mechanism is the foundation. Everything below explains why it works, where it fails, how it differs from reaction roles, and what thresholds actually control member behavior.
How the rules screening gate actually works
Discord's membership screening inserts a mandatory interstitial between accepting an invite and gaining full server access. The new member sees your rules text in a modal-style page, then must press a button labeled with your chosen action (Discord defaults to something like "I agree" or "Accept Rules"). Until that click registers, the member is placed in a pending state with restricted permissions.
The restriction is not cosmetic. Pending members cannot send messages in text channels, cannot join voice channels, and cannot react to messages. They can typically still read channels your role permissions allow, depending on how you configure the "pending" role defaults. This is the mechanical reason screening works as a gate: the accept action is the only path from pending to member.
The reaction itself is stored server-side as a completed screening event on that account for that server. Once a member passes screening, they are not asked again unless they leave and rejoin. Rejoining after leaving triggers screening anew, which is a detail many server owners miss when they assume a banned-then-rejoined raider is permanently filtered.
Platform support matters. Membership screening is available on desktop, web, iOS, and Android, so the gate is not bypassable by using a different client. However, the rules text you write has a character ceiling, and overly long rules pages get truncated or require scrolling, which changes how much a member actually sees before pressing accept.
Plain language: the gate is a permission checkpoint disguised as a consent page, and the accept button is the key.
Quantified context: what the gate changes in practice
Treat these as ranges to design around, not guarantees. Discord does not publish granular screening analytics, and outcomes vary enormously by server size and audience.
The gate's clearest quantified effect is on friction. Every additional required step between invite click and first message reduces conversion. A server that converts 60% of raw invite clicks into active members without screening might convert 40-50% with screening enabled, because some fraction of casual joiners abandon at the rules page. That trade is usually worth it for community servers and usually not worth it for high-volume public hubs.
Time-to-first-message also rises. Without screening, a motivated member can post within seconds of joining. With screening, add the reading and clicking time, typically 10-40 seconds for a short rules page and longer for verbose ones. Servers with rules longer than roughly 1,500-2,000 characters see noticeably more abandonment because the page requires scrolling on mobile.
The gate does not scale linearly with rules length. A 300-character rules page and a 1,200-character page filter roughly similar numbers of bad actors, because determined raiders will click anything. The marginal value of the 1,201st character is close to zero for security and slightly negative for conversion.
Counterintuitive detail: screening is weakest precisely where owners expect it to be strongest. A raid bot or self-bot that automates the join flow can also automate the accept click, so screening filters lazy human trolls and casual rule-breakers far better than it filters organized raids. Against coordinated raids, screening buys you seconds, not immunity.
Timeline: what a new member experiences from invite to full access
| Step | What happens | Typical duration | Owner-visible signal |
|---|---|---|---|
| Invite accepted | Account joins server in pending state | Instant | Member appears in member list with restricted role |
| Rules page shown | Screening interstitial displays your rules text | 0-5 seconds to load | None specific |
| Member reads | Voluntary; no tracking of reading time | 5-40 seconds | None |
| Accept clicked | Screening event recorded, pending role removed | Instant | Member gains default role permissions |
| First message | Member can now post in permitted channels | Variable | Message appears in channel |
| Rejoin after leave | Screening repeats on next join | Instant | New pending state |
The table exposes the core limitation: Discord tracks the click, not comprehension. There is no reading-time threshold, no quiz, and no way to confirm the member scrolled to the bottom. Any "proof of reading" you want must come from a separate mechanism, such as a bot that asks a question with a correct answer drawn from the rules.
Reaction roles vs. rules screening: which gate to use
These are different tools that owners routinely conflate. Rules screening is a native consent gate. Reaction roles are bot-driven role assignment triggered by emoji reactions or button clicks. You can layer both, but they solve different problems.
| Mechanism | Who can configure it | What it proves | Bypass resistance | Best use |
|---|---|---|---|---|
| Native rules screening | Anyone with Manage Server | Member clicked accept | Low (bots can automate) | Baseline consent gate for all servers |
| Reaction role bot (button) | Bot with role permissions | Member clicked a specific button | Low-medium | Self-assigned roles, ping opt-ins |
| Reaction role bot (quiz) | Bot with message/role permissions | Member answered correctly | Medium | Rules comprehension for high-risk servers |
| Manual approval queue | Moderators | Human reviewed the account | High | Small, high-trust communities |
| Time-based gate (e.g., 10-minute wait) | Bot | Member waited | Medium | Anti-raid throttling |
| CAPTCHA-gated verification | Third-party bot | Member solved a challenge | Medium-high | Public servers facing bot raids |
| Role-gated channel access | Channel permissions | Member holds required role | Depends on role source | Segmented communities |
The comparison makes the layering logic clear. Screening is your floor, not your ceiling. On servers where rule violations carry real cost, pair screening with a quiz-style reaction role or a CAPTCHA bot, and keep a manual approval queue for the first 24-48 hours of any suspected raid.
Red-flag warnings to watch for:
Screening enabled but default role permissions still allow DMs to members or link embeds, letting filtered members cause harm anyway. Rules text that references channels the pending member cannot see, producing confusion and support tickets. A "verify" reaction role that grants a role with broader permissions than the screening default role, creating a privilege escalation path. Screening disabled during a raid "to speed up joins," which is exactly backwards. Rules pages copied verbatim from another server, including channel names and role names that do not exist in yours. Assuming a member who passed screening accepted your rules; they accepted the button.
Misconceptions that break the gate
The most common misconception is that screening equals agreement. It does not. A member who clicks accept has performed a required action, and Discord records that action, but nothing in the system captures whether they read a word. Enforcement still depends on moderators and on rules that are short enough to be plausible.
A second misconception is that screening stops bots. It stops naive bots that do not implement the click, and it stops nothing else. If your threat model includes automated raids, screening is a speed bump; CAPTCHA verification and invite hygiene (short-lived invites, invite tracking) do more work.
A third is that the pending state is fully locked down. Permissions in the pending state are governed by your server's default role and channel overrides, and misconfigured overrides can leave pending members able to read sensitive channels, react in them, or trigger integrations. Audit channel permissions for the default role after enabling screening, not before.
A professional caveat: many owners enable screening and then add a reaction role bot whose verification message lives in a channel the pending member cannot post in. The member can react (reactions are sometimes permitted even when messages are not, depending on overrides) but the bot's role grant may fail silently if the bot lacks hierarchy position. Test the full join flow with a throwaway account after every configuration change.
Plain language: the gate only does what its permissions allow, and permissions are where most servers actually fail.
Practical actions: configuring the gate so it holds
Start with the native gate, then harden it. The sequence below reflects what survives contact with real members and real raids.
Enable Membership Screening under Server Settings > Safety Setup, and write rules that fit in roughly 800-1,200 characters. Front-load the three rules that matter most, because mobile users see the first screen and little else. Audit the default role's channel permissions immediately after enabling screening. Pending members should not be able to read staff channels, post in any channel, or trigger bots that grant roles. Set your accept button label to something specific and legible, such as "I have read and agree to the rules," rather than a generic default. Specificity correlates with slightly better conversion and better moderator records. Layer a quiz-style verification on top for high-risk servers. A bot that asks one question whose answer appears verbatim in your rules filters automated joins and demonstrates comprehension in a way screening cannot. Keep invite hygiene tight: use invites with expiration and max-use limits, and rotate them after any raid. Screening does not compensate for a permanent public invite posted on a raid forum. Re-test the full join flow with a fresh account after any role, channel, or bot change. The most common failure is a bot whose role sits below the member role it needs to assign.
Thresholds to reconcile explicitly: Discord's rules text field, your default role permissions, and any bot's required role hierarchy position are three separate systems with three separate limits. Enabling screening satisfies none of the other two. Treat the join flow as a pipeline, verify each stage independently, and re-verify after every configuration change.
Limitations and what the gate cannot promise
Screening cannot verify reading, cannot stop determined automation, and cannot substitute for active moderation. Servers that rely on the gate alone and never review reports will still accumulate rule-breakers who clicked accept in under a second. The gate's real value is legal and social: it establishes a documented consent event and a clear behavioral expectation, which makes later moderation defensible.
The mechanism is also stable but not eternal. Discord has changed verification features before, and server owners should treat screening as one layer in a stack that includes invite control, role hygiene, bot verification, and human review. Build for the stack, not the single feature.
None of this is legal advice, and rules screening does not create a binding contract or guarantee that members will follow your terms. If your server collects personal data, hosts regulated content, or serves minors, consult a qualified local professional about consent and moderation obligations rather than relying on a platform checkbox. For immediate safety concerns involving a member, contact local emergency services rather than handling it through server configuration.