Email authentication for schools and universities

16 May 2026 · 13 min read

Why email authentication is harder for a university than for a bank

A bank sends mail from a handful of well governed systems run by one IT function. A university does not. A single .edu or .ac.uk domain typically carries the admissions office, the alumni and development team, the central IT helpdesk, the library, the careers service, dozens of academic departments, the students' union, the conference and events team, payroll, the research grants office, and a long tail of niche systems that someone bought on a departmental card in 2017 and never told anyone about. Each of those groups sends email, and a surprising number of them send it from the institution's main domain rather than a subdomain.

That is the core problem. DMARC enforcement (p=quarantine or p=reject) is a single decision applied to one organisational domain, but the people affected by that decision are spread across the entire institution and report to different managers. Turning on enforcement before you have found every legitimate sender will silently bin real mail: offer letters that never reach applicants, password reset emails from a faculty's own learning platform, fundraising appeals to alumni, payslips. In a university the blast radius of a careless flip to p=reject is enormous, and the people who get blamed are rarely the people who pulled the trigger.

This article is about doing it properly on a sprawling estate. Not a generic "what is DMARC" walkthrough, but the specific path from discovery to enforcement when you have many departments, many senders, federated identity, third party recruitment platforms, and a domain that has been accreting senders for fifteen years. If you want to see where your domain stands right now before reading further, run it through the DMARC checker and the SPF checker.

The three layers you are actually authenticating

It helps to be precise about what passes and what fails, because in a federated environment the answers are not obvious.

• SPF authorises which IP addresses may send mail using your domain in the SMTP envelope sender (the MAIL FROM, also called the Return-Path). It is checked against the envelope domain, which is frequently not the domain a human sees.
• DKIM attaches a cryptographic signature to the message using a private key, and receivers verify it against a public key you publish in DNS. DKIM survives some forwarding that SPF does not.
• DMARC ties the two together. It requires that SPF or DKIM not only pass, but pass for a domain that aligns with the visible From: header domain. This is the part institutions consistently get wrong.

Alignment is where universities trip. A department buys an email service, the vendor sends on your behalf, SPF passes for the vendor's own domain in the envelope, DKIM is signed with the vendor's domain, and a non-technical person concludes "authentication is fine". DMARC then fails, because neither passing mechanism aligns with the From: your recipients actually see. If you want the precise rule set, our explainer on DMARC alignment, header From versus envelope From covers the distinction in detail, and RFC 7489 explained covers the standard itself.

Stage one: discovery, before you touch a single policy

You cannot enforce what you cannot see. The first job on any educational estate is to turn the institution's email into data, and the only honest way to do that at scale is to publish a monitoring DMARC record and collect aggregate reports for several weeks.

Start with the most permissive possible policy so you change nothing about delivery:

v=DMARC1; p=none; rua=mailto:dmarc-reports@yourdomain.edu; ri=86400; fo=1

p=none tells receivers to take no action and simply report. rua is the address that receives daily aggregate XML reports from Google, Microsoft, Yahoo and others. fo=1 asks for a failure report whenever any underlying mechanism fails, which surfaces near misses you would otherwise never notice. Generate a correct record for your specifics with the DMARC generator rather than hand editing, because a malformed record is treated as no record at all.

Do not point rua at a human inbox. A medium sized university generates thousands of aggregate reports a month from hundreds of sending sources, each one a compressed XML file. You need them parsed and aggregated. Paste a sample into the DMARC report analyzer to see what the raw data actually contains, then plan for ongoing automated processing. If you would rather not stand up that pipeline yourself, our DMARC monitoring does the collection, parsing and change alerting for you.

Run the discovery phase for at least four to six weeks, and ideally across a full term boundary. University sending is intensely seasonal. Clearing and confirmation generates a recruitment email storm in August that simply does not exist in February. Graduation, freshers' week, exam results, alumni giving days and grant deadlines all light up senders that are dormant the rest of the year. Enforce in March on data gathered in March and you will discover the August senders the hard way.

What the reports reveal on a real .edu estate

When the first weeks of aggregate data come back, an institution typically finds something like this in the DMARC report analyzer:

• The central Microsoft 365 or Google Workspace tenant, sending the bulk of staff and student mail. This usually aligns cleanly once DKIM is enabled, and it is your easy win.
• A student information system (Banner, SITS/Tribal, Workday Student, PeopleSoft) sending admissions decisions and enrolment mail, often through a relay or a bolt on email module nobody documented.
• A CRM and recruitment platform (Slate, Hobsons, Ellucian, Salesforce Education Cloud) sending prospectus requests, open day invitations and offer communications, frequently from your domain with the vendor's own SPF and DKIM.
• A virtual learning environment (Canvas, Blackboard, Moodle, Brightspace) sending course notifications, sometimes from a subdomain, sometimes not.
• Alumni and development software (Raiser's Edge, ThankQ, Toucan, a dedicated mass mailer) sending fundraising and event mail to addresses that are old, sensitive to deliverability, and unforgiving of a fundraising appeal landing in spam.
• A scattering of departmental tools: survey platforms, lab booking systems, a careers job board, a library overdue notice service, a conferences team using Mailchimp, a research group running its own list server on a Linux box under a desk.
• A meaningful volume of forwarding, because academics forward institutional mail to personal accounts and to other institutions constantly. Forwarding breaks SPF and is the single biggest source of confusing report data on an academic domain. If your reports show DMARC failing while SPF and DKIM individually look fine, read DMARC fails but SPF and DKIM pass and fix DKIM fails after forwarding.
• Finally, outright spoofing: spam and phishing using your domain in the From: to target your own students, applicants and staff. This is the threat enforcement exists to stop, and on a recognisable university brand the volume is rarely zero.

Catalogue every legitimate source before you change anything. Build a register: sending system, owning department, named contact, the domain it currently signs with, and whether it can be made to align. That register is the actual deliverable of stage one, more than any DNS record.

Stage two: fix SPF without breaking the ten lookup limit

SPF on a long lived university domain is almost always a mess, because every vendor onboarding added another include: and nobody ever removed one. The protocol imposes a hard limit of ten DNS lookups when evaluating an SPF record, and exceeding it produces a permerror that causes SPF to fail outright. Each include: for a major platform can itself consume several lookups, so universities blow past ten with depressing ease.

Check your current count with the SPF checker. A typical bloated record looks like this:

v=spf1 include:_spf.google.com include:spf.protection.outlook.com include:_spf.salesforce.com include:servers.mcsv.net include:sendgrid.net include:_spf.elasticemail.com include:mail.zendesk.com ~all

That is already over the limit before you have added the student information system or the alumni mailer. When you hit a permerror, read fix SPF too many DNS lookups and fix SPF permerror for the mechanics.

Two structural fixes matter more than any single edit:

1. Stop sending everything from the apex domain. Give each major function its own subdomain with its own SPF and its own DMARC policy. Admissions on apply.yourdomain.edu, fundraising on give.yourdomain.edu, course mail on learn.yourdomain.edu. Each subdomain has its own ten lookup budget and its own blast radius, so a misconfiguration in the careers job board cannot threaten admissions mail. This is the single most useful architectural decision on a sprawling estate.
2. Flatten or audit the apex record so it only contains senders that genuinely must send as the bare domain. SPF flattening resolves include: chains to their IP ranges to stay under ten lookups, but it must be kept current as vendors change their ranges, which is exactly the kind of silent breakage our DMARC monitoring is designed to alert on.

End the record with ~all (softfail) during the transition rather than -all (hardfail), then tighten to -all once DMARC enforcement is doing the real rejecting and you trust your inventory.

Stage three: get every sender to align on DKIM

DKIM is your friend on an academic estate because it survives forwarding, and academics forward everything. The goal of stage three is for every legitimate sender to apply a DKIM signature that aligns with the From: domain your recipients see.

For each platform in your register, this means:

• Enabling DKIM in the vendor's admin console, which generates a public key.
• Publishing that key as a DNS record on the correct selector, usually a CNAME that delegates to the vendor so they can rotate keys without involving you. A delegated selector for a recruitment platform might look like slate._domainkey.apply.yourdomain.edu.
• Configuring the vendor to sign as your domain or subdomain, not theirs, so the signature aligns.

Verify each one with the DKIM checker, and generate keys for any in house systems with the DKIM generator. When a key cannot be found or the signature will not verify, fix DKIM key not found and fix DKIM signature did not verify cover the usual causes: a selector typo, a key published with line breaks, or a default versus relaxed canonicalisation mismatch.

The hard cases are the long tail systems. The list server under a desk, the ten year old contract with a vendor who charges extra for DKIM, the lab tool whose support address bounces. You have two honest options for each: make it align, or move it. A system that genuinely cannot be made to authenticate has no business sending as your primary domain once you reach enforcement. Migrate it to a subdomain you control, or to a different sending service, or retire it. Enforcement is the forcing function that finally lets IT say no to a sender that has been a liability for years.

Stage four: the staged ramp to enforcement

With SPF clean, DKIM aligned across your register, and weeks of clean reports, you ramp the policy in deliberate steps. Never jump straight to p=reject.

Move first to a small sampled quarantine. The pct tag applies your policy to only a percentage of failing mail:

v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc-reports@yourdomain.edu; fo=1

This sends a quarter of failing messages to spam folders rather than rejecting them. Watch the reports and your helpdesk for a week or two. If a forgotten sender surfaces (and on a university estate one always does, usually a small department that only sends during a specific cycle), you have caught it with a quarter of the impact and nothing has bounced. If mail genuinely lands in spam but is not in your inventory, read DMARC quarantine but mail in inbox to understand why receivers vary.

Then step the percentage up: 25, 50, 100 at quarantine, holding at each level long enough to span the relevant sending cycle. Only when full quarantine has run clean do you move to:

v=DMARC1; p=reject; rua=mailto:dmarc-reports@yourdomain.edu; fo=1

Treat your subdomains independently. You might reach p=reject on give.yourdomain.edu months before the academic departments on the apex are ready, and that is correct: each domain enforces when its own inventory is clean, not when the slowest department catches up.

A crucial detail for any institution with subdomains: by default a DMARC policy applies to subdomains too, but you can override that with the sp tag. While you are still cleaning up departmental senders on the apex, you can hold subdomains at a different policy:

v=DMARC1; p=quarantine; sp=none; rua=mailto:dmarc-reports@yourdomain.edu

Here the organisational domain is at quarantine while undefined subdomains stay at p=none, which buys you time to inventory the long tail without bouncing departmental mail. Tighten sp last.

The governance problem nobody warns you about

The technical work is genuinely the smaller half. The harder half on a .edu estate is organisational, and it is where most stalled rollouts actually fail.

• Change control crosses departmental boundaries. Moving admissions to a subdomain affects admissions, IT, and the CRM vendor, none of whom report to each other. Enforcement deadlines slip not because DNS is hard but because three teams need to coordinate and no single person owns the outcome.
• Shadow IT is the norm, not the exception. A department will buy a survey tool tomorrow, configure it to send as the main domain, and tell no one. After you reach p=reject that mail simply bounces, the department blames central IT, and you are debugging a sender you never knew existed. Continuous monitoring with change alerts is the only practical defence: you find out a new unaligned source appeared from a report, not from an angry call.
• The reporting inbox needs a real owner. Aggregate reports keep arriving forever. Vendors change IP ranges, certificates expire, an include: silently pushes you back over ten lookups. Without someone watching, your carefully reached p=reject slowly rots until a legitimate sender starts failing.
• Decommissioning is political. Telling the emeritus professor's research group that their twelve year old list server must move is a conversation, not a config change. Enforcement gives you the leverage, but someone has to have the conversation.

Map your sending estate against the requirements of the major mailbox providers as well. Since Google and Yahoo's 2024 bulk sender rules, any institution sending more than 5,000 messages a day to Gmail (which describes essentially every university the moment admissions or alumni mail goes out) must have DMARC in place and keep spam complaints low. For students and applicants whose primary mailbox is Gmail or Outlook, your authentication posture directly determines whether your offer letter lands in the inbox or vanishes.

A realistic timeline and the practical takeaway

For a mid sized university with the estate described above, a sane plan looks like:

1. Weeks 1 to 6: publish p=none, collect and parse reports across a sending cycle, build the sender register.
2. Weeks 4 to 10: subdomain the major functions, fix SPF under ten lookups, enable and align DKIM on every catalogued sender.
3. Weeks 10 to 16: ramp pct quarantine from 25 to 100, holding at each level, using sp to protect the slow departments.
4. Weeks 16 plus: move clean domains to p=reject one at a time, tighten SPF to -all, and keep monitoring forever.

The honest message is that the work is not intellectually difficult; it is wide. The protocols are simple and well documented. What defeats institutions is the breadth of the estate, the seasonality of the sending, and the fact that the decision is central while the senders are not. Discover before you enforce, subdomain aggressively so no single mistake can take down admissions or alumni mail, and never flip to p=reject on data you gathered in the quiet part of the year.

Start by measuring what you actually have: run your domain through the DMARC checker, SPF checker and DKIM checker, then drop a sample report into the DMARC report analyzer to see your real sending estate. If you would rather not run a multi month, multi department rollout in house, DMARC Engine does this as a done for you service: we take a sprawling domain from p=none to p=reject safely, with continuous monitoring and change alerts so the next survey tool a department buys never becomes a silent outage.