Self-hosted email for education: why mailbox churn and student records shape the design
An IT director at a university or school district usually inherits a mail estate that changes every term: thousands of student accounts created in August and retired after graduation, alumni who expect to keep an address for years, and staff and contractors who come and go on their own schedule. The platform choice depends on three things: how many mailboxes must be provisioned and removed each year, how much of that lifecycle can run automatically from the student information system or directory, and which groups must stay on hosted mail because a contract or the institution's risk appetite requires it. Those answers decide whether a lightweight server is enough or whether a groupware suite with a directory-driven lifecycle is worth its operating load.
For most institutions the shortlist is Stalwart, mailcow and OX App Suite. Stalwart is a single all-in-one mail and collaboration server with IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV support, licensed under AGPL-3.0, and it suits smaller estates with a capable team that wants few moving parts. mailcow is a Docker-based bundle built around Postfix, Dovecot and SOGo under GPL-3.0, a practical option for mid-sized deployments. OX App Suite v8 is built for larger scale. It runs on Kubernetes and is delivered as Helm charts that reference container images, so it needs a cluster team, Helm 3.17.0 or newer, Istio or a basic ingress-nginx option, and a supported edition with an agreed support commitment. Confirm with Open-Xchange which modules your institution needs, because the license agreement may set custom packaging, limitations or separate fees for certain modules.
Which education rules turn into mail platform requirements
This table maps the US education and child privacy rules that affect school mail to concrete platform requirements for provisioning, logging and retention. Read each row as a question to put to your legal, registrar and IT teams before choosing a platform, since the rule sets only define outcomes and the mail design has to deliver them.
| Rule | What it asks for | What it means for mail provisioning, logging and retention |
|---|---|---|
| FERPA school official access (34 CFR 99.31) | Contractors may see education records only under direct institutional control and with legitimate educational interest; access must be limited by technical or physical controls | Provision mailboxes by role and group, restrict shared and delegated access, and confirm that the hosting partner acts under written institutional control with redisclosure limits in place |
| FERPA disclosure logging (34 CFR 99.32) | Record each request for and disclosure of personally identifiable information, with the parties and their interests, for as long as the records are kept | Enable mailbox access and admin audit logs that can be tied to a named person and purpose, and keep them for the same period as the records they concern |
| FERPA inspection timing (34 CFR 99.10) | Respond to a parent or eligible student inspection request within a reasonable period and no more than 45 days after receipt | Be able to locate all mail that relates to a student across mailboxes, archives and backups within that window, so search tooling and archive indexes must be tested before go-live |
| FERPA enforcement exposure (34 CFR 99.67) | Non-compliance can lead to withheld payments, a cease and desist complaint or loss of eligibility for funding | Treat logging, access control and inspection search as launch gates, not later improvements, and ask counsel to document how each control was verified |
| GLBA Safeguards: MFA and written program (16 CFR 314.4) | Written information security program, multi-factor authentication for anyone accessing any information system, and a designated coordinator | Require MFA on webmail, IMAP, JMAP, admin consoles and VPN paths, and block legacy basic-auth clients that cannot use it; document the program that covers the mail stack |
| GLBA breach notification (16 CFR 314.4(j)) | Notify the FTC within 30 days of discovering a notification event affecting at least 500 consumers | Log authentication failures, mailbox exports and admin changes so the institution can determine scope quickly, and agree on an incident runbook with the hosting partner |
| COPPA under-13 data (16 CFR 312.2 and 312.8) | Operators collecting personal information from children under 13 keep a written security program, a designated coordinator and at least annual risk assessments | Separate accounts for younger users where any service collects their data, and include those accounts in the annual risk assessment scope |
| COPPA retention and deletion (16 CFR 312.10) | Keep children's personal information only as long as reasonably necessary, with a written retention policy and deletion timeframe | Set mailbox and archive retention per age group, automate deletion or archival at account end, and confirm that backups follow the same deletion timeframe |
Which student, staff and alumni groups should stay on hosted mail
Enrolled students send and receive messages that often contain education records, such as grades, disciplinary notes, financial aid correspondence and accommodation requests. Under FERPA (34 CFR Part 99), the institution must control who may see those records and must be able to show each disclosure. A self-hosted platform gives the institution direct control over mailbox access, logging and retention, which is why many institutions keep the student core on infrastructure they run. The trade-off is volume: enrollment cycles bring large, predictable spikes in mailbox creation and deletion each term.
- Records in the mailbox: Treat any mailbox that may hold education records as in scope for FERPA access logging and the 99.32 disclosure record.
- Volume and churn: Plan provisioning and deprovisioning around the enrollment calendar, not average daily load.
- Spam at scale: Student addresses are a common phishing target, so filtering and authentication need to be tuned for large inbound volume.
- Access controls: Use directory-driven access and role separation so administrators can reach mail only for a documented need.
- Hosted fallback: Consider keeping low-sensitivity, high-volume announcement lists on hosted mail if your deliverability team prefers it.
Check with your registrar and general counsel which mailboxes hold education records, and confirm your FERPA disclosure logging before choosing the hosting model.
Faculty and staff mailboxes hold the same kinds of records as student mail, plus personnel files, grant administration, research data and HR correspondence. Staff tenure is usually longer than a student enrollment, so mailboxes accumulate more history and need longer, more deliberate retention. Many institutions therefore self-host this group when they already run identity and calendaring for the campus, and they want one access model across the institution. Because this group also handles sensitive personnel data, the same logging and encryption expectations apply.
- Long-lived mailboxes: Plan storage growth and archive policy around multi-year tenure.
- Personnel and grant records: Separate these from general correspondence in retention and access rules where possible.
- Shared and departmental mailboxes: Map delegation, shared folders and calendars early, since these are often where access problems start.
- Directory integration: Tie authentication to the institutional identity source so departures remove access promptly.
- Mobile and calendar clients: Confirm that the protocols your staff use, such as IMAP, CalDAV and CardDAV, are supported on the chosen server.
Confirm with HR and legal which records must be preserved and for how long, and confirm that your directory integration covers leavers and contractors.
Alumni mail is often the least sensitive group but the largest in long-term count. Alumni typically keep forwarding addresses for decades, and the institution has a relationship with them for fundraising and career services, which is a different legal footing from enrollment. Keeping alumni on a self-hosted mail platform means carrying an ever-growing mailbox population with little operational reason to stay close to the core. A hosted service or a forwarding model often fits better here, as long as the institution controls its domain, sender authentication and the forwarding rules.
- Lifecycle divergence: Alumni accounts outlive enrollment, so decide whether they are full mailboxes, forwards or hosted accounts.
- Sender reputation: Outbound alumni newsletters can damage the domain reputation shared with official mail, so send them through a separate sending path.
- Forwarding risk: Forwarding to outside providers moves mail out of your controls, so document what leaves the institution.
- Domain control: Keep the institutional domain and DNS records under your management regardless of where the mailbox sits.
- Migration and exit: Set a clear rule for when an alumnus loses a mailbox, and communicate it early.
Confirm the forwarding and retention policy with the alumni office, and confirm that your domain, SPF, DKIM and DMARC records remain under institutional control.
Schools that provide accounts to pupils under 13 face a different set of rules. The COPPA Rule (16 CFR Part 312) applies to operators that collect personal information from children under 13 online, and it requires a written information security program, at least annual risk assessments and a written retention policy with a deletion timeframe. FERPA also applies to pupil records held by a school. Self-hosting can give a school district the control these rules expect, but it also makes the district responsible for the program, the assessments and the deletion. Many districts therefore keep pupil accounts on a vendor relationship they have assessed carefully, or limit pupil mail to closed, internal messaging.
- Operator obligations: Determine whether your district or a vendor acts as the operator for pupil accounts, since that choice sets who carries the COPPA duties.
- Retention rules: Pupil mail may be kept only as long as reasonably necessary, so build automatic deletion into the design.
- Closed communication: Restrict external delivery for pupil accounts unless there is a documented need.
- Parental access: Plan how parents or eligible students request records within the FERPA timeframe.
- Assessment cadence: Schedule the annual risk assessment and keep its output with the security program.
Confirm with counsel whether pupil accounts fall under COPPA for your deployment and who acts as the operator before choosing the hosting model.
Research groups often include outside collaborators, sponsored project staff and contractors who need institutional mail. FERPA allows an outside contractor to receive education records as a school official only when it performs a service the institution would otherwise use employees for, is under the institution's direct control for the use and maintenance of the records, and follows the redisclosure limits in 99.33(a) (34 CFR 99.31(a)(1)(i)(B)). That condition is narrow. A contracted research partner that is not performing an institutional service may not qualify, so mail with student records should not reach it by default. Hosted mail from a third party may also be the right answer for groups whose work is mostly external, provided the contract covers records handling.
- School official test: Confirm each contractor's role against the three conditions in 99.31(a)(1)(i)(B) before granting access.
- Direct control: Keep the mailbox, its logs and its retention under institutional administration, which is easier on a self-hosted platform.
- Redisclosure limits: Write the redisclosure restrictions into the contract and into mail handling guidance.
- Access by need: Use access controls so contractors reach only the records in which they have a legitimate educational interest.
- Separate tenancy: Consider a separate domain or tenant for external collaborators so their mail never mixes with student records.
Confirm each research group's contractor status and records exposure with your general counsel before deciding whether its mail stays self-hosted, moves to hosted mail or sits in a split model.
Which open-source mail platforms fit a campus
A campus mail platform has to match its mailbox count, its operations team and its lifecycle processes, and no single product fits every institution. The cards below set out where Stalwart, mailcow and OX App Suite each fit, and where a gateway or archive changes the design.
Stalwart for lean, protocol-first teams
Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV, and it is licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs. It suits a small central IT team that wants a single server to run and is comfortable owning configuration. Check whether the features your registrar and student services need, such as delegated access and group management, are present in the edition you choose, and confirm the current release, which is v0.16.26 published on October 11, 2026. Confirm support terms before committing a student population to it.
mailcow for mid-sized campuses
mailcow-dockerized is licensed under GPL-3.0 and bundles Postfix, Dovecot, Rspamd and SOGo groupware into a Docker Compose stack. It fits a mid-sized institution, a single campus or a college with a few thousand accounts, where a small team can maintain containers and backups. Plan for the operational work that stays with you: updates, reverse DNS, sender reputation and restores. Test how the bundled components handle alumni forwarding and bulk account lifecycle changes before you rely on them for graduating classes.
OX App Suite v8 for large, multi-tenant estates
OX App Suite v8 is designed to run on Kubernetes and is delivered as Helm charts that reference container images, with Helm 3.17.0 or newer required. It needs Istio, or a basic ingress-nginx option where Istio cannot be used, plus MariaDB, Redis 7.4.x and a distributed file store such as NFS or object storage for larger deployments. Choose it when a university runs very large mailbox counts or serves several affiliated institutions, and when you have platform engineers. Use the current LTS release, v8.47, for planning, and confirm licensing for any modules you need, since certain features may carry separate fees.
Where a gateway or archive joins the stack
None of the three mail platforms replaces a dedicated inbound filtering layer or a long-term archive for every campus. A commercial gateway in front of the server can absorb spam and phishing spikes during enrollment and admissions cycles, and a separate archive keeps records for departments that must preserve correspondence. Ask each vendor how journaling is delivered, how the archive is searched for records requests, and who owns the configuration. Keep the decision separate from the mail server choice so that it can change later without a migration.
Integration points that carry student lifecycle and records
A self-hosted mail platform for a university or school is only as accurate as the data feeding it. The four integration points below decide who gets a mailbox, when that access ends, how inbound mail is screened at volume, and whether the institution can show who accessed student correspondence and when.
Student information system and identity feed
The student information system is usually the authoritative source for enrollment status, program, and student number. Connect the mail platform's directory to the identity provider that consumes that data, using OpenID Connect or SAML so that login decisions come from one place rather than from manually maintained mail accounts. Check which attributes the feed carries, how often it runs, and who owns a record when the registrar and the identity team disagree. The single identity source is the control that keeps mailbox state honest.
Provisioning for admissions and graduation
Mailboxes should be created when an offer is accepted or enrollment is confirmed, and changed when a student graduates, withdraws or moves to alumni status. Each transition needs a defined outcome: retained access, read-only access, forwarding, or removal after a stated period. Agree these rules with the registrar and the records office before the first cohort is loaded, and test the deprovisioning path as carefully as the provisioning path, because stale accounts are the most common source of unexpected access to retained correspondence.
Spam filtering at institutional scale
Universities receive high volumes of inbound mail from applicants, vendors, and bulk senders, and a large share of traffic is phishing aimed at students and staff. The filtering layer needs scoring rules, malware scanning, and a process for releasing false positives that does not depend on one administrator. Ask any partner how filter tuning is reviewed, how quarantine is delivered to users, and how sender authentication results are recorded. Plan these controls before you move high-traffic groups off hosted mail, not after complaints arrive.
Access and disclosure logging
FERPA requires institutions to record each request for access to, and each disclosure of, personally identifiable information from education records, along with the parties involved and their legitimate interests, for as long as the records are kept (34 CFR 99.32). Mail platforms must therefore log administrative access, mailbox opens by staff, and any export or forwarding of student correspondence, and send those logs to storage the operators cannot quietly edit. Confirm with counsel which events count as disclosures before you define the log schema.
How a campus mail migration moves from pilot to cutover
This sequence moves a university or school from its current mail estate to a self-hosted platform in controlled stages, so that each population is classified, provisioned, tested and verified before the old tenant is retired. Every phase closes with a written artifact that the institution can review and sign off.
Scope groups and classify records
The project team, with the registrar, library, HR and the data protection or privacy office, inventories every mail population: students, alumni, faculty, staff, contractors, shared mailboxes and departmental accounts. For each group, it records which education records may appear in mail, which retention rules apply, and whether the group stays on hosted mail. The output is a written data map that names the systems, owners and legal basis for each population. The step is done when the institution's data owners have signed the map and the list of groups that will move, and the groups that will stay on hosted mail, are agreed in writing.
Integrate identity and lifecycle events
The team connects the directory source of truth to the mail platform through the institution's chosen single sign-on method, then maps enrollment, graduation, leave and departure events to mailbox states such as active, forwarding-restricted, read-only and deleted. Deprovisioning rules are written down before any mailbox is created. The output is a tested deprovisioning run: test accounts are moved through each lifecycle event, and the team confirms that access is removed, alumni forwarding follows the policy, and no record is left in an orphaned mailbox. The step is done when the test log is reviewed and accepted by the identity owner.
Run a pilot with one faculty group
A single faculty group, chosen because its members can give fast and detailed feedback, is migrated onto the new platform while the old mail system stays live. The pilot checks mailbox import fidelity, calendar and contact sync on the clients the group uses, shared mailbox permissions, and access from mobile devices. The team also tests the agreed procedure for handling a student-records message that arrives in faculty mail. The output is a pilot report listing defects, workarounds and the rollback steps that were rehearsed. The step is done when the faculty group confirms the workflows they depend on, and the defects that remain are assigned to an owner with a fix date.
Migrate population waves
Remaining populations move in waves defined by the data map, usually starting with staff and moving toward the largest and most transient student populations. Each wave follows a migration runbook that lists source and target hosts, the import order, delta sync windows, address changes, forwarding rules and the verification checks for message counts and folder structure. Alumni and dormant accounts are handled in their own wave under the retention and forwarding policy. The output is a signed wave record for each population showing counts reconciled against the source. The step is done when each wave passes reconciliation and the help desk has its updated scripts.
Tune filtering and deliverability
Before the domain points to the new platform, the team sets up SPF, DKIM and DMARC for every sending domain, confirms reverse DNS and TLS for outbound connections, and tunes spam and malware filtering against the institution's real mail flow. Because campus mail includes large bulk lists, research correspondence and frequent external submissions, the team reviews false positives with the faculty pilot group and the help desk before wider release. The output is a deliverability baseline with DMARC report monitoring and a documented process for releasing quarantined legitimate mail. The step is done when test messages reach the major external providers with passing authentication results and the quarantine review process is staffed.
Cut over mail routing and delivery
On an agreed date within a change window, the team lowers DNS time-to-live values in advance, updates MX and autodiscovery records, moves remaining delta syncs, and confirms that inbound mail reaches the new platform. Outbound routing, client configuration and mobile profiles are switched in the same window, and the rollback procedure from the runbook is kept ready until delivery is stable. The output is a cutover log with timestamps, checks performed and any messages held or re-routed. The step is done when inbound and outbound tests pass from internal and external accounts and the monitoring dashboards show normal delivery.
Decommission the old tenant
After a stabilization period that the institution sets in advance, the old mail tenant is retired. Before deletion, the team confirms that required archives, legal holds and records exports have been taken and verified, that the retained copies are stored under the agreed access controls, and that accounts, licenses, DNS entries and connectors are removed. The output is a decommissioning certificate signed by the data owner, with a record of what was retained, where it is held and who can access it. The step is done when the institution confirms in writing that no education records remain only in the retired tenant and that the old contracts have been closed.
Evidence auditors and the Department of Education ask for
This table lists the evidence an institution typically needs for FERPA, GLBA Safeguards and COPPA-related reviews, the component that produces each item, and what to confirm before an assessment. DeployOpen prepares the systems, controls and evidence, but auditors, certification bodies and the Department of Education reach the conclusions. Use the rows to check whether your mail platform, identity provider and archive can each produce their part.
| Evidence item | Component that produces it | What the reviewer expects to see |
|---|---|---|
| FERPA disclosure log | Mail archive and ticketing system for records requests | A record of each request for and disclosure of student PII, with the parties and their legitimate interest, kept as long as the records are kept (34 CFR 99.32) |
| School official access controls | Identity provider groups and mailbox delegation settings | Documented role groups, evidence that access is limited to legitimate educational interest, and records of who was granted delegate or shared-mailbox rights |
| Written information security program and risk assessment | Policy repository and annual risk assessment records | A written program with a named coordinator, a current risk assessment and evidence that findings were tracked to closure |
| MFA evidence for mailbox access | Identity provider authentication logs and mail server login logs | Proof that multi-factor authentication applies to every route that reaches mail, including IMAP, JMAP and webmail, with exceptions listed and approved |
| Deletion records for minors' data | Mail server retention settings, backup policy and deletion tickets | A written retention policy with deletion timeframes for under-13 accounts and records showing deletion ran, including backups |
| Incident notification process | Ticketing system and mail server alert pipeline | A written process with roles, timelines for FTC notification where the Safeguards Rule applies, and records from a past exercise or event |
| Mailbox audit logs | Mail server logs, forwarded to a central log store | Logs showing who accessed, forwarded or exported mailboxes, retained long enough to support an investigation and protected from edits by administrators |
What to ask an implementation partner before a campus mail project
Start with FERPA and GLBA experience. Ask the partner to describe a past engagement where education records sat in a mail or groupware system and school officials needed access. Under 34 CFR 99.31(a)(1)(i)(B), an outside party can receive education records as a school official only under direct institutional control and subject to redisclosure limits, so ask how the partner's contract terms, administrator roles and audit configuration would demonstrate that control. Ask how they set up the access controls described in 34 CFR 99.31(a)(1)(ii) so staff see only mailboxes tied to a legitimate educational interest, and how they keep the disclosure record that 34 CFR 99.32 requires. For GLBA, ask which written information security program elements they would document for the Safeguards Rule, including multi-factor authentication for every administrative and mailbox access path, and how they would support the 30-day FTC notification clock in 16 CFR 314.4(j).
Ask how lifecycle deprovisioning is tested. Student and alumni mailboxes change state constantly, so request a written test plan that covers enrollment, graduation, withdrawal, leave of absence and alumni conversion, with the expected result for each state. Ask which directory source drives those changes, what happens to mail forwarding, calendars and shared mailboxes when an account is disabled, and how long data remains before deletion. Ask how the partner aligns the deletion timeframe with the institution's retention schedule and with any COPPA obligations for accounts of students under 13, which 16 CFR 312.10 governs. Request a sample of the test evidence, not only a description of it.
Ask how spam tuning protects admissions and faculty correspondence. Ask which filtering components they would run, how they would set allowlists for trusted senders such as applicant portals and accreditation bodies, and how they would measure false positives during a pilot. Ask who reviews quarantined messages and how fast. On licensing, ask which OX App Suite edition and modules are in scope, whether any module needs separate fees under the license agreement, and how they plan around the support commitment: which release train they recommend, how they track standard and LTS end-of-support dates, and what upgrade window they assume. Finally, ask how they will move mailboxes without loss, including dry-run migrations, delta syncs, and sign-off criteria for each campus group before cutover.
What do campuses ask before self-hosting email
What drives the cost of self-hosted email for a university?
Cost is driven by mailbox count and churn, storage per mailbox, the number of systems the mail platform must connect to, any licensed modules, and the staff time that deliverability and spam filtering take. Mailbox count sets the size of the storage, backup and high availability design, and student intake and graduation cycles add provisioning and deprovisioning work every term. Integration count matters because each identity source, directory, learning platform or records system needs its own connector and testing. If you choose OX App Suite, ask whether the modules you need are included in your license, since Open-Xchange states that some modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask any partner to split its quote into one-time build work and recurring operations, support and upgrades.
How long does a campus email migration take?
Duration depends mainly on mailbox volume, the total size of archives, the number of identity sources, and how many departments and alumni groups move in each wave. Large, fast-changing populations usually need staged waves rather than one cutover, so coexistence and mail routing during the transition must be planned in advance. Domain changes, SPF, DKIM and DMARC records and any external sender reputation work add their own steps. This page does not give a duration because none is supplied for this scenario. Ask a partner for a written plan that lists the waves, the test mailboxes, the rollback steps and the criteria for moving each group.
What does the institution have to provide before the project starts?
The institution must supply decisions and data that no implementer can make for it. The main inputs are:
- An authoritative identity source for students, staff, alumni and guests, and the rules for when each account is created, changed or removed.
- Named data owners for mail, calendars, contacts and any records that mail may contain.
- Written policy decisions on retention periods, legal hold, access to other people's mailboxes, and which groups stay on hosted mail.
- Records of the FERPA access and disclosure obligations that apply to student records, so the mail design can be checked against them.
Because the regulations in 34 CFR Part 99 require institutions to control which school officials can see education records, those decisions shape the access model. Confirm each input before the design phase starts.
Can our IT team run a self-hosted campus mail system alone?
Some campuses run mail with their own staff, but the workload must be sized honestly. Routine operations include patching, monitoring queues, managing certificates and keys, handling spam tuning and false positives, and responding to blocklistings. Deliverability to large providers depends on correct DNS, reverse DNS, TLS and DKIM and DMARC alignment, and that work recurs. Student lifecycle changes, backup restore tests and upgrade planning also take steady time. Ask whether your team has someone who can own deliverability and incident response outside busy periods, and whether a partner can cover those tasks under a written support arrangement.
Can DeployOpen support our mail platform after go-live?
Yes. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and ongoing support, upgrades and continuous testing are available as retainers. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. DeployOpen does not publish a price list, so a quote follows from the written scope. Ask for the support hours, the escalation path, the upgrade approach and which parts of operations stay with your team.
Which student and alumni groups should stay on hosted mail?
Many campuses keep some groups on hosted mail while moving others, and the split should follow data sensitivity and operational capacity rather than convenience. Groups that handle education records, research data or regulated correspondence are common candidates for tighter control, while large student populations may be better suited to a platform with strong lifecycle automation. Consider the GLBA Safeguards Rule for financial aid data, which requires multi-factor authentication for anyone accessing any information system, and the COPPA Rule if the campus serves children under 13. Write the split as a policy and review it against each group's records.
How does spam filtering at campus scale affect the design?
Filtering at campus scale must balance high inbound volume against false positives that block coursework, admissions or financial aid messages. The design needs a scoring layer, malware scanning of attachments, sender authentication checks and a process for releasing quarantined mail. Mailbox churn means filtering rules must not depend on manual per-user settings. Ask any partner how false positives are measured, who approves releases, how quarantine retention is set, and what logs are kept for investigations.
How DeployOpen scopes and supports campus email
DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source mail inside the institution's own cloud accounts, data centers or networks. Most campus engagements are fixed-scope, so the mailbox groups, domains, migration waves, retention rules and deliverable list are agreed in writing before work starts. DeployOpen does not publish a price list. A quote follows from that written scope, so the scope document is the first thing to bring to a procurement discussion. Ask for each deliverable to be tied to a named group of users, a named records rule and a named acceptance check.
Scoping for a university or school usually starts by splitting the population. Staff, students, alumni, applicants and shared department mailboxes often need different retention periods, different routing and different access rules. The scope should record which groups move to the self-hosted platform, which stay on hosted mail, and which records each group creates. Student records handling is the sensitive part. Under FERPA, a contractor that receives education records as a school official must stay under the institution's direct control, so the written scope should state who administers the platform, who can open a mailbox, and how access is logged. Confirm those roles with your counsel before the first migration wave.
Implementation runs inside the institution's infrastructure, with DeployOpen handling configuration, hardening, backup design, monitoring setup and runbooks. Acceptance tests should cover restore of a mailbox from backup, spam and malware filtering on a sample of inbound and outbound traffic, and sender authentication for every domain in scope. Evidence packs for a compliance assessment can include configuration baselines, access reviews and test results. DeployOpen prepares that evidence but does not issue audit reports, attestations or certifications, so confirm with your auditor which artifacts they will accept. Because the platform keeps changing, many institutions add a retainer for upgrades, security patches and continuous support after go-live, and should price that as a recurring line item separate from the build.
