How to use this email server requirements checklist
This checklist is for teams replacing or building mail, calendars and contacts without a platform chosen yet. The requirements below are the baseline you turn into verifiable tests before you pick Stalwart, mailcow, OX App Suite or any other option. Each requirement is grouped under one of five headings: functional, security, integration, operations and compliance. Functional items cover mailboxes and storage, protocols such as IMAP, JMAP and ActiveSync, calendars and contacts. Security items cover SPF, DKIM and DMARC, spam and malware filtering, and transport encryption. Integration items cover directory, identity and client connectivity. Operations items cover deliverability and IP reputation, backup, high availability and migration from the current provider. Compliance items cover archiving and retention. Every requirement carries a verification step, such as a DNS lookup, a test message to a major external provider, a restore from backup or a timed mailbox move, so that a yes or no answer can be recorded and reviewed by the people who sign it off.
Regulated organizations need to read the compliance group first, because retention and audit obligations change what the mail server must record and for how long. For example, a broker-dealer must preserve business communications under SEC Rule 17a-4(b)(4), and a covered entity handling ePHI must meet the audit control requirement in 45 CFR 164.312(b). Confirm with your compliance and legal teams which rules apply to your entity and which records must be kept outside the mailbox server, because the mail platform alone is rarely the record. Treat this checklist as the shared baseline for the sibling pages on archiving and retention, deliverability with SPF, DKIM and DMARC, and migration. Those pages go deeper on one area each. Use this page to decide what you must verify, then use the sibling pages to design how each item will be met.
Which functional requirements must a self-hosted email server meet
This table lists the day-to-day functional requirements a self-hosted mail platform must meet, with a verification step for each. Read the verification column as the test you run before choosing a platform, because protocol and calendar support differs between Stalwart, mailcow and OX App Suite and must be confirmed in each candidate's documentation and a proof of concept.
| Requirement | Why it matters day to day | How to verify before you commit |
|---|---|---|
| Mailboxes, quotas and storage growth | Users notice full mailboxes and slow folders first. Quotas set per user, per group or per domain determine how fast the store grows. | Build a storage growth model from your expected mailbox count, average message size, attachment share and retention period, then load test with that data volume. |
| IMAP, JMAP and ActiveSync | IMAP is the baseline for desktop and most mobile clients. JMAP is newer and suits modern clients. ActiveSync covers many phones that do not speak IMAP well. | Confirm each protocol in the vendor documentation, then test folder sync, push, search and flag changes across the client matrix. |
| CalDAV and CardDAV | Calendars and contacts must sync across desktop and mobile clients without manual exports, and they must survive client upgrades. | Create, edit and delete events and contacts from each client, then check that changes appear on the other devices within the same session. |
| Shared mailboxes and resource booking | Support, finance and facilities teams need shared inboxes and rooms or equipment that users can book without an administrator. | Check whether the platform supports delegated access, send-as rights and resource calendars, then test permissions with a non-admin account. |
| Free/busy lookup | Scheduling across users and resources depends on free/busy data being visible across accounts and, where needed, across domains. | Book a meeting between two users on different domains and confirm free/busy times display correctly in both clients. |
| Aliases and catch-all handling | Role addresses, legacy addresses and catch-all rules control where mail lands. Catch-all also attracts spam if left unmanaged. | Document every alias and catch-all rule, send test mail to each, and confirm that unknown recipients are rejected or routed as policy requires. |
| Multi-domain hosting | Subsidiaries, brands and acquired domains often need separate address spaces on one platform with separate policies. | Add a second domain in a lab, configure its DNS and check that addresses, policies and DKIM keys stay separated per domain. |
| Client and device test matrix | Protocol support varies by platform and by client version. A feature that works in one client can fail in another. | Test at least Outlook, Apple Mail, Thunderbird, Gmail's IMAP client, and the native iOS and Android mail, calendar and contacts apps your users run, on the versions you will support. |
How Stalwart, mailcow and OX App Suite differ against the same requirements
Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV in one product. It is licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs, and the latest release supplied for this page is v0.16.26, published on October 11, 2026. Because mail, calendar, contacts and file access share one server, the platform team deploys a single service stack rather than assembling separate groupware components.
- Protocol coverage: IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV are the listed protocols, so the requirements for mailboxes, calendars and contacts can be checked against one product.
- Licensing: The AGPL-3.0 license applies to the community build, and the Enterprise License is optional. Confirm with Stalwart Labs which features sit under each license before committing.
- Deployment footprint: The platform is a self-contained server, so the infrastructure is simpler than a multi-service groupware suite. Confirm supported storage backends, clustering and high availability options against the current documentation.
- Filtering and authentication: Confirm which spam filtering, DKIM signing, DMARC reporting and archiving functions are built in and which need external components.
- Mobile and client support: Confirm which ActiveSync or other mobile sync methods are supported, since the supplied facts list IMAP, JMAP, CalDAV and CardDAV but not ActiveSync.
Check each requirement on the checklist against the current Stalwart release notes and the Enterprise License terms before treating the platform as a match.
mailcow-dockerized packages a complete mail stack as Docker containers, and it is licensed under GPL-3.0. The latest release supplied for this page is 2026-09a, published on October 6, 2026. The design centers on a single-host Docker Compose deployment, so the platform team manages a stack of containers on one or a small number of servers rather than a Kubernetes cluster.
- Deployment model: The project is delivered as a Docker-based installation, which suits teams that already operate Docker hosts and want a single-server footprint.
- Groupware: Confirm the calendar and contacts components bundled in the current release, since the supplied facts do not list the specific groupware package for this page.
- Protocols: Confirm IMAP, SMTP, ActiveSync and CalDAV or CardDAV support in the release you plan to run, and confirm whether JMAP is offered.
- Infrastructure: The main requirements are Docker hosts, persistent volumes, backup storage and a reliable public IP with correct reverse DNS. Confirm the minimum host sizing with the project documentation rather than assuming it.
- High availability: A single-host design needs a separate plan for failover, backup restore and mail queue handling during outages. Confirm what the project supports natively and what the operator must build.
Verify these points against the checklist items for backup, high availability and archiving before shortlisting mailcow for a regulated workload.
OX App Suite v8 is a groupware suite designed to run on Kubernetes and delivered as Helm charts that reference container images. The current LTS release is v8.47 (FCS 2026-03-18), and the newest listed release is v8.53, first shipped on 2026-09-23. Open-Xchange publishes the App Suite UI and middleware code on GitHub under AGPL-3.0, but the right to use certain modules or features may be subject to custom packaging, limitations or separate fees set in the license agreement, so the license terms must be read alongside the code.
- Platform requirements: Helm 3.17.0 or newer, a supported Kubernetes version (N-1 or N-2), and either Istio (latest release plus two prior versions) or the basic ingress-nginx option where Istio cannot be used.
- Data stores: Redis 7.4.x for caching and sessions, deployed by default through the littlered operator, and MariaDB with InnoDB, in supported versions 10.6.x, 10.11.x, 11.4.x or 11.8.x. Galera Cluster is supported.
- File storage: Persistent data such as OX Drive files and PIM attachments requires a distributed file system, NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones.
- Release planning: A standard release is supported for 12 weeks, and an LTS release is supported until the next LTS plus six months. Plan upgrades around the LTS line.
- Identity: OpenID Connect and SAML integration are documented, so confirm the exact identity setup with Open-Xchange for your directory.
Because the stack is larger than a single-host mail server, confirm the full bill of materials, licensing and support terms in writing before comparing it with the other two options.
Which security and authentication controls a self-hosted mail platform must provide
A self-hosted mail platform is only as trustworthy as the controls around it. Sender authentication, encrypted transport, access control, filtering and retention all have to hold together, or messages get spoofed, intercepted or lost. The cards below describe what to verify in each area before go-live.
Sender authentication alignment
SPF, DKIM and DMARC protect your domain from spoofing only when they agree with each other. SPF must list the servers that send for the domain, DKIM must sign outbound mail with a published key, and the DMARC policy must align with the visible From address. Check each outbound stream, including application notifications, scanners and any smarthost, because a single unsigned sender can fail alignment and damage reputation for the whole domain.
Enforced transport encryption
Require TLS for client submission, IMAP and SMTP relay, and decide explicitly whether opportunistic encryption to external servers is acceptable for your data. Confirm certificate chains, disable legacy protocol versions and test how the platform behaves when a remote server refuses TLS. For regulated mail, the policy must be enforced at the server, not left to client settings.
Admin and user access control
Confirm that the platform supports multi-factor authentication for webmail, administrators and API access, and that admin roles can be split so no single operator can change retention, mail routing and audit settings alone. Verify that administrative actions and mailbox access are written to audit logs that you can export to a central log platform. Ask the vendor or partner which of these features are in the edition you are considering.
Malware and phishing filtering
Inbound filtering should combine content scoring, attachment scanning, sender reputation checks and link protection, with a documented process for quarantine release and false positives. Confirm how the filter is updated, who owns signature and rule updates in an offline or restricted network, and how phishing reports from users reach the security team. Test the chain with known-bad samples before relying on it.
Retention for broker-dealer records
SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications received and copies of those sent relating to the business for not less than three years. The mailbox server rarely meets that alone, so confirm that journaling copies every relevant message to a separate archive with immutable storage, legal hold and search. Ask the partner which retention periods and storage options you must configure, and have your compliance team sign off on the design.
HIPAA transmission and audit controls
45 CFR 164.312(e)(1) requires technical measures that guard against unauthorized access to ePHI sent over electronic networks, and 164.312(b) requires audit controls that record and examine activity in systems holding ePHI. For mail, verify enforced TLS for external messages, mailbox access logging, and a way to review those logs on a schedule. DeployOpen prepares configuration, control mapping and evidence for your assessments but does not issue audit reports or attestations.
Why deliverability and IP reputation decide whether self-hosted mail gets read
A mail server can meet every functional requirement on this checklist and still fail its users if messages land in spam or are rejected by large providers. Deliverability is a requirement in its own right, and it has to be verified before any mailbox moves. Start with the basics that every receiving server inspects: the reverse DNS record for the sending IP must resolve to the mail host name, the TLS certificate on the submission and SMTP ports must be valid for that name, and the SPF record for each sending domain must list every server that sends on its behalf, including any web application or scanner that relays through your domain.
Next, verify DKIM and DMARC as a set. Confirm who generates the DKIM signing keys, where the private keys are stored, how they are rotated, and that each sending domain publishes the matching public key. Then check DMARC alignment, which requires the domain in the visible From address to match the domain that passes SPF or DKIM. Publish a DMARC policy, start with monitoring, and read the aggregate reports for legitimate senders you have missed before you tighten the policy. Decide whether the outbound IP is clean enough to send directly, or whether a smarthost relay is needed. A relay changes who controls your sending reputation, so ask for that decision in writing.
Reputation is built over weeks and months, not during a test, so a new sending address has little history to draw on. Plan a gradual ramp of outbound volume, and monitor results through the postmaster tools that large providers offer for domains and IP addresses, together with your DMARC reports. Ask any candidate partner how they protect sender reputation, how they detect a listing on a DNS blocklist, who requests delisting, and how long a listing is allowed to affect production mail. The detailed setup and provider rules are covered on the self-hosted email deliverability page, so use this section to confirm ownership and evidence rather than configuration.
How email connects to identity, directories, archives and other workplace tools
A mail server rarely runs alone. Its accounts, sign-in, outbound relay, archive, file storage, calendars and monitoring all depend on other systems, and each link is a place where requirements can fail. The cards below name the question to answer for each connection before the platform is chosen.
Directory and single sign-on
Decide whether mailbox accounts are created from LDAP or Active Directory, who disables them on leaving, and whether users sign in through OpenID Connect or SAML. Open-Xchange documents OpenID Connect and SAML operator guidance for OX App Suite, but that documentation does not confirm how your directory schema will map. Ask the platform owner which attributes sync, how group membership drives mailbox access, and what happens to sessions when the identity provider is down.
SMTP relay for applications and scanners
Scanners, line-of-business systems and monitoring tools often send mail through an internal relay with no user login. Confirm which hosts may relay, whether they authenticate by IP address or by credential, and how their messages are signed so they pass SPF, DKIM and DMARC checks. Application mail should use a separate sending identity so a misconfigured report does not damage the reputation of your primary domain.
Journaling to an external archive
Where retention rules apply, every inbound and outbound message may need a copy sent to a separate archive at the time of delivery. Ask whether the mail platform can journal all messages, including those sent between internal mailboxes, and whether the archive can prove the copy is complete. Also confirm how legal holds and deletions in the mailbox interact with the archived copy.
File storage and attachment integration
OX Drive files and PIM attachments are stored on a distributed file system: NFS for small to mid-size deployments, or object storage such as AWS S3, Ceph RadosGW or Scality RING for larger ones. Confirm which option your design uses, how attachment storage is backed up with the mailbox database, and how links to shared files are kept consistent when a file is moved or deleted.
Calendar and groupware interoperability
Calendars must work with the desktop and mobile clients your users already run and with any other groupware still in use during migration. Test free/busy lookups, resource booking and meeting invitations sent between your platform and external organizations. Check which protocols each client uses, since native support differs between CalDAV, ActiveSync and vendor sync methods.
Logs and SIEM export
Authentication events, mailbox access, administrative changes and filter decisions need to reach your security monitoring platform in a form it can parse and retain. Ask which log sources the mail platform produces, whether they export over syslog or another standard transport, how timestamps are synchronized, and how long logs remain in the mail host itself. Healthcare and financial services scenarios depend on these records, so confirm the format before procurement.
Which operational requirements keep self-hosted email reliable after go-live
This table compares the operational requirements that keep a self-hosted mail platform dependable once it is live, with a verification method for each. Use it to turn general reliability goals into tests you can run before cutover and repeat afterward. Recovery targets, availability commitments and support levels must come from your own requirements and the written scope, not from this page.
| Requirement | What it asks for | How to verify it |
|---|---|---|
| Backup and restore | Mailbox-level restore for single users and full-system restore for the mail server, database, configuration, DKIM keys and mail storage, kept in a separate location from production | Run scheduled restore drills into an isolated environment, restore a sample mailbox and a full stack, and time each drill against the recovery targets you set |
| High availability and failover | Redundant SMTP and IMAP entry points, a database failover design (replication or clustering), and shared or replicated mail storage so a node loss does not stop mail flow | Test node loss and database failover under realistic load, confirm inbound mail queues and active IMAP sessions recover, and record how long each step takes |
| Upgrade and patch process | A staging copy of the production stack, a documented change window, pre-upgrade backups, and a tested rollback path for both application and schema changes | Apply the update to staging, run mail flow and client tests, then perform a rollback on staging and confirm mailboxes and queues are intact |
| Monitoring and alerting for queues and deliverability | Alerts on SMTP queue depth and age, bounce and deferral rates, blocklist status of sending IPs, TLS failures, disk and storage growth, and DMARC report volume | Inject test messages on a schedule, trigger a queue backlog in staging to confirm alerts fire, and review alert routing with the on-call team |
| Capacity planning for storage growth | Growth forecasts for mailbox counts, average mailbox size, attachment volume and archive copies, with headroom reviewed on a fixed schedule | Compare actual storage growth against the forecast each month, and load test indexing and backup duration as the mailbox count grows |
| Vendor support and release lifecycle | A supported release for each platform component. OX App Suite standard releases are supported for 12 weeks, and OX LTS releases are supported until the next LTS release plus six months, so plan upgrades around those windows | Confirm the current support status of each component with the vendor in writing, map each upgrade to the support window, and schedule a test upgrade before any support end date |
How to move mailboxes from the current provider without losing messages
This sequence moves mail, calendars and contacts from a hosted provider to a self-hosted platform in controlled waves, with a message count checked at each stage. The result is a cut over mail domain, a verified archive of historical mail, and an old tenant retired only after retention obligations are met.
Inventory domains, mailboxes, aliases and holds
Your mail administrator lists every domain, mailbox, shared mailbox, alias, distribution list, calendar and contact book in the current tenant, and records which mailboxes sit under legal hold or retention policies. The output is a signed-off inventory with owners and a count per mailbox type. Confirm with your chosen platform's documentation which of these object types its migration tooling can carry over, because shared mailboxes and delegated permissions are often handled differently.
Plan DNS and coexistence routing
The team maps how inbound and outbound mail will route while both systems run, including which domains point to the old provider, which point to the new server, and how calendar free/busy lookups work between them. The output is a written routing design and a DNS change plan with the current TTL values recorded. Confirm coexistence options and any required connectors with the platform vendor before changing any record.
Run a pilot with test mailboxes
Create a small set of test mailboxes on the new platform and move them first, then check sending and receiving to external providers, calendar invitations, shared calendars and contact sync on each client your staff use, including mobile devices. The output is a pilot report listing each client and protocol that passed, and each defect with an owner. Do not proceed to production waves until the pilot report is signed off.
Migrate historical mail in verified waves
Migrate mailboxes in waves, copying historical mail, calendars and contacts for each group, then compare the message count per folder between source and target before the wave is closed. The output is a per-wave reconciliation record showing source and target counts and any gaps explained and resolved. Keep the source copy intact until the reconciliation for that wave is accepted.
Cut over MX, SPF, DKIM and DMARC with monitoring
Change the MX record to the new platform, publish the SPF record that authorizes the new sending hosts, install the DKIM public key for the new signing selector, and confirm the DMARC policy and reporting addresses still align. Monitor delivery logs, bounce rates and DMARC aggregate reports for a period agreed with your team. The output is a cutover record with timestamps, test messages that passed authentication, and a named owner for any rollback decision.
Retire the old tenant after read-only and final export
Place the old mailboxes in a read-only state for a period your legal and records teams agree, then export a final archive of mail, calendars and contacts that the retention rules require you to keep. The output is a verified export with checksums and a sign-off that retention obligations are satisfied before licenses are removed. Confirm with compliance counsel how long the archive must be retained and where it will be stored.
What buyers ask before hiring help to build a self-hosted email platform
How much does a self-hosted email project cost?
No single figure applies, because the total depends on the mailbox count, the storage profile, the platform you choose and how much of the work is done in-house. The main cost components are the servers or cluster capacity in your own cloud or data center, the storage for mail and attachments, an outbound relay or clean sending IP addresses if your own addresses cannot build reputation, spam and malware filtering, archiving, backup, migration of existing mailboxes and the administration time that deliverability and monitoring take after go-live. Open-source platforms carry no license fee in the base case, but OX App Suite licensing may be subject to custom packaging, limitations or separate fees set in the license agreement. Ask any implementation partner for a written, fixed-scope quote that lists each component, marks which costs are one-time (build, migration, integration) and which recur (hosting, support, upgrades, relay and filtering subscriptions), and states your assumptions about mailbox count and retention.
Can our own team run a self-hosted mail server without outside help?
Many teams can run a small mail server with existing staff, but the work is more than installing software. Operating a mail platform requires skills in DNS, TLS certificates, SMTP routing, IMAP or JMAP access, spam and antivirus tuning, backup and restore testing, and patching on a fixed schedule. Deliverability also needs ongoing attention: SPF, DKIM and DMARC records must stay aligned, reverse DNS must match, and blocklist and reputation signals must be watched. Regulated firms add retention, audit logging and access review. Before deciding, ask who will own the on-call rota, who reviews DMARC reports, and who tests restores. A partner can cover the build, hardening and documentation, and then support you through a retainer, so your team keeps control of the operation.
How long does a self-hosted email rollout take?
The timeline depends on the scope you agree in writing, not on a fixed template. The main drivers are the number of domains and mailboxes, the size of the existing mail estate and how much history must move, the directory and identity integration you require, whether a separate archive is needed, the number of test users and decision owners available, and the change windows for DNS and mail routing. Parallel-run and coexistence periods add time but reduce cutover risk. Ask any partner to break the plan into phases with named deliverables, sign-off points and a cutover plan, and to state which items depend on your teams, such as DNS changes or identity access. Avoid any plan that promises a date without first reviewing your domains, mailboxes and retention policy.
What do we need to provide before a mail project starts?
Preparation shortens the discovery phase and reduces the risk of surprises at cutover. Typically you need administrative access to the DNS zones for every domain, read access or an export plan for the current mail provider, and a list of directory sources and groups if mailboxes will sync with your identity system. You also need a written retention policy, including which mail must be kept and for how long, and a decision on who owns legal hold and eDiscovery requests. Name test users from several departments, plus a technical owner for mail flow, a security owner for filtering and logging, and an executive sponsor who can approve cutover. Confirm these items with your legal, records and security teams early, because retention and archiving requirements often change the architecture.
Should we choose OX App Suite, Stalwart or mailcow?
The choice depends on your scale, your need for a groupware suite, and your licensing position. Stalwart is an all-in-one mail and collaboration server that supports IMAP, JMAP, SMTP, CalDAV, CardDAV and WebDAV. It is licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs. mailcow-dockerized is licensed under GPL-3.0 and packages a Docker-based mail stack. OX App Suite v8 is designed to run on Kubernetes, is delivered as Helm charts, requires Istio or a basic ingress-nginx option, uses Redis and MariaDB, and stores files on NFS or object storage. Its support follows a commitment with defined release lifetimes, and some features may be subject to separate fees. Ask each vendor which edition you would license, what support is included, and how upgrades are handled. Our team can compare these options against your written requirements.
Does a regulated firm need a separate archive for email?
In many regulated cases, yes. Rules such as SEC Rule 17a-4(b)(4) require broker-dealers to preserve originals of business communications received and copies sent for not less than three years, including inter-office messages. A mailbox server is built for delivery and access, not for long-term preservation with legal hold and search, so most designs journal messages into a separate archive. The HIPAA Security Rule, at 45 CFR 164.312, adds transmission security and audit controls for ePHI, which affects logging and encryption design. Confirm with your compliance and legal teams which records apply to you, how long they must be kept, and whether journaling, legal hold and eDiscovery are required before choosing the archive product.
How is deliverability protected after cutover?
Deliverability depends on several controls working together. Publish SPF records that list your sending sources, sign outgoing mail with DKIM, and set a DMARC policy that you move toward enforcement only after reviewing aggregate reports. Reverse DNS should match the sending hostname, TLS should be enforced for transport, and the sending IP address reputation must be monitored. If your own address space is new or shared, a smarthost relay may be needed, which adds a recurring cost. After cutover, watch DMARC reports, postmaster tools from major providers, blocklist status and bounce rates for at least the first several weeks. Ask any partner how they will test sender authentication before cutover and who responds to a blocklisting.
How is a fixed-scope email engagement agreed?
A fixed-scope engagement starts with discovery, then a written scope that lists the platform, domains, mailbox count, integrations, migration approach, archiving design, testing, cutover and handover deliverables. The agreement should also name assumptions, client dependencies such as DNS access and decision owners, out-of-scope items and change control. DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted platforms in your own infrastructure, and prepares evidence for compliance assessments, but does not issue audit reports or certifications. DeployOpen does not publish a price list, so a quote follows from the written scope. Ongoing support, upgrades and continuous testing can be added as a retainer once the project closes.
How DeployOpen scopes, delivers and supports a self-hosted email platform
DeployOpen plans, implements, integrates, hardens, backs up, documents and supports self-hosted open-source mail platforms inside your own cloud accounts, data centers or air-gapped networks. We start from a written requirements baseline for mailboxes, authentication, filtering, archiving and migration, then build and hand over only what that baseline covers.
How we scope
- We record mailbox counts, domains, protocol needs such as IMAP, JMAP and ActiveSync, and calendar and contact requirements in writing.
- We document which DNS, SPF, DKIM and DMARC changes your team owns and which we prepare for you to apply.
- We agree retention, archiving and legal hold responsibilities in the written scope, so the mail server is never assumed to be the record.
How we build
- We deploy the chosen platform, such as Stalwart, mailcow or OX App Suite, into your environment and configure authentication and TLS.
- We set up filtering, DNS blocklist handling and anti-malware checks and tune them against a test mailbox set before cutover.
- We test mailbox migration samples, backup and restore, and failover behavior against the requirements baseline.
How we hand over
- You receive configuration records, DNS and DKIM key inventories, runbooks for mailbox, queue and certificate tasks, and a test report.
- We document which controls and logs support your compliance readiness work, while your auditors make the assessment.
- Handover covers administrator training on the platform and a written list of open items agreed with your team.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer, scoped in writing after handover.
- We track vendor release notes and security updates for the platform and apply them under the agreed change process.
- Before you commit to a support tier, confirm response expectations, maintenance windows and escalation paths in the written agreement.

