Email newsletter platform RFP questions

listmonk is licensed under the AGPL v3, which is a strong copyleft license. The AGPL applies to the software you run, so you should ask the vendor to confirm the license in the project's own GitHub repository and to state in writing whether any code in your deployment falls under a different license. Ask which version you will deploy, such as the current v6.2.0 release published on June 26, 2026, and confirm that your implementation documentation names it. Counsel should review what the AGPL obligations mean for your organization's use.

The AGPL requires that users who interact with a modified version over a network can obtain the corresponding source code, so internal changes can trigger obligations. Ask the vendor to list every change planned for your deployment, including custom templates, messengers, plugins and patches, and to explain how each is classified. Confirm where modified source will be kept, who receives it, and how it will be provided if a user or regulator asks. Counsel should confirm whether your planned changes create a source disclosure duty for your use.

Mautic's repository is licensed under GPL-3.0, which is a copyleft license that generally applies when you distribute modified copies of the software, not merely when you run it internally. Ask the vendor to confirm whether your use is internal, whether you will provide Mautic to third parties such as clients or partners, and whether any modified code will be shared outside your organization. Confirm that the project's license is cited from the Mautic GitHub repository in your implementation records. Counsel should decide whether distribution or hosting for others triggers obligations.

Dittofeed is MIT licensed according to its GitHub repository, which is permissive and allows commercial use and modification with a notice requirement. Its recent GitHub releases are pre-release tags, with v0.24.0-alpha.21 published on October 4, 2026, so ask the vendor to confirm which tag is deployed and whether it is suitable for production. Ask whether any Dittofeed features, connectors or hosted services are offered under separate terms, and get that answer in writing. Counsel should confirm the notice and attribution duties that apply to your release.

The vendor should state whether any component of the platform, add-on, connector, template pack or managed service is licensed on different terms from the core project. Mautic's project states that it has no paid edition of the software itself, but separately promoted managed Mautic and hosting services exist, so ask which services are contracted and what terms apply to each. Ask for every third-party license, including the sending service you connect to, and request copies of the terms in writing before work starts. Counsel should review any service agreement with the vendor alongside the open-source licenses.

The organization that deploys and operates the platform carries the compliance duty for its own use, while the implementation partner should document what it installs, modifies and delivers. Ask the vendor to name the person accountable for an inventory of licenses, notices and versions, and to provide that inventory as a deliverable. Confirm who approves changes to license-sensitive code, how upgrades will be tracked against license changes, and what happens if a license changes in a future release. Counsel should set the responsibility split in the written scope.

The vendor should cite the license from each project's own repository, record the exact version, and state the date it was checked. For listmonk, ask for citations to the project's GitHub repository and releases page, for Mautic to the GitHub repository and releases page, and for Dittofeed to its repository and release list. Ask for a license file, notice file and dependency list for the exact release deployed. Keep these records with the fixed-scope document so the scope and licensing position can be reviewed together.

A vendor can state what a license says and where it is published, but it cannot decide how the license applies to your organization's specific use. Ask the vendor to confirm the license facts in writing, and ask your counsel to review the obligations that follow from your use, distribution and modifications. DeployOpen plans, implements and documents self-hosted platforms in your own infrastructure, so ask for written scope that states which licensing deliverables are included. Treat that scope as the basis for your legal review, not as legal advice.

listmonk supports OIDC single sign-on with granular roles, permissions and API tokens, according to the project's website. Confirm the configuration for your deployment before relying on it: ask the bidder to show the OIDC settings working against your identity provider, how role assignments map from your groups, and how staff accounts are removed when someone leaves. Ask whether API tokens are issued per integration, who can create them, and how they are revoked. Ask every bidder to demonstrate the same sign-in, role and token revocation steps in a test environment so the answers can be compared directly.

Ask where every credential lives and who can read it. The list usually includes SMTP and messenger credentials, database passwords, OIDC client secrets and API tokens. Ask the bidder to name the secret store used in your environment, whether values appear in container images, compose files or configuration files in version control, and how rotation is done without a send outage. Request a written procedure for rotating each credential type, and ask who performs rotation after go-live. Strong answers name the storage mechanism and the owner of each secret rather than describing security in general terms.

Ask for the patch cadence written against each project's published support windows. For Mautic, the project publishes monthly patch releases, minor releases every three months and major releases every two years, and it lists security support end dates for each version. Confirm which Mautic version you will run and when its security support ends, then ask how the bidder will move you before that date. Ask the same question for the operating system, PostgreSQL or MySQL, PHP and the web server. Request the bidder's process for testing a patch, the window in which it is applied and the rollback plan. Any SLA on patch timing should appear in the written scope, not in a verbal assurance.

Ask whether scanning and testing are part of the fixed scope or a separate retainer, and what each covers. Scanning typically covers the hosts, containers and dependencies, while penetration testing covers the web interface, the subscriber import and API endpoints, the public subscription and unsubscribe pages, and the sending path. Ask who selects the test scope, who receives the findings, how severity is rated and how fixes are tracked to closure. DeployOpen runs security testing of applications, APIs, cloud and infrastructure, and AI systems. Ask each bidder for a sample scope document and the report format it would deliver before signing.

Ask for a list of the events that produce a record, and confirm that each one is available in your deployment. Useful events include administrator sign-in and role changes, API token creation and revocation, list exports, subscriber deletions, template edits, campaign creation and launch, and changes to SMTP settings. Ask where logs are stored, how long they are kept, whether they are forwarded to your central logging platform, and whether they can be made tamper-evident. Confirm that the logs record the acting user and timestamp. The bidder should show a sample log entry for each event type.

DeployOpen prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that work. Ask each bidder which artifacts it will prepare, such as access reviews, configuration baselines, patch records, backup and restore test results, change records and data flow diagrams. Ask who keeps the evidence after the engagement ends and in what format. Ask for references to the control areas the evidence supports, but do not accept any claim that a bidder's work alone satisfies an audit. Put the list of artifacts in the written scope.

Yes, if the handover is planned into the scope. Ask the bidder to list the runbooks it will deliver, including account provisioning, token rotation, patch application, log review and restore testing, and who on your team will be trained to run each one. Ask whether the platform's configuration is kept in version control so that changes can be reviewed. If you want the partner to remain responsible for patching or testing, ask whether that is delivered under a retainer and what the retainer covers. The cost of internal administration recurs with staff time, while the handover itself is usually one-time work defined in the written scope.