FERPA and AI Email Tools in Schools: What Admins Must Ask

The FERPA question about AI email student data is not "is this tool allowed." It is "under what agreement." FERPA does not name technologies, and it does not certify vendors. It governs when a school may disclose personally identifiable information from a student's education records, and to whom.

Staff email is full of those records. A parent's note about a grade, a counselor's message about an IEP, a discipline thread naming a child - all of it is an education record the moment it is written down and held by the school. Point an AI assistant at those mailboxes and you have disclosed education records to a vendor.

This guide is for the person who has to sign off. It explains what FERPA requires, the one exception a district can actually use, the questions your approval process must ask a vendor, and - honestly - where AI Emaily fits and where it does not. We build AI Emaily; that disclosure matters, and we come back to it in the verdict.

The short answer#

Yes, a school can use an AI email assistant on mailboxes that contain student records - but only if the vendor is brought inside the school official exception by a written agreement, or the tool never touches an education record.

That agreement has to do specific work: place the vendor under the district's direct control over how it uses and keeps the records, limit its use to the service you hired it for, forbid redisclosure, and bar training any model on the data. A general terms-of-service click-through does not do that work.

The obligation is the school's, not the vendor's. There is no federal FERPA seal, audit, or registry, so a vendor cannot be "FERPA-certified." "FERPA-compliant" on a marketing page is not a determination - your counsel's reading of the signed contract is.

What FERPA governs, and who owes the duty#

FERPA is the Family Educational Rights and Privacy Act - 20 U.S.C. section 1232g, with rules at 34 CFR Part 99. It applies to schools and districts that receive U.S. Department of Education funds, which is nearly all public K-12 and most colleges.

An education record, under 34 CFR 99.3, is any record that is directly related to a student and maintained by the school or by a party acting for the school. Email meets both tests easily: a message naming a student is directly related to them, and it sits in a mailbox the school runs.

The duty to protect those records stays with the school. When you route email through a vendor, the vendor is acting for you - so its handling of the record is your handling of it. That is why the contract, not the vendor's good intentions, is the control.

The school official exception is the only realistic path#

FERPA lets a school disclose education records without parental consent to a "school official" with a legitimate educational interest (34 CFR 99.31(a)(1)). The exception was written for teachers and staff, but the regulation extends it to an outside party.

A contractor, consultant, volunteer, or vendor can be a school official only if it meets three conditions in the rule: it performs an institutional service or function the school would otherwise use employees for; it is under the direct control of the school with respect to the use and maintenance of the records; and it is subject to 99.33(a), which forbids redisclosing the information or using it for anything other than the purpose of the disclosure.

An AI email assistant clears the first test - triage and drafting is work staff would otherwise do by hand. The other two conditions are contract terms, and they are where approvals live or die.

Directory information does not cover most email content#

Some staff want to lean on directory information as a shortcut. Under 34 CFR 99.37, a school can disclose designated directory information - name, grade level, dates of attendance, and similar low-sensitivity items - without consent, if it gives public notice and lets families opt out.

That route does not rescue an AI email deployment. The records inside a mailbox are grades, discipline, health notes and IEP discussions, none of which is directory information. Directory information also excludes Social Security and student ID numbers by rule.

So the directory-information exception authorizes disclosing a name to a yearbook printer. It does not authorize a vendor processing the full contents of a counselor's inbox. For that, you are back to the school official exception and its contract.

The questions a district approval process must ask#

Turn the two contract conditions into questions, and score the vendor's written answers - not the sales call. Each row below has a compliant answer and a failing one. A failing answer on direct control, redisclosure, or training is disqualifying, not a point to average away.

Ask for the answers in a signed data privacy agreement or addendum, and keep the emailed replies. A privacy page can be edited after you sign; a countersigned contract cannot.

Worked example: approving an AI email assistant for a district#

Here is the sequence a K-12 approval process runs before any staff mailbox connects. It maps the FERPA conditions onto steps a technology director can actually complete.

1. 1

   1. Decide whether education records are in scope at all

   If you can restrict the tool to mailboxes with no student records - a facilities or purchasing inbox - FERPA is not triggered and the review is a normal security review. If counselor, teacher, or front-office mail is in scope, continue.

2. 2

   2. Confirm the vendor will be a school official in writing

   Get a signed data privacy agreement that names the district as controller, defines the service, and states the vendor is a school official under 34 CFR 99.31(a)(1). No signable agreement, no approval.

3. 3

   3. Read the direct-control and use clauses

   Verify the contract limits use to the service, forbids redisclosure and secondary use, and gives the district control over how records are used and kept. Match this to 99.33(a); a lawyer, not IT, signs off here.

4. 4

   4. Pin down training, retention, and sub-processors

   Require in writing: no training on your mail, a stated retention or zero-retention term with model providers, and a named sub-processor list. File the answers with the contract.

5. 5

   5. Set access controls and the exit path

   Confirm role-based access, an audit trail, and access scoped so staff see only their own mailbox - the reasonable methods 99.31 requires. Confirm the return-or-delete window on termination.

6. 6

   6. Update the annual notification and record the review

   Make sure your annual FERPA notice describes the criteria for school officials and legitimate educational interest broadly enough to include contractors, and keep the completed review on file.

Red flags in a vendor's answers#

• "We're FERPA-compliant" with no signable agreement behind it. Compliance is the district's determination on a contract, not a vendor label.
• Training on customer content is the default and can only be turned off by asking. If the safe state is opt-out, assume the data has already been used.
• No sub-processor list, or a reserved right to share with "trusted partners." You cannot control redisclosure you cannot see.
• Deletion "on request" with no timeline, and no return-or-delete clause on exit. That is retention, not a data-handling promise.
• The audit log records what the AI suggested, not what it changed. Only the second is evidence when a parent asks who saw a record.
• A blank look at prompt injection. An agent that reads mail from strangers and then acts needs an action allowlist and approval before send.

What we'd pick, honestly - and where we fit#

We build AI Emaily, so read this as a disclosed placement, not a neutral review. AI Emaily is an AI email client for staff mailboxes across Gmail, Outlook and Microsoft 365, iCloud, Fastmail, Proton and standard IMAP. Its design choices line up with several FERPA questions above: sends are approval-gated by default, every autonomous action lands in an audit log with undo, it does not train on your mail, it runs zero-retention inference, it publishes a sub-processor list, and it offers a general data processing agreement plus bring-your-own-key for sensitive work. Incoming mail is treated as untrusted input, which is the prompt-injection control the table asks for.

Here is the honest limit, as of August 2026: AI Emaily does not market itself as FERPA-compliant, does not publish FERPA-specific documentation, and does not offer a ready-made "school official" agreement out of the box. Whether our general DPA plus a signed agreement placing us under your direct control satisfies 34 CFR 99.31(a)(1) is your counsel's call - confirm our current contracting options with us in writing before you rely on them. We also do not offer single sign-on, an org-wide admin policy console, or automated seat provisioning, and SOC 2 is on the roadmap rather than done.

So who is AI Emaily right for here? A district or private school that runs its own FERPA program, is prepared to do the school-official contracting work, and wants approval-gated AI on staff mail with an audit trail and no training on the data. Who is it wrong for? A district that needs the vendor to hand over a signed, state or consortium student-data-privacy agreement out of the box, needs SSO and central policy controls on day one, or wants a vendor to self-certify FERPA. Those districts should shortlist tools that already sign your required data privacy agreement, or keep AI off mailboxes that hold education records until we do.