Campus Mailboxes · branded webmail for a high school or district office
Branded webmail for a high school or district office
An office runs on its inbox. This gives that traffic the school’s own name, and keeps it there when the person answering it changes.
Campus Mailboxes is branded webmail for the office that runs a high school or a district -- one professional home for the mail a building lives on, from attendance and enrollment questions to activities and athletics notices to the everyday note home. Correspondence carries the school's own name rather than a free provider's, and family and staff contact details stay inside our own private system instead of an outside marketing company that would mine them. Campus is the institutional side of the same school-photography platform, run by the same team -- a sibling brand on one shared engine, not a separate company. The address is open for a school or district to claim, and nothing here says a specific building already uses it.
Example address: [email protected]. Checkout is not open yet. The figures further down are catalog estimates, never a charge. No mailbox is created and no card is billed.
The actual problem
This is not a technology swap. It is who a family reaches.
Switching a mail provider is a project. That is not what this page is about. The problem underneath it is smaller and more durable: which address a family reaches when the building has something to say, and whether that address still works the day the person who set it up moves on.
A district office answers this the same way most small operations do, informally: a personal account here, a shared login there, a free provider's domain on the reply. It works until it does not -- until a staff member leaves and takes six years of correspondence with them, or a family cannot tell whether an email claiming to be from the school actually is.
Campus Mailboxes is the narrow fix: an address that belongs to the office, on the school's own domain, that outlasts whoever is covering it this year.
The addresses an office actually needs
Eight role addresses, in the order a family looks for one
Every one of these is a role, not a person. The address stays with the job when the person covering it changes.
| Address | Who answers it | Why it is a role, not a person |
|---|---|---|
| [email protected] | The front office | The general line for a family or a visitor with a question. Whoever is at the desk answers it, not whoever happened to set the account up. |
| [email protected] | The attendance clerk | Absence notes and early-dismissal requests, in one place instead of scattered across whichever staff inbox a parent happened to have saved. |
| [email protected] | The registrar | Enrollment and records questions carry the weight of an official address, not a personal one a family has to double-check. |
| [email protected] | The athletics director | Eligibility, schedules, and transportation notices under the school's own name, reachable the same way every season. |
| [email protected] | The activities coordinator | Clubs, permission slips, and event logistics -- correspondence that outlives whichever staff member is running a given club this year. |
| [email protected] | The business office | Invoices, purchase orders, and reconciliation questions land on an address that matches the district's own paperwork. |
| [email protected] | Building leadership | Escalations and board correspondence carry the building's name, and the address does not change when leadership does. |
| [email protected] | The office | Where a single family's question about a school message actually gets answered. It is not a broadcast sender and has no distribution list -- that job belongs to schoolnews.email. |
A school or district picks the addresses it actually needs; this list is illustrative of the shape, not a fixed menu. The team and organization tiers below differ mainly in how many of these an office can run at once.
The ordinary, unglamorous case
When a staff member leaves, the address stays
Offices lose institutional memory through personal inboxes more often than through any dramatic failure. A registrar retires, an athletics director takes a job across town, and the thread history that answered every family's version of the same question goes with them.
A role address is the fix, not a policy memo asking staff to please cc the shared folder. The address belongs to the office. Coverage is a rotation, not a password handed off in a hallway.
So a family that emailed attendance@ in September can still get an answer in April, from whoever is covering it that week, without needing to know who that is.
This is the case that never makes a pitch deck and is the one an office actually feels. It is the whole argument for this page.
The same addresses, a different mix all year
What moves through an office mailbox across a school year
Not a claim about any specific building’s volume -- just the ordinary shape of a school year, and why a role address rather than a person is the right unit for carrying it.
Late summer
Enrollment and registration questions dominate registrar@ and office@, ahead of the first day.
Early fall
Attendance settles into its steady rhythm, and activities@ carries the first wave of club and permission-slip mail.
Fall and winter sports
athletics@ carries eligibility questions, schedule changes, and transportation notices on its own cadence, distinct from the classroom calendar.
Mid-year
businessoffice@ carries invoice and purchase-order traffic tied to the district's own budget cycle, not the academic one.
Spring
Activities and athletics both run active seasons at once, and registrar@ starts fielding next year's enrollment questions early.
End of year
Records requests and transcript questions peak at registrar@, and principal@ carries the correspondence a school year closes on.
How claiming an address would work
A conversation first, then a founder-confirmed step
Nothing on this page is self-serve today, and we are not going to pretend otherwise with a signup button that leads nowhere.
The honest path is: an office tells us roughly how many people send mail and which role addresses it wants, we confirm the tier that fits (team or organization, below), and turning those mailboxes on is a founder-confirmed step from there. No card is requested at any point in that exchange.
That is slower than a self-serve product would be. It is also the accurate description of where this product is today, and this page is not going to say otherwise to look further along.
Moving in, without a flag day
Five steps, and an office can stop after any of them
None of this is automated. Each step is a decision an office makes at its own pace, not a migration we run for you.
Step 1
Name the addresses
The office decides which role addresses it actually wants -- not every school needs all eight from the table above. A small building might start with office@ and attendance@ alone.
Step 2
Confirm the tier
Team fits a single building's set of role addresses. Organization fits a district running many buildings on one set of tiers. Either way, this is a conversation, not a self-serve form.
Step 3
Forward before cutting over
The honest first move for an existing personal account is a forwarding rule and an away-note, not a flag-day switch. Mail keeps arriving at the old address while the new one comes online.
Step 4
Staff learn the new address on live mail
A role address earns trust the same way any address does: by being on the reply line for a while, so a family's saved contact updates on its own instead of by memo.
Step 5
Retire the personal account from official use
Once the branded address is the one families actually reply to, the personal account stops being where official correspondence lives. We do not automate this step; the office decides its own pace.
The roster connection, said honestly
Not tied to the district roster yet
campus.software already imports a district roster for its own use -- buildings, staff, and grades. It would be a natural source list for which role addresses a district wants: one row per building office, one per athletics program, and so on.
That connection is not built. Creating mailboxes from a roster automatically is a real idea and an honest-off one; today, provisioning a role address is a manual, founder-confirmed step regardless of whether a district also runs campus.software. We are naming the idea here so a reader does not assume it already works.
A branded address next to a personal one
We are not going to name another company. The comparison that matters is structural: how a personal account handles an office’s mail, next to how a branded address on the school’s own domain handles it.
| The question | A personal account | A branded mailbox here |
|---|---|---|
| The name on the reply | A personal handle on a free provider's domain. | The school's own name, on every message. |
| Who owns the address | Whoever created the account, personally. | The office. It is a role, not a person. |
| When that staff member leaves | The thread history usually leaves too. | The address is handed over. History stays with the office. |
| Covering a mailbox while someone is out | Password sharing, or nothing. | A role address is covered by whoever is in. |
| How it looks on district paperwork | A personal domain that does not match the vendor of record. | An address that matches the office it names. |
| A family's trust signal | A personal or generic address for something official. | An address that matches the school's own name. |
| What happens to contact details | Terms vary. Often read for ad targeting. | They stay on our own private system. Never sold. |
| Storage for old correspondence | Shared with a personal account's own mail and photos. | Storage per mailbox, listed on each plan. |
| Sender authentication | Set by the provider, not by the school. | Not asserted here (see What is honest-off below). |
What comes with a mailbox
Where a year of correspondence actually lives
An office answers the same handful of questions every year. The value is in still having last September’s answer in April.
Storage per mailbox
Every plan lists storage per mailbox in the pricing below. A year of attendance threads or activity permission notes is exactly the kind of record an office wants to still have in June.
Correspondence stays where the office can find it
A role address keeps its own thread history in one place, instead of scattered across whichever staff member's personal account happened to answer first.
Nothing is sending or receiving on this domain
campus.email publishes no mail-exchanger record, so the domain accepts no mail, and no mailbox is provisioned on it. Everything on this page describes the address a school would claim, not an inbox that exists.
No compliance certification claimed
We do not label this a legal record-retention system or claim a specific regulatory certification. It is correspondence storage, described plainly, not a compliance product.
The other reason an office keeps mail on its own address
Correspondence a public office may have to produce
A public school or district office sometimes has to locate and answer a request for its own correspondence. That is easier when the correspondence lives on an address the office controls than when it is scattered across whichever personal accounts staff happened to use.
We are not going to call this a compliance product or claim a specific legal certification -- it is not one, and this page will not pretend otherwise. What we can say plainly: a role address keeps a year's worth of a given kind of correspondence in one place, which is a real, practical advantage when that correspondence needs to be found again.
That is the honest version of the claim, and it is the only version on this page.
What happens to the contact details
Families and staff, not a marketing list
The people writing to a campus.email address are families and staff, not customers being prospected. Their contact details are the office's own business, not ours.
Those details stay inside our own private system. They are not handed to an outside marketing company and they are not sold.
We are not going to dress that into an absolute. Mail is delivered to other people, by design, every time someone at the office presses send.
One boundary worth stating plainly. A message answered from a role address may name a student -- an attendance note usually does. This product does not add a roster, a gallery, or a face-match capability to that mail. It is the same office correspondence a school already sends, now carrying the school's own address instead of a personal one.
Security, said at the level we can actually stand behind
What we can promise, and what we are honestly not claiming
The address belongs to the office
A role address is owned by the job, not the person holding it this year. Handing off coverage does not mean handing off a personal password.
Single sign-on is honest-off
District-wide single sign-on for staff is in wiring across the Campus family, not live. campus.software states the same status for itself; this page states it here rather than imply otherwise.
No deliverability status asserted
We do not claim SPF, DKIM, or DMARC is live or drafted for this specific domain. campus.email sits outside the fleet's measured anti-spoof audit scope, so this page makes no record claim for it.
No inbox-placement promise
Nobody can promise a message lands in the inbox rather than a spam folder. Placement is decided by the receiving side, message by message, and we say so plainly.
What is actually true about the domain
No transport, and no accounts
Two different questions, kept separate on purpose: is the domain able to receive mail at all, and is any specific mailbox on it turned on. Today the answer to both is no. What is real here is the name, the page, and a price book we will stand behind when there is something to sell.
Mail transport is not provisioned
campus.email publishes no mail-exchanger (MX) record, so the domain does not accept mail. No MTA or DKIM signing is provisioned for it. That is a transport-level fact about the domain, not a claim about any specific mailbox. Not provisioned
Account provisioning is a manual step
Turning on a specific mailbox for a school or district is a founder-confirmed step, and it is currently off. Nothing on this page creates an inbox. Currently off
Billing
There is no checkout, no cart, and no card on file. Every figure on this page is a catalog display figure, never a charge. Checkout closed
Moving in from an old account
Forwarding plus an away-note is the honest first move. There is no automated import or archive transfer built, and we are not going to imply otherwise. Not built
Who this page is for
A district office or a high-school administrator, specifically
This page is written for the person who owns a school office's or a district office's correspondence today -- deciding whether it keeps riding on personal accounts or moves onto the school's own name. It is not written for a parent, a student, or a single classroom teacher.
A teacher who wants one professional address of their own is better served by educator.email's solo tier -- a single-seat plan, not the multi-seat office tiers this page prices.
An elementary school and its families looking for the warm, community-facing side of the platform belong on homeroom.software, a sibling brand tuned for that audience. This page stays institutional and operational throughout, the same register campus.software and campus.management use.
What a mailbox would cost
Catalog figures for planning. Not a price you are charged. Every plan is per mailbox, monthly, with storage included.
Team $2.50 per mailbox / month
Catalog price — not a charge
Includes 5 mailboxes · 25 GB each.
A small set of on-brand school addresses for a department or office.
At the included 5 mailboxes, that is about $12.50 / month at catalog rates — an estimate, never billed.
Organization $2.00 per mailbox / month
Catalog price — not a charge
Includes 25 mailboxes · 50 GB each.
School-wide branded mailboxes with shared routing and archiving.
At the included 25 mailboxes, that is about $50.00 / month at catalog rates — an estimate, never billed.
A single school office running its own role addresses usually starts at the team tier. A district-wide rollout across many buildings tends to look at the organization tier. Both figures are catalog, and neither is a charge.
Worked examples, computed from the same catalog above
What a few illustrative office sizes would see
Every figure below is computed live from the SAME price-book estimator the plan cards use, not hand-typed. The seat counts are illustrative office sizes, not a claim about any real school or district.
| Illustrative office | Tier | Seats | Per mailbox | Monthly total |
|---|---|---|---|---|
| A small building's office (5 role addresses) | Team | 5 | $2.50 | $12.50 / month |
| A larger high school (10 addresses) | Team | 10 | $2.50 | $25.00 / month |
| A district office plus 3 buildings (25 addresses) | Organization | 25 | $2.00 | $50.00 / month |
| A mid-size district (50 addresses) | Organization | 50 | $2.00 | $100.00 / month |
| A larger multi-building district (100 addresses) | Organization | 100 | $2.00 | $200.00 / month |
The organization tier’s included-mailbox floor and per-mailbox rate are the same figures the plan cards above read from mailbox/pricebook.ts -- this table simply runs the same estimator at a few more seat counts.
What’s true today
Catalog prices, not a charge
We show these figures so an office can plan a budget, not because a card can be charged right now.
There is no buy button on this page and no signup that bills. Turning a mailbox on is a founder-confirmed step and it is currently off.
- Prices shown are catalog estimates, not a charge -- checkout is not open yet.
- Mailbox provisioning is a founder-confirmed step and is currently off; no mailbox is created and no card is billed.
- A branded address is a professional mailbox, not a claim that any specific school or studio uses it.
Nothing on this page creates a mailbox or moves a cent. When that changes, the page will say so in the same plain words.
What this is not
A page that only lists what a product does is half a page. Here is the other half, so an office can rule this out quickly if it is the wrong fit.
Not a student information system
This is correspondence, not enrollment records or grades. campus.software is the platform that covers roster-driven school operations.
Not the newsletter broadcast
communications@ answers one family's question. It has no distribution list. Sending to a whole family list is schoolnews.email's job, not this page's.
Not an operations console
There is no season calendar, no retake list, and no order rollup here. campus.management covers that work.
Not a single sign-on provider
District-wide single sign-on for staff is in wiring, not live. We say so on this page rather than let a reader assume it already works.
Not an automated migration tool
We have not built an import from an old provider or an archive transfer. Forwarding plus an away-note is the honest first move.
Not a deliverability guarantee
No provider can promise inbox placement, and we make no SPF/DKIM/DMARC status claim for this domain either way.
Not live yet
Checkout is closed and provisioning is off. The address is unclaimed. We would rather write that here than bury it in a footnote.
Questions an office asks first
Can our office claim an address today?
Not yet. Checkout is closed and provisioning a specific mailbox is a founder-confirmed step that is currently off. Ask through the contact form -- nothing is charged and nothing is reserved by asking.
Is campus.email already used by a school or district?
No. No school or district is named, implied, or counted as a user. The address is open to claim.
What does the price include?
A per-mailbox monthly catalog rate, a set number of included mailboxes, and storage per mailbox -- all listed on each plan card below. Every figure is display-only, never a charge.
Is Campus Mailboxes the same product as campus.software?
No, but it is the same platform. campus.software is the institutional platform pitch to a district -- roster-driven picture day, athletics, student IDs, the yearbook pipeline. This page is one address: the office mailbox.
How is this different from campus.management?
campus.management is the operations console that runs a picture-day season across every building. This page has no season calendar and no order rollup -- it is correspondence, not operations.
How is this different from schoolnews.email?
schoolnews.email is the family-facing newsletter broadcast a school newsroom sends to a distribution list. [email protected] answers one family's question. Different job, no shared list.
How is this different from educator.email?
educator.email is a single teacher's own solo-tier address. This page is the school persona, multi-seat, for an office that needs several role addresses at once.
What is a role address, and why does it matter?
An address tied to a job, not a person. office@, attendance@, athletics@ and the rest. When the person covering one changes, the address and its history stay with the office.
Can more than one staff member cover the same address?
That is the design intent: a shared role address is covered by whoever is in, so a family's reply does not depend on one person being at their desk.
Are SPF, DKIM, or DMARC live for this domain?
We are not asserting a status either way on this page. The fleet-wide anti-spoof audit covers a specific set of program-bound *.email hosts and campus.email is not one of them, so this page makes no DNS-record claim for it at all rather than guess.
Does this connect to our student roster automatically?
Not yet. campus.software already imports a district roster for its own use; this mailbox is not tied to that roster automatically. Creating role addresses today is a manual, founder-confirmed step.
Is single sign-on available for staff?
Not live. District-wide single sign-on is in wiring across the Campus family, the same honest-off status campus.software states for itself. We say the same thing here rather than imply it is further along on this page.
Does any student data move through this product?
A message answered from an office role address may name a student, the same as any school correspondence does today. This product adds a domain and a role address to that mail -- it does not add a roster, a gallery, or a face-match capability. None of those exist here.
Will you migrate our old mail for us?
No. There is no automated import or archive-transfer capability built. Forwarding plus an away-note from the old account is the honest first move while a new address is set up.
Do you promise messages land in the inbox?
No. Nobody can promise that; placement is decided by the receiving side, message by message. We describe what a branded address gives you -- an identity that matches the school -- and stop there.
What is the minimum for a district-wide rollout?
The organization tier is built for that scale and is priced per mailbox with a larger included count. Talk to us for a district-wide conversation -- no card is charged during that conversation.
Does this replace our whole email system, or add to it?
It adds branded role addresses on the school's own domain. This page does not describe replacing an entire staff mail system in one step, and the rollout above is deliberately staged, not a flag-day cutover.
Can a photography studio partner use a campus.email address?
The addresses here belong to the school or district office, not to a vendor. A studio partner working with a district would use its own address, the same honest separation the rest of the platform keeps between institutional and vendor roles.
Is the office@ example address a live inbox we can email?
No. Every address shown on this page, including [email protected] in the hero panel, is illustrative. None is a live inbox, and mail sent to it is not read by anyone.
Why does this page use its own header instead of the wider platform's navigation?
campus.email is a branded webmail surface, the same chrome pattern the rest of the .email family uses. Its only action is a question, not an account signup, so it does not need the shared platform navigation.
Who actually decides which role addresses we get?
The office does. The eight addresses on this page are illustrative of the shape a school or district typically wants, not a fixed menu every building must take in full.
Is this the right page for an elementary school?
This page is written for a district or high-school office, institutional in voice throughout. An elementary school and its families are better served by homeroom.software, a sibling brand tuned for that audience.
The rest of the Campus family
Campus Mailboxes is the office’s inbox. The rest of the family covers picture day, operations, and the family storefront. They are separate products on one shared platform, and none of them pretends to be another.
campus.software
The institutional platform pitch to a district: roster-driven picture day, athletics, student IDs, and the yearbook portrait pipeline.
campus.management
The operations console that runs the picture-day season across every building -- the season calendar, staff roles, and the order rollup.
campus.photos
The family storefront on the same platform, where a parent finds a child's photo and orders. This page never addresses a family directly.
homeroom.software
The community-facing sibling brand for elementary schools and their families, on the same engine, roster model, and consent gate.
k12.photos
The school-photography property the wider platform is built around -- the home for how picture day works across the K-12 estate.
Asking a question
The only action on this page is a question. It does not reserve an address and it does not create an account.
Tell us the school or district, roughly how many people send mail, and which role addresses you would want. That is enough to have a useful conversation.
No card is requested at any point in that exchange. There is no advertised response time, because we are not going to invent one.
What is real and what is honest-off
Real today. The domain is owned and this page is real. The catalog is a committed price book, and the figures above are read from it. The address is unclaimed and we say so.
Off today. The domain publishes no mail-exchanger record, so it accepts no mail: nothing is being sent or received at campus.email. Checkout is closed. Turning on a specific mailbox is founder-confirmed and currently off. No mailbox is created and no card is billed.
Not asserted. SPF, DKIM, or DMARC status for this specific domain -- it sits outside the fleet's measured anti-spoof audit, so this page makes no record claim for it either way.
Not built. Automatic roster-to-mailbox provisioning, single sign-on, automated mail import, and archive transfer. Each is described plainly as not built where it is mentioned above.
Never claimed. Inbox placement, a school or district already using this address, or a student roster, photograph, or face match passing through this product. None of those is true, so none of those is on this page.