Verifying academic affiliation since 2020

.edu email vs university SSO for student verification

A .edu email check is fast but weak. Compare it with university SSO for correctness, global coverage and fraud resistance — and when each is good enough.

Short answer

A .edu email check is fast and cheap, but it proves an email domain, not current enrollment. University SSO is signed by the institution and works globally. Use an email check only for low-stakes gates; use SSO when the decision matters.

Read the integration guide

Last updated September 13, 2026

70+
Federations: 6,365
Institutions: None
User data stored: 6 yrs
Verifying academics

Powers verification for teams at

Proves current affiliation

Institution-signed and current as of login — not just an email domain.

Global by default

eduGAIN reaches thousands of institutions across 70+ federations, well beyond .edu.

Hard to game

No forwarded addresses, no alumni inboxes, no borrowed accounts.

.edu email vs university SSO

Criterion	`.edu` email check	University SSO (Studid)
What it proves	The domain of an address	✅ The institution vouches for the user
Current enrollment	❌ No	✅ Yes, as of login
Global coverage	❌ US-centric	✅ eduGAIN: thousands of institutions, 70+ federations
Role (student/faculty)	❌ No	⚠️ Sometimes, when released
Fraud difficulty	❌ Low — easy to game	✅ High — institution-signed
Friction	✅ Very low	⚠️ One redirect and a login
Cost	✅ Trivial to add	✅ Free API; no per-check fee
Best for	Low-stakes gates	Eligibility, access and trust decisions

See the check an email domain cannot give you

Institution-signed, current as of login, and global. Run a real academic login and compare it with a domain match.

Read the integration guide

The whole integration

The check that proves affiliation, not a domain — two calls:

# 1. Create a verification → returns { id, link }
curl -X POST https://api.studid.io/v2/auth/verification \
  -H 'Content-Type: application/json' \
  -d '{"secretToken":"YOUR_TOKEN","redirectUrl":"https://yourapp.com/callback","serviceName":"My App"}'

# 2. Redirect the user to `link`, then poll for the result
curl https://api.studid.io/v2/auth/verification/{id} \
  -H 'Authorization: Bearer YOUR_TOKEN'

When an email check is fine

A low-value perk where occasional false positives are acceptable.
An initial signal before a stronger check, if you treat it as a hint rather than proof.
Users with no institutional login at all, as a last resort.

If the gate protects a real benefit, access to data, or trust in your platform, an email domain is not enough. The question is not "is a domain check bad?", but "what happens when it is wrong?" If the answer is "nothing much," keep it. If the answer is "a paying customer's discount, a seat in a program, or access to data," it is the wrong tool.

Who should choose which

Choose a .edu / domain check if:

The gate is low-stakes and occasional false positives are tolerable.
You want near-zero friction and are willing to accept weak proof.
Your audience is US-only and every institution you care about uses a recognizable domain.
You are layering it as a hint before a stronger check, never as the final decision.

Choose university SSO if:

The decision is consequential — discounts, paid programs, data access, account trust.
You need current affiliation, not an address that may have survived graduation.
Your audience is international, so a .edu assumption excludes many legitimate users.
You want a result the institution itself signs, rather than one you infer.

The full comparison

What a domain check actually proves

Checking that an address ends in .edu — or matches a known university domain — is a useful signal and nothing more. The failure modes are well known:

Alumni keep their addresses. A graduate with a still-active .edu inbox passes forever.
Addresses can be forwarded or borrowed. Control of an address is not proof of affiliation.
.edu is US-centric. Most institutions outside the United States never used it, so a domain check silently excludes much of the world.
No role information. You cannot tell a student from staff, faculty or an alumnus.
No revocation. When someone leaves the institution, a domain check does not know.

An email loop (send a code to the address) narrows this a little by proving control, but it does not fix the underlying problem: affiliation is not the same as an email domain.

How to move from a domain check to SSO

You can adopt SSO without a rewrite, because it answers the same boolean your domain check approximates:

Keep the domain check as a fast pre-filter if you like, but stop using it as the final answer.
Add the two calls. Create a verification, redirect the user to the returned link, poll until session is populated.
Map the result. Treat entityId as proof of affiliation. If authIdentifier is present, use it as a stable per-user key; if it is null, bind the result to your own session token.
Handle the affiliations gap. Because Studid is not a REFEDS R&S entity, affiliations is often empty. That is expected and not a failed login — do not gate on it.

If you gate a research or platform feature rather than a consumer perk, the research platforms use case covers the same integration.

The hybrid pattern that works

The most robust setups keep both methods but give them different jobs:

SSO first for everyone who has an institutional login — the large majority, and the only path that is institution-signed.
Email loop or documents for the minority who genuinely have no institutional identity provider: applicants, incoming students, homeschool or unaffiliated learners.
Domain checks only as telemetry, never as the gate.

This keeps the happy path fast and authoritative while preserving an escape hatch for edge cases, so you never turn away a legitimate user just because their institution does not fit a US-centric pattern.

Auditing the check you already have

If you already gate on an email domain, the fastest way to see the gap is to run your current logic against a few real cases:

A recent graduate whose address is still active. A domain check passes; SSO reflects what the institution actually vouches for.
A forwarded address. A domain check sees the domain; SSO sees an authentication.
A non-US institution that never used .edu. A domain check silently rejects a legitimate user; SSO does not.
A staff member who should not get a student rate. A domain check cannot tell; affiliation attributes sometimes can.

Write down what your product should do in each case. If the answers are acceptable for a domain check, keep it. If they are not, the gap is the reason to adopt SSO — not a general preference for newer technology.

An evaluation checklist. Before switching, confirm:

What current enrollment proof does the decision actually require?
How many of your users are outside the US, where .edu does not apply?
Do you need role information (student vs staff vs faculty)?
What should happen when you can revoke access after someone leaves?
Can you run SSO alongside the domain check during a transition?

What a domain check is still good for

An email domain is not worthless; it is just easy to over-trust. Used deliberately, it earns a place:

A cheap first pass that filters obvious noise before a stronger check.
A routing hint that decides which verification path to offer, not whether to grant access.
Internal triage for support or marketing, where a wrong answer is cheap to correct.

What it should never be is the final authority on a benefit, a seat or a data grant. The distinction to keep clear is between a signal and a decision: a domain is a fine signal and a poor decision.

Three checks, ranked

It helps to line up the options rather than treat them as one choice:

A domain check answers "does this address look academic?" It is nearly free, nearly frictionless, and nearly meaningless on its own. Use it as a filter, never a decision.
An email loop answers "does this person control an address at that domain?" It adds a real verification step and blocks casual typos and dead addresses, but it still cannot separate a current student from an alumnus, and it fails for institutions without a recognizable domain.
University SSO answers "does the institution vouch for this person right now?" It is the only option that produces an institution-signed, current assertion, and it works across federations rather than only where .edu applies.

The ranking is not about sophistication; it is about what each can prove. Move up the list only as far as the value of the decision requires — and no further, because each step adds friction.

Verify these claims yourself

Try a real institutional login in the live demo.
See the global coverage on the network page.
Read the full field list — including why affiliations is often empty — in the integration guide.

Methodology: This page compares verification methods generally, based on Studid's own implementation and public identity-verification practice as of September 2026.

Frequently asked questions

Is checking a .edu email address good enough?

It depends on the stakes. A domain check is trivial to add and adds friction for almost nobody, but it proves nothing about current enrollment: alumni keep addresses, mail can be forwarded, and many international institutions do not use .edu at all. For anything of value, it is easy to game.

Why not just send a verification email?

An email loop confirms control of an address, not affiliation. It is better than a bare domain check, but it still cannot tell a current student from an alumnus, and it does not work when the institution does not use a recognizable domain.

Does SSO work outside the United States?

Yes. Studid verifies through eduGAIN-participating federations, which cover institutions worldwide — including the many countries that never used .edu addresses.

Can SSO tell us the user's role?

Sometimes. When an institution releases affiliation attributes you will see student, staff or faculty values. Studid is not a REFEDS R&S entity, so those are often empty — but the institution itself is always identified via entityId.

How much does SSO verification cost?

With Studid, nothing — no account, no API key, no per-verification fee.

Can we keep the email check and add SSO only for high-value users?

Yes, and it is a common pattern. Use the email domain as a low-stakes filter or an initial hint, then require SSO before granting anything valuable.

What if an institution uses a student email domain but has no SSO?

Then SSO cannot cover that user, and a document or manual fallback is the honest option. The hybrid pattern on this page keeps that path available without making it the default.

You are one redirect from a signed affiliation

Authenticate with a real university or research institute and see the institution-verified result immediately.

Read the guide