Discord verification for universities and schools¶
A university Discord fills up fast, and not everyone who joins belongs there. Course servers get outsiders looking for coursework, society servers get spam accounts, and department servers end up with alumni, applicants and strangers mixed in with actual members — with no way to tell them apart.
Email verification fixes that at the door: a member only gets a role once they've proven they receive mail at your institution's domain.
Who this is for¶
- Course and module servers — only enrolled students, no lurkers from other cohorts.
- Department and faculty servers — students and staff separated automatically by their address.
- Societies, clubs and student unions — membership limited to the institution.
- Applicant and open-day servers — a fixed allowlist of invited addresses instead of a domain.
- Alumni networks — a CSV of known addresses, since alumni rarely share a live domain.
Setting it up for a university¶
Allowed domains support wildcards, which matters because universities almost never use a single flat domain.
Accepts any US university address. For a specific institution, or one outside the .edu system:
You can add as many as you like — a joint programme across two universities just gets both domains.
Split students from staff automatically¶
Most institutions issue students and staff addresses on different subdomains. Map each one to its own role and the sorting happens by itself:
/domainrole add domain:@students.university.edu role:@Student
/domainrole add domain:@staff.university.edu role:@Faculty
/domainrole add domain:@alumni.university.edu role:@Alumni
Members receive the domain-specific role plus whatever default role you set with /role add. No manual role handing-out, and no admin having to judge whether a screenshot of a student card is real.
Make verification mandatory¶
The first gives every new arrival an "Unverified" role — deny that role access to your channels and unverified members simply can't read anything. The second prompts them to verify the moment they join, rather than hoping they find the button.
Semester spikes¶
Verification traffic at a university is not spread evenly across the year. It's near zero for months and then several hundred people arrive in the first fortnight of term.
The free tier covers 25 verification emails per server per month, which is enough for a small society year-round but not for an intake week. Two ways to handle the spike:
- Credit packs — one-time purchase, never expire, roll over month to month. A 500-pack bought before September can cover a whole intake and still have credits left in the spring.
- Standard subscription — unlimited sends, sensible if you run several large servers or verify continuously.
You'll get warnings at 80% and 95% of the free quota with a run-out forecast, so the cap never arrives as a surprise mid-intake.
Deliverability at universities¶
This deserves its own warning: university mail filters are the most aggressive you'll encounter. A verification code from an unfamiliar sender is exactly the shape of thing they quarantine.
Always run /testmail against an address at your own institution before you announce the server:
If it lands in junk, paid plans route mail through Zoho ZeptoMail — EU-hosted and transactional-only, so no marketing senders share its IP reputation. That difference is usually what gets codes into university inboxes reliably.
If your IT department will do it, asking them to allowlist the sending domain is the most robust fix of all.
Data protection¶
Student email addresses are personal data, and a Discord bot holding a plaintext list of them is a genuine liability for whoever set it up.
- Addresses are stored as cryptographic hashes only. Plaintext exists just long enough to send the code and is never written to disk.
- Members can erase themselves with
/data delete-user, which also removes their verified status. - Admins can wipe the server's whole record with
/data delete-server. - Mail for paying servers stays in the EU (Zoho ZeptoMail, EU data residency).
- The source is auditable — AGPL-3.0, so your IT department can read exactly what it does, or host it themselves.
Full details in the privacy policy.
If your institution needs a formal agreement
Departments procuring a tool officially usually need a data processing agreement rather than a click-through. Self-hosting sidesteps the question entirely — the Docker image is public and no data ever leaves your infrastructure. For anything else, ask in the support server.
What this does and doesn't prove¶
Worth being precise about, because it changes how you should use it.
It proves the person controls a mailbox at your institution's domain, right now.
It does not prove they are currently enrolled. Most universities let graduates keep their address indefinitely, so a @*.edu gate will let alumni through. If current enrolment is what you actually need, use a CSV allowlist of this year's registered students instead of a domain rule — see courses and events for how that works.
Related¶
- Quick start guide — three steps, with a 60-second video
- How EmailVerify compares to other verification bots
- Companies and teams — the same thing for a corporate domain
- Courses, events and hackathons — fixed allowlists instead of domains