Which email server RFP questions decide the partner you hire
When you replace or extend mail, the questions that separate one implementation partner from another are not about which server logo appears in the proposal. They are about sender reputation, migration without loss, archiving, and how incidents such as outages and blocklistings are handled. Any candidate can install a mail server. The difference shows in whether the partner can keep your messages reaching Gmail and Outlook, prove that every mailbox moved intact, and explain who acts when a sending IP lands on a blocklist at 2 a.m. Your RFP should weight those answers above feature comparisons.
Run the evaluation the same way for every bidder. Send one written question set to each partner, and require answers tied to your own environment: your domains, your mailbox count, your current provider, your retention obligations and your DNS and identity setup. Ask each bidder to name the people who will operate the system after go-live and the contractual response expectations for incidents. Score every answer against the same criteria, written before the responses arrive, and record why each score was given so that the decision can be defended to auditors and procurement.
Candidate platforms include Stalwart, mailcow and OX App Suite, and each fits a different profile. Stalwart is licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs, mailcow-dockerized is licensed under GPL-3.0, and OX App Suite is delivered as Helm charts for Kubernetes and carries its own support commitment and licensing terms. Confirm with each bidder which license applies to the modules you need, because the Operations Guide notes that some features may be subject to separate fees. The right server depends on scale, licensing and the operating model you choose, so ask partners to justify their recommendation against those three factors rather than against a preferred product.
Questions to ask about server choice, deliverability and operations
Which mail server would you recommend for our mailbox count, and why?
A credible bidder names one primary server and explains why, then names the alternatives it rejected. Ask for the reasoning in writing: protocol support (IMAP, JMAP, CalDAV, CardDAV), the admin model, and the licensing terms. Stalwart is an all-in-one server licensed under AGPL-3.0 with an optional Enterprise License from Stalwart Labs. mailcow-dockerized is licensed under GPL-3.0 and is built on containers. If you are considering OX App Suite, ask the bidder to explain how it runs the platform: OX App Suite v8 is delivered as Helm charts, so the bidder should describe its Kubernetes cluster, Helm 3.17.0 or newer, its Istio or ingress-nginx choice, Redis 7.4.x for caching and sessions, and MariaDB as the primary store, with the supported versions listed. Ask bidders to confirm licensing for individual modules, because Open-Xchange notes that some modules or features may carry custom packaging or separate fees set in the license agreement.
How will you protect our sender reputation and meet Gmail sender rules?
A good answer lists the specific records and checks, then shows who owns each one. Expect SPF, DKIM with key rotation, and a DMARC policy that moves from monitoring to enforcement only after reports are reviewed. The bidder should also cover reverse DNS, TLS for inbound and outbound connections, and a plan for IP warm-up if a new sending address is used. Ask whether a smarthost relay is part of the design and who holds its contract. Monitoring should include Google Postmaster Tools and aggregate DMARC reports, with named owners and a review cadence. Ask for a written test plan that sends to Gmail and Outlook test accounts before cutover and records the authentication results.
How do you tune spam filtering to cut false positives without letting threats through?
The answer should name the filtering components and the tuning process. Ask which scoring engine handles messages (Rspamd is a common choice), how attachments are scanned (ClamAV is a common open-source option), and whether greylisting and DNS blocklists are used. Good bidders describe a tuning loop: a baseline period, a quarantine with user release, a weekly review of false positives and misses, and a documented change log for every rule adjustment. Ask who reviews quarantined mail and how long it is kept. Also ask whether a commercial gateway in front of the server is recommended and what it would cost to run, since that is a separate recurring fee.
How do you migrate mailboxes from our current provider without losing mail?
A credible answer is a written runbook with stages: inventory of mailboxes, folders, calendars, contacts and shared resources, a pilot batch, a full sync with delta passes, and a cutover window with a rollback path. Ask how the bidder verifies counts and checksums per mailbox, how it handles mail that arrives during cutover, and how it moves calendars and contacts without breaking invitations. Ask for the coexistence plan: how mail routes between the old and new systems during the transition and how long the old tenant stays active. The bidder should name the migration tool and explain how it handles throttling by the source provider. Ask for the acceptance criteria in writing before the first batch moves.
How does archiving meet our retention rules, and what is stored where?
The mailbox server alone is usually not the compliance record. Ask the bidder to describe a separate archive fed by journaling or a similar copy mechanism, with the retention period set by your regulator or policy, not by the bidder. For example, SEC Rule 17a-4(b)(4) requires broker-dealers to preserve communications for not less than three years, and a bidder should show how that period is enforced. Ask how legal hold, search and export work, who holds the keys, and how the archive is backed up and tested for restore. Confirm whether the archive is included in the fixed scope or sold as a separate product, and what recurring storage cost it adds.
What happens during an outage or blocklisting, and who responds?
A good answer names the monitoring tools, the on-call roles, and the response steps for each failure type. For a blocklisting, the runbook should cover checking major DNS blocklists, identifying the cause, requesting delisting where the process allows it, and temporarily rerouting outbound mail through a clean relay. For an outage, ask about high availability design, backup frequency, restore testing and the target recovery approach. Ask whether the bidder offers a support retainer and what its response windows are in writing. Ask for a sample incident report and the post-incident review template. Do not accept a verbal promise: service levels must appear in the signed scope.
Can we run the platform ourselves after handover, and what does that require?
The answer depends on your team's skills and the platform you choose. Ask the bidder to list the runbooks, admin training and documentation delivered at handover, and which tasks stay with a partner under a retainer. For a containerized or Kubernetes-based platform, your team needs skills in the cluster, Helm releases, database backups and certificate management. Ask for the upgrade policy: Open-Xchange states that a standard release is supported for 12 weeks and an LTS release until the next LTS plus six months, so upgrade planning is recurring work. Ask who performs upgrades, how they are tested, and how they are costed on a fixed-scope basis.
Answers that should worry you
Vendors who answer an email RFP well can explain their trade-offs, their verification steps and their limits. The answers below are the ones that suggest a partner has not run mail for regulated organizations, and each card names the check that exposes it.
One product, no comparison
A partner who recommends a single mail server without explaining why it fits your users, protocols and operating model has not weighed alternatives. Ask them to compare Stalwart, mailcow and OX App Suite against your mailbox count, calendar needs, archiving design and team skills, and to explain what each option would cost you to run. A credible answer names the conditions under which they would recommend something else.
Guaranteed inbox placement
No partner can guarantee that Gmail, Outlook or any other provider will deliver every message to the inbox, because receiving providers make those decisions. Promises of guaranteed placement usually mean the partner will not commit to measurable deliverability work. Ask instead for the SPF, DKIM and DMARC alignment plan, the reverse DNS and TLS setup, the monitoring they will run, and how they report complaint and bounce rates to you.
No written migration verification
A migration plan that ends at the cutover date leaves you unable to prove that every mailbox, folder, calendar and contact arrived intact. Ask for a written method that compares item counts and checksums per mailbox, lists the exceptions, and defines who signs off each wave. Also ask how the partner handles mail that arrives during the cutover window and how they keep the old source until verification passes.
Archiving treated as optional
If you are a regulated firm, a mailbox server is not a record system, so a partner who treats archiving as an add-on for later has missed a core requirement. SEC Rule 17a-4(b)(4) requires broker-dealers to preserve originals of communications relating to the business for not less than three years. Ask how journaling feeds a separate archive, how legal hold and search work, and who is accountable for proving retention to an examiner.
No blocklist removal plan
Any sending IP or domain can land on a DNS blocklist, and an RFP answer that does not describe the response is a warning sign. Ask how the partner detects listings, which lists they watch, how they contact each list operator, what they do to stop further damage while a listing is open, and how they keep a relay or clean IP available as a fallback. You should also see who has authority to make that call during business hours and after them.
Vague support hours
Phrases like "business hours" or "24/7 support" with no definition leave you guessing about response for an outage that affects mail delivery. Ask for the hours, the time zones covered, the severity levels, who responds at each level and how an escalation path reaches an engineer who can change the mail stack. Request the written support terms and check whether they cover on-call coverage for the mail queue and the spam filter, not just the help desk.
How to score partner responses
This table pairs each question area from the RFP with a suggested weight, the evidence a bidder should produce, and a pass or fail threshold. Use it to score written answers consistently across bidders. Scores should rest on documents, test results and named references you can verify, not on verbal assurances made in a meeting.
| Question area | Weight | Evidence required | Pass or fail threshold |
|---|---|---|---|
| Recommended server and edition | Medium | Written architecture rationale naming the server (for example Stalwart, mailcow or OX App Suite), the license terms and the edition or support model, plus a reference deployment you can contact | Fail if the choice is not justified against your protocol, scale and hosting constraints, or if licensing for required features is unclear |
| Sender reputation and Gmail sender rules | High | Written SPF, DKIM and DMARC configuration, reverse DNS and TLS setup, a DMARC monitoring plan, and a test report from a sample domain showing alignment | Fail if the bidder cannot show a tested sending configuration or explain how Postmaster Tools data will be monitored |
| Spam filtering tuning | High | Description of the filtering stack, a false positive and false negative test plan using your sample mail, and a tuning log from a comparable deployment | Fail if there is no measured test plan or no process for releasing and reviewing quarantined mail |
| Mailbox migration without loss | High | Migration runbook, a pilot migration report with message and folder counts reconciled, and a rollback plan for each wave | Fail if the runbook has no reconciliation step or the bidder cannot describe how coexistence and mail routing are handled |
| Archiving and retention | High | Retention design mapped to your regulatory rules, journaling configuration, legal hold and search test results, and a statement of which records remain in the archive | Fail if the mailbox server is treated as the record without a separate archive, or if retention periods are not confirmed with your compliance lead |
| Outages and blocklisting response | Medium | Documented incident and escalation process, monitoring and alerting design, backup and restore test results, and a blocklist removal procedure | Fail if no tested restore is available or if there is no named escalation path and response process |
| Verifiable references | Medium | Named references in comparable regulated or sized environments, with contacts willing to confirm scope and outcomes | Fail if references cannot be contacted or describe a different scale or deployment model |
How mail platform, DNS, filtering and archive fit together
Answers to one RFP question usually change the answers to others. A vendor who recommends a server, a filtering stack or a migration method is also making choices about sender authentication, reverse DNS, TLS and where mail is archived. Sender authentication is the clearest example. SPF, DKIM and DMARC only work when the DNS records, the signing keys and the sending hosts agree with each other, so the server choice, the outbound relay (if any) and the DNS zone must be reviewed together. The same is true of reverse DNS and TLS for outbound connections, which mailbox providers check before they decide whether to accept or filter a message. Ask each bidder to show one diagram that places the mail server, the DNS provider, the filtering layer, the archive, and the backup target side by side, and to name who owns each record and key.
The filtering layer and the archive are where regulated organizations most often misread the design. Spam and malware filtering decides which messages reach a mailbox, and journaling decides which copies leave the mail platform for retention. These are separate systems with separate owners. The archive should sit outside the mailbox server, fed by journaling, so that the record of business communications does not depend on user deletions or on the health of one mail host. For broker-dealers, SEC Rule 17a-4(b)(4) requires preservation of originals of communications received and copies of communications sent for not less than three years, so the RFP should ask which messages the journal captures, how the archive handles deduplication and legal hold, and how a restore is tested. For ePHI, the HIPAA Security Rule at 45 CFR 164.312 requires transmission security under 164.312(e)(1) and audit controls under 164.312(b), which means logs from the mail server, the filtering layer and the archive must be retained and reviewable. Confirm with the vendor how those logs are collected and where they are kept.
Backups tie the whole set together, and they are the item most often left out of an RFP. A mailbox restore is only as good as the backup of the mail store, the configuration, the DKIM keys, the DNS zone and the archive index, and each of these may be backed up on a different schedule. Ask the partner to state the recovery order after a total loss of the mail host, and to show how the signing keys are restored without breaking DMARC alignment for the existing domain. Ask who reviews blocklisting and outage alerts across the filter, the relay and the DNS provider, since a fault in one of them often appears first as a delivery problem. Retention periods, archive retrieval times and restore targets are not supplied here, so request them in writing from each bidder rather than accepting a general statement.
Running the evaluation by bidder type
A pure software vendor sells or supports a mail product but does not operate your environment. Its written responses should cover the product, its release policy and its support boundaries, and it should be clear about what it will not do. Ask for the license terms in writing, because the license for the core server may differ from the license for modules, connectors or enterprise features. Ask which release lines are supported and for how long, since support windows shape your upgrade plan.
- Licensing scope: Ask which features require a separate license, whether the license covers the number of mailboxes you expect, and whether it permits your planned hosting model.
- Release and support policy: Request the published support window for each release line and the process for security patches.
- Reference architecture: Ask for the vendor's documented topology for single-node, high availability and containerized deployments, with the components it requires.
- Interoperability evidence: Request test results or documented compatibility for the clients, directories and archive tools you plan to use.
- Questions a software vendor often cannot answer: Sender reputation for your domains, spam tuning against your traffic, and your specific retention obligations depend on the operator and your own records policy.
Check whether the license, support window and deployment topology are stated in the vendor's own documents rather than in a sales email.
An implementation partner plans, builds, hardens and operates the mail platform in your infrastructure, usually on open-source servers such as Stalwart or mailcow. Its responses should show how it designs the system, how it tests it and who carries which duty after go-live. Because the partner works inside your cloud account or data center, the RFP should ask for a written scope, named deliverables and a clear split of responsibilities between your team and the partner's.
- Written scope and responsibilities: Ask for a fixed-scope statement that lists what is built, what is migrated, what is documented and what is handed over.
- Architecture and test evidence: Request the proposed design, the backup and restore test plan and a migration rehearsal approach with pass criteria.
- Security hardening record: Ask for the hardening baseline, the TLS and authentication settings, and the findings and remediation process from any independent test performed.
- Operating model: Request the monitoring, blocklist response and outage procedures, and whether support is offered as a separate retainer.
- Questions an implementation partner often cannot answer without your data: Your actual mail volume, your DNS and sender history, and whether your regulator requires a particular archive product are facts you must supply or confirm.
Check that every operational duty appears in the responsibility matrix with an owner on both sides.
A hosted mailbox provider runs mail for you on its own platform and may offer a self-hosted option, a dedicated tenant or an on-premises edition. Treat the self-hosted claim as a separate offer. Ask which components run in your environment, which run in the provider's, and where mail, logs and backups are stored at each point. The answers determine how much of your compliance evidence the provider can supply.
- Deployment boundary: Ask for a diagram showing which services, data stores and admin consoles sit in your infrastructure and which sit with the provider.
- Data location and access: Request written statements on data residency, provider staff access and how access is logged and reviewed.
- Archive and export: Ask whether journaling, export and legal hold can run on your own archive, and what formats the export produces.
- Contract terms: Request the service levels, incident notice periods and exit terms in the contract draft, not in marketing material.
- Questions a hosted provider often cannot answer: The internal configuration of a multi-tenant platform, your specific supervision workflow and the status of your domains on external blocklists may be outside what the provider can disclose.
Check that the self-hosting claim is backed by a deployment boundary diagram and a written data flow, not only by a product name.
What to put in writing before work starts
This sequence turns an email RFP conversation into a signed, fixed scope that names the environment, the migration acceptance tests, who owns archiving, and how fast the bidder responds when something breaks. Each step ends with a written artifact both sides can check.
Confirm scope and the target environment
Start by listing the domains, mailbox counts, shared mailboxes, calendars, and the directory or identity source the mail platform must use. Record where the platform will run (your cloud account, a data center, or an air-gapped network), which DNS provider holds your zones, and whether outbound mail will leave directly or through a relay. The bidder should document the proposed server, such as Stalwart, mailcow, or OX App Suite, and explain why it fits your mailbox count and protocol needs. The step is done when the environment and the platform choice appear in one written architecture note that both parties have reviewed. Ask the bidder to confirm which OX App Suite prerequisites apply if that option is on the table, including the Kubernetes, Helm, Istio and storage requirements.
Agree migration verification and cutover criteria
Define how each mailbox will be checked after it moves: message counts per folder, calendar and contact item counts, attachment integrity, and a sample of messages read by the mailbox owner. Agree the cutover window, the rollback trigger, and who signs off each wave. Ask the bidder to describe how coexistence and mail routing work while some users are still on the old system. The step is done when a written migration test plan lists the checks, the named sign-off roles, and the conditions under which a cutover is reversed. Ask for the bidder's approach to mailbox and calendar migration in writing, not only as a slide.
Define archive and retention responsibilities
Decide whether the mail server itself or a separate archive holds the business record. If your sector has preservation rules, identify the regulation and the retention period your legal or compliance team has set, then ask the bidder whether journaling, legal hold and search are in scope or handled by another system. Write down who owns the archive, who approves deletion, and who answers eDiscovery requests. The step is done when a responsibility matrix names the owner for each archive function and the bidder confirms which parts it delivers. Do not assume the mailbox server meets a preservation rule on its own. Confirm the regulatory reading with your counsel or compliance lead before signing.
Set incident and blocklist response expectations
Ask the bidder to state, in writing, how it detects an outage, how quickly it acknowledges an incident, and how it responds when your sending IP addresses or domains appear on a DNS blocklist. Cover monitoring of queues, certificate expiry, DMARC reports and Postmaster Tools data, plus the escalation path to your team. Ask which response times the bidder will commit to and whether they are contractual. The step is done when an incident runbook outline and a written response commitment are attached to the scope. If the bidder cannot commit to a number, record that gap and agree how it will be handled instead.
Agree backup, restore and access controls
Confirm what is backed up, how often, where copies are stored, and how a restore is tested. Agree who holds administrator access, how that access is logged, and how mailbox access is reviewed. If the platform handles regulated content, confirm which audit records the platform keeps and where they go. The step is done when the backup scope, restore test plan and access model appear in the written scope, with a named owner on each side. Ask the bidder to demonstrate a test restore before go-live if your recovery objectives are strict.
Sign a fixed scope and quote from it
DeployOpen engagements are typically 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. Use the previous steps as the scope inputs, and ask every bidder to price the same list of deliverables so the offers can be compared. Ask for the cost components: which items are one-time (deployment, migration, configuration) and which recur (hosting, licensing, support retainers, filtering and archive subscriptions). The step is done when a signed scope document lists deliverables, exclusions, acceptance tests and the support model after handover. Ask whether ongoing support, upgrades and testing are offered as a retainer and what they cover.
How much effort, time and cost does a mail partner review involve?
What drives the cost of a self-hosted email project?
The main drivers are mailbox count, the size of the archive you must keep, the depth of spam and malware filtering, how complex the migration is, and the number of support hours you buy after go-live. Infrastructure is one part, but most of the effort sits in design, DNS and reputation work, migration waves and testing. Ask any partner for a quote that splits one-time work (design, build, migration, hardening, documentation) from recurring work (monitoring, patching, filter tuning, backup testing, support hours, and any licensing for the groupware edition). Ask which line items change if your mailbox count or retention period changes, and whether third-party components such as an outbound relay or an archive product are included or billed separately.
Can our own team run self-hosted email without a partner?
Many organizations with experienced mail and systems administrators can run a mail server, but the hard parts are usually outside the server software: sender reputation, DNS records, blocklist response, spam tuning and archive integrity. Before deciding, assess whether your team has someone who can own SPF, DKIM and DMARC alignment, read delivery logs, respond to a blocklisting within hours and test restores. Compare that against the on-call load of a 24-hour service. A partner can take on some or all of these functions under a written scope, and you can keep ownership of policy decisions such as retention periods and who may access archives.
How long does an email hosting evaluation and rollout usually take?
The timeline depends on mailbox count, the number of domains, how many legacy systems send mail, and how many approvals your retention and security reviews require. Plan the evaluation in stages: requirements and proof-of-concept testing, a written design and fixed-scope proposal, then pilot migration, phased cutover and decommissioning of the old service. Ask each partner for a schedule with milestones tied to deliverables, the testing they will perform before cutover, and the dependencies on your side. No duration is fixed here, so treat any figure you receive as a proposal to verify against your own environment.
What does our team have to provide to a mail partner?
Expect to supply administrative access to the DNS zones for every mail domain, a decision on the identity source (directory, LDAP or an OIDC or SAML provider), and a written list of retention and legal hold rules. You will also need the current mailbox inventory, shared and resource mailboxes, mail-enabled applications and scanners that relay through the server, and a named business owner who can approve cutover windows. Ask the partner to list every access they need, the accounts they will create, how privileged access is logged and removed at the end of the engagement, and which of these items must be ready before the design phase starts.
What ongoing work follows go-live for self-hosted email?
After cutover, the recurring work includes patching the mail and groupware stack, rotating DKIM keys on a schedule, reviewing DMARC reports, tuning spam rules for false positives and negatives, monitoring blocklists and sending reputation, testing backups and archive restores, and watching certificate expiry. Regulated organizations also need periodic evidence collection for their assessors. Ask the partner for a service description that lists these tasks, the response targets they will commit to in writing, the hours of cover, and whether support is a retainer or a per-incident charge. Confirm who pays for emergency work during a blocklisting.
Which licensing costs apply to an open-source mail platform?
The mail server software may carry an open-source license with no per-mailbox fee, but the total licensing picture depends on the edition you choose. Some groupware suites require a commercial license for specific modules or features, and vendors may package them with separate fees. Open-Xchange states in its Operations Guide that the right to use certain modules may be subject to custom packaging, limitations or separate fees set in the license agreement, and its support commitment defines how long each release is supported. Ask every partner to name each component, its license type, any commercial edition involved, and the support period for the versions in the proposal.
How DeployOpen scopes and delivers email evaluations and implementations
DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For email, that means answering RFP questions with a written scope, a tested design and handover documentation that your own team and auditors can check.
How we scope
- We confirm which mail server options fit your domains, user count, protocols and existing clients before any proposal.
- We record sender authentication, spam filtering, migration and archiving requirements in the written scope so each RFP answer maps to a deliverable.
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
How we build
- We deploy the chosen mail platform in your cloud account, data center or air-gapped network, with your own DNS, certificates and identity sources.
- We configure SPF, DKIM and DMARC records, TLS settings and filtering policies, then test delivery to major mailbox providers and record the results.
- We run a pilot migration on test mailboxes, verify message counts and folder structure, and document the rollback steps before cutover.
How we hand over
- You receive architecture, configuration and runbook documentation covering mailbox operations, outage response and blocklist handling.
- We prepare retention, audit logging and access control evidence so your compliance team can map controls to the frameworks it assesses.
- Your administrators are trained on daily operations, monitoring dashboards and DMARC report review before the platform goes live.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, so patches and release changes follow a planned schedule.
- We can run periodic security testing of the mail platform, its web interfaces and its APIs as part of the support arrangement.
- Ask your partner to confirm in writing who responds to outages and blocklistings, and within what windows, before signing.
