We ran 104 of the world's most prominent universities — from Harvard and Oxford to Tsinghua, KAIST, and the University of Cape Town — through NODA's dual-axis DNS scoring methodology: a Health score (does it work?) and a Best Practice score (is it done right?), evaluated across 41 checks spanning five categories — infrastructure, security, mail authentication, reliability, and operations.
The result is a genuinely interesting split-personality dataset. Higher education runs some of the oldest, most stable name-serving infrastructure on the internet — many of these institutions have held their domains since before the modern DNS existed. That maturity shows. What doesn't show is a matching maturity in security hygiene.
A note on scope: this list was compiled from established global-ranking and general-recognition sources, not pulled from one canonical index — treat it as a representative sample rather than an exhaustive census. All 104 domains were checked live on August 7, 2026; DNS configurations change, so numbers will drift over time.
The numbers
| Metric | Value |
|---|---|
| Domains scored | 104 |
| Average Health score | 94.5 / 100 |
| Average Best Practice score | 82.3 / 100 |
| Best Practice standard deviation | 8.23 |
| Best Practice range | 61 – 100 |
Health scores cluster tightly near the top — universities keep their DNS running. Best Practice scores spread out considerably more, and that gap between a tight Health distribution and a loose Best Practice one is itself the finding: uptime is a solved problem in this sector; hygiene is not.
DNSSEC: the surprise laggard
Only 24% of the universities we scored have DNSSEC enabled. That's a strikingly low number for a sector built almost entirely on federated trust — research collaboration, cross-institution identity federation, shared library systems — all of which depend on the same trust chain DNSSEC is designed to protect. Universities were early adopters of nearly every other piece of internet infrastructure. DNSSEC didn't make the list.
DNSSEC cryptographically signs DNS responses so a resolver can verify they haven't been tampered with in transit. Without it, an attacker positioned on the network path can forge DNS answers — silently redirecting visitors to a fake login page without ever touching the real server.
Mail authentication: the weakest category, across the board
Break the Best Practice score down by NODA's five scoring categories, and one category stands out as the consistent underperformer: CAT-MAIL, covering SPF, DKIM, and DMARC.
- DKIM Record: missing on 34.6% of domains
- DMARC Record: present but set to
p=none— monitor-only, no actual enforcement — on 45.2%. Only 28.8% have reachedp=reject. - SPF Record: present in most cases, but 18.3% flag warnings on policy strength
Meanwhile, infrastructure-layer checks — nameserver redundancy, glue records, SOA hygiene — pass at rates north of 95% almost across the board. The DNS works. The mail-security layer sitting on top of it is, for close to half these institutions, still in "we'll get to it" mode.
SPF, DKIM, and DMARC together let a receiving mail server verify a message actually came from the claimed domain. This isn't just an abstract security gap: Gmail and Yahoo's 2024 bulk-sender rules mean mail without DKIM increasingly lands in spam — a real deliverability problem for admissions offices, alumni relations, and any department that sends mail at volume, not just a compliance checkbox.
Single points of failure
37.9% of universities have all their nameservers announced from a single Autonomous System. For institutions this size, that's a real availability risk hiding behind a Health score that otherwise looks clean — a single upstream provider outage, not just a server failure, would be enough to take the whole domain off the map. It's exactly the kind of failure mode that doesn't show up until the day it does.
An Autonomous System (AS) is an independently-operated network — effectively, which provider actually owns the IP block your nameservers sit in. All nameservers in one AS means a single outage, BGP misconfiguration, or provider incident can take the whole domain offline at once. Caveat: this isn't automatically a problem if that AS belongs to a large anycast network like Cloudflare or Route 53, which are resilient by design — the real risk is a single small or non-anycast provider with no fallback.
Best and worst performers
Top 5 (Best Practice score):
| Domain | Best Practice | Health |
|---|---|---|
| polytechnique.edu | 100 | 98 |
| tum.de | 100 | 95 |
| kyoto-u.ac.jp | 100 | 94 |
| lmu.de | 100 | 94 |
| harvard.edu | 97 | 100 |
Bottom 5:
| Domain | Best Practice | Health |
|---|---|---|
| kaist.ac.kr | 61 | 86 |
| snu.ac.kr | 61 | 92 |
| soton.ac.uk | 71 | 89 |
| gla.ac.uk | 71 | 95 |
| kcl.ac.uk | 71 | 99 |
Worth noting: every domain in the bottom five still scores a comfortable Health rating above 85. Nothing here is broken — it's underconfigured. That's a more honest and more common failure mode than outright outages, and one that's much easier to fix once it's visible.
The takeaway
Universities are not failing at DNS. They're failing at the parts of DNS that were designed after 2005. The infrastructure inherited from decades of institutional continuity is solid; the newer security and authentication layers — DNSSEC, DKIM, DMARC enforcement — haven't caught up in nearly a quarter to nearly half of the sample. The sites work fine. The hygiene is inconsistent. For a sector that trades in credential systems, research data, and federated identity, that gap is worth closing.
What to do about it
If you run DNS for a university (or anything with a similar profile — a large, decentralized organization with a long-lived domain), the fixes here are well understood and don't require new infrastructure:
- Enable DNSSEC if it isn't already. Most registrars and managed DNS providers support one-click signing now — this used to be genuinely hard; it mostly isn't anymore.
- Move DMARC from
p=nonetop=quarantine, thenp=reject, gradually. Monitor-only DMARC for months or years is a common trap — it collects reports but blocks nothing. Use those reports to fix legitimate senders first, then tighten. - Add DKIM signing to every outbound mail source, including third-party platforms (admissions CRMs, alumni newsletter tools, event systems) — each one needs its own DKIM setup or it'll be the gap that keeps the domain from reaching
p=rejectsafely. - Review nameserver AS diversity for any subdomain that can't tolerate an outage — student portals, application systems, payment pages — even if the main domain's single-AS setup is an acceptable risk elsewhere.
Curious where your own domain lands? Run it through NODA and see the same 41 checks scored live.