Why high-volume sending on self-hosted email is a deliverability project
The platform is the easy part. Sending reputation, queue design and list hygiene decide whether a large campaign reaches the inbox. Teams that plan a self-hosted send around software installation usually discover the problem after the first large campaign, when mailbox providers begin deferring or filtering mail from a sender they have no history with. In practice, listmonk fits high-throughput campaigns with a lean footprint, while Mautic fits teams that need automation alongside campaigns and can carry heavier operational needs. Both depend on an SMTP relay, whether that is a managed sending service such as Amazon SES or your own mail transfer agent, so the relay's reputation, limits and bounce handling become part of your results.
The listmonk project publishes its own claim of a production instance sending a campaign of more than 7 million emails at a fraction of one CPU core and 57 MB of peak memory. Treat that as the project's claim, not an independent benchmark. Resource use on your side will depend on your database, your message size, your send rate and the SMTP servers you connect, so ask your implementation partner to test a representative send before committing to a schedule. The lean footprint is real only if the relay accepts the volume you plan to push through it.
The decisions to make early are these: which relay carries the mail, how many SMTP servers the queues use, what rate limits each domain and provider will tolerate, and how warm-up will ramp volume on new sending domains and IP addresses. Confirm with your relay provider which limits apply to your account and whether dedicated IP addresses are available to you. Then decide who owns bounce and complaint processing, because a list that is never cleaned will eventually damage the reputation every other campaign depends on.
Which sending requirements shape the build
This table maps the sending rules that most affect a self-hosted listmonk or Mautic build to the part of the stack they change. Read each row for the source of the rule, what it asks of the sending relay, and which platform settings you must verify. The main takeaway is that authentication, unsubscribe handling and bounce processing are configured across the relay, DNS and the list platform together, so none of them can be set in isolation.
| Requirement | Source of the rule | What it means for the relay and platform settings |
|---|---|---|
| SPF, DKIM and DMARC alignment | Mailbox provider bulk sender rules | Each sending domain needs SPF and DKIM records published, and the DMARC policy must align with the visible From domain. Confirm the relay signs with your domain, not only its own domain. |
| One-click unsubscribe headers | Mailbox provider bulk sender rules | Campaign messages need a List-Unsubscribe header and a one-click POST endpoint. Confirm that listmonk or Mautic emits the header and that the relay passes it through unchanged. |
| Bounce and complaint handling | Platform behavior and mailbox provider feedback loops | Hard bounces and complaints must suppress addresses automatically. Confirm how the relay returns bounce and complaint events to the platform, and how listmonk or Mautic records and blocks those addresses. |
| Rate limiting and queue design | Platform behavior and relay quotas | listmonk sends through queues across multiple SMTP servers with rate limiting, and Mautic relies on cron jobs and a messenger consumer for queued email. Confirm send rates against the relay quota and the number of workers you run. |
| Opt-out processing | Anti-spam law (for example, CAN-SPAM, CASL and GDPR) | Opt-outs must take effect quickly across every list and campaign. Confirm that unsubscribes apply globally where the law requires it and that the platform keeps an auditable record of each request. |
Relay through Amazon SES or run your own MTA
A managed relay such as Amazon SES accepts mail over SMTP or its API and handles delivery to recipient mail servers. listmonk supports multiple SMTP servers, so you can point it at the relay and spread load across configured servers while keeping the subscriber database and templates in your own infrastructure. The provider operates the sending network, but your domain and sending practices still determine reputation.
- IP reputation: Shared or dedicated IP pools are managed by the provider. Confirm which pool type you receive and who can request a dedicated IP.
- Warm-up: Warm-up for a new domain or dedicated IP stays your responsibility, through gradual volume increases and clean lists.
- Feedback loops: Bounce and complaint events come back through the provider's notification mechanism, which you must route into listmonk or Mautic to suppress addresses.
- Data location: Message content and metadata pass through the provider's regions, so check where it is processed against your residency rules.
- Staffing: Less infrastructure work, but your team still owns the DNS records, event handling and monitoring.
Confirm the current sending terms, quotas and acceptable use rules with the provider before you commit to a volume plan.
Running your own MTA, such as Postfix or another SMTP server you operate, keeps message transfer inside your network and gives you direct control over queues, retries and logs. listmonk can relay through that server as one of its SMTP servers, but you then own every reputation signal that recipients and mailbox providers observe.
- IP reputation: Your IP addresses are your reputation. Blocklist checks, reverse DNS and sender authentication become your daily work.
- Warm-up: New IPs need a deliberate warm-up schedule, and volume must rise slowly while you watch rejections and deferrals.
- Feedback loops: You must enroll in each mailbox provider's feedback programs where available and process complaint reports yourself.
- Data location: Subscriber data and message transfer stay in the infrastructure you choose, which suits strict residency needs.
- Staffing: Expect ongoing operations work for patching, queue health, TLS certificates and abuse handling, owned by a named internal team or a partner under a support agreement.
Confirm your hosting provider's rules on outbound port 25 and IP reputation before you build, because some environments restrict direct mail delivery.
Some organizations keep listmonk or Mautic in their own infrastructure and send through a managed relay for most traffic, reserving an owned server for mail that must stay internal, such as notices governed by a residency rule. The split lets each message class follow its own data and reputation path, but it adds routing logic and a second set of logs to reconcile.
- IP reputation: Segregate streams so that marketing reputation is not tied to operational or regulatory notices.
- Warm-up: Each sending path needs its own warm-up plan, even when both use the same domain.
- Feedback loops: Bounce and complaint handling must cover both paths and feed one suppression list.
- Data location: Document which message types use which path so auditors can trace where data flows.
- Staffing: Two operating models mean more configuration review, but a smaller owned footprint than a full MTA.
Confirm with the relay provider which traffic it may carry under its terms, and with your data owner which categories may leave your infrastructure.
How IP and domain warm-up is sequenced
A staged warm-up builds sender reputation on a new IP or domain so that mailbox providers learn to trust the volume before it grows. Each stage closes with a written check, so the next volume increase rests on evidence rather than on the calendar.
Confirm the sending path and warm-up owner
Before any volume moves, confirm whether the platform relays through a managed service such as Amazon SES or through your own MTA, and whether the IP pool is dedicated or shared. The relay provider or your own operations team owns the warm-up schedule, and that owner should be named in writing. Ask the relay for its documented warm-up guidance and for any limits on new dedicated IPs. The step is done when the owner, the relay and the IP pool type are recorded in the runbook.
Verify authentication records before sending
Publish and test SPF, DKIM and DMARC for the sending domain, and confirm that the envelope and header domains align with the From address. Check that the reverse DNS and HELO name of each sending IP match the relay's documentation. Send test messages from listmonk or Mautic to a set of inboxes and inspect the authentication results in the headers. The step is done when every test message passes all three checks with alignment, and the results are saved as evidence.
Test with a seed list
Build a seed list of mailboxes across the major providers your audience uses, and send a small controlled batch to it. Record where each message lands (inbox, spam or missing) and review the tracking data for bounces and opens. Seed results are a directional signal, not a guarantee of inbox placement, so treat them as a gate for the next stage rather than a verdict. The step is done when placement across providers is recorded and any authentication or content issue has been fixed.
Ramp volume in stages against engagement
Start with the most engaged subscribers, such as recent openers or clickers, and increase daily volume in steps that the relay or your reputation data supports. Use the segment query in listmonk or the segment rules in Mautic to select each cohort, and pause the ramp if deferrals or throttling appear. Do not copy a generic schedule from a blog post. Confirm each stage's volume with the chosen relay. The step is done when each stage closes with its open, click, bounce and deferral figures reviewed before the next increase.
Set bounce and complaint thresholds
Agree written thresholds for hard bounces, soft bounces, complaints and unsubscribes before the ramp accelerates, and configure the platform to stop or pause sending to a segment when a threshold is crossed. Confirm the complaint and bounce feedback channels with the relay, including how suppression lists are synchronized back to the platform. The step is done when thresholds, the pause rule and the owner who acts on an alert are documented and tested with a controlled alert.
Confirm the sending plan for each ramp stage
Before moving from one stage to the next, record the authentication status, seed results, engagement and threshold status in a short sign-off. Share it with the relay or the operator team and agree the next volume in writing. If the relay has no published guidance for your case, ask it to confirm the volume it will allow for your IP or domain. The step is done when a signed or recorded decision exists for every stage transition.
Move to steady-state monitoring
Once the target volume is reached, keep daily monitoring of placement, complaint rates, bounce classes and deferrals, and tie alerts to the thresholds set earlier. Review suppression and list hygiene on a fixed cadence so that stale addresses do not drag reputation down again. Confirm with the relay how it reports reputation changes to you. The step is done when monitoring is live, owners are named, and the warm-up record is filed for audit or customer questions.
What bounce, complaint and list hygiene processing must do
How do hard bounces suppress addresses in a self-hosted newsletter platform?
A hard bounce is a permanent delivery failure, such as an address that does not exist, and it should remove that address from future sends immediately. listmonk records bounces against each subscriber and includes bounce data in its built-in analytics, so you can see which campaigns and domains produce the most failures. Confirm in your installed version how bounce actions are configured, whether a hard bounce blocklists the subscriber automatically, and how many soft bounces trigger that action. Mautic handles this through contact and segment rules, so you will need to build the suppression condition yourself and test it with a sample of real failure responses before the first large send. Ask your implementation partner to document the exact threshold, the field that marks the suppression, and the report your team will check after each campaign.
How are spam complaints fed back and acted on after a send?
A spam complaint arrives when a recipient marks your message as spam, and the most important action is to stop mailing that address at once. Complaints reach you only if the mailbox provider sends feedback to you, usually through a feedback loop offered by your sending service or the provider itself, so confirm which loops your sending path supports and how the complaint data is delivered to your platform. In listmonk, complaint events should be tracked as a suppression reason in the same way as bounces, and the campaign analytics should show complaint rates per campaign. In Mautic, the equivalent is a contact flag or a segment exclusion that your campaigns respect. Ask for a written procedure that states who reviews complaint volume, the rate at which a campaign is paused, and how a complaint is linked back to the list it came from.
How must unsubscribe requests be honored across lists and campaigns?
An unsubscribe must remove the subscriber from the list they opted out of, and it should stop all future marketing messages to that address unless your legal basis says otherwise. listmonk supports single and double opt-in lists, and its campaign templates include unsubscribe handling, but you must confirm that the unsubscribe link in your installed template updates the subscriber status in the database and is not overridden by a cached copy. Mautic uses contact preferences and channel frequency rules, so verify that an opt-out on one channel does not leave the contact reachable through another segment or campaign. Test the full path with a test address before each new template goes live. Your partner should also record how unsubscribe events flow into any downstream systems, because a suppression that exists only in one tool can be lost during a sync.
How should stale subscribers be retired without losing good contacts?
Stale subscribers are addresses that have not opened, clicked or responded for a defined period, and retiring them protects sender reputation while keeping the list healthy. Define the inactivity window with your marketing and compliance owners, then build a segment that captures those subscribers and move them to a review list or suppress them, depending on your policy. listmonk's campaign analytics show opens and clicks per subscriber, so you can build an SQL-based segment from that data, but confirm the query behavior on your database version before you rely on it. Mautic segments and campaigns can perform a similar task through contact activity conditions. Schedule the retirement job, log each run, and keep the criteria in writing so you can explain why a contact was removed.
How do suppression lists survive imports, restores and backups?
Suppression lists are only useful if an import, restore or migration cannot silently add back addresses that were removed. Treat the suppression record as protected data: an import should check incoming addresses against it before inserting, and a database restore should be followed by a comparison against the latest suppression export. Confirm in your installed listmonk or Mautic version whether imports respect existing blocklist and bounce status, and test that behavior with a file that contains a known suppressed address. Back up the suppression table on its own schedule, record the retention period, and make restore procedures include a reconciliation step. Ask your implementation partner to include this check in the runbook, the restore test and the change process for any new sending domain or list.
What monitoring shows that bounce and complaint processing is working?
Processing works when the platform reports the same bounce, complaint and unsubscribe counts that your sending service and mailbox provider feedback show. Monitor hard bounce rate, complaint rate, unsubscribe rate and the number of addresses suppressed per campaign, and compare them with the sending service's own reports. In listmonk, the built-in campaign analytics for bounces and links provide the platform-side view, while Mautic reports cover campaign and contact activity. Set alert thresholds in writing and assign an owner to each. If the numbers diverge, investigate the feedback path before sending the next campaign. Ask for a sample report from the partner that shows how these metrics are collected, stored and reviewed after go-live.
Can our own team run bounce and list hygiene after go-live?
Your team can run daily hygiene if it has an owner, written procedures, access to the platform and a reliable way to receive sending service reports. The harder part is ongoing ownership: someone must review complaint trends, approve threshold changes and handle exceptions when a large send goes wrong. An implementation partner can design the suppression rules, build the monitoring, test the restore path and document the runbook, and DeployOpen offers ongoing support and continuous testing as retainers. Whether a retainer is needed depends on send volume, the number of lists and the staff available. Ask any partner for a fixed-scope statement that names what is handed over, what remains with your team and how changes are requested after handover.
Which reputation signals to monitor and who owns them
Sending reputation is measured in a handful of signals that move together: volume, bounces, complaints, authentication and engagement. Each one needs a named owner, an alert threshold the team has agreed in writing, and a known place in the platform where the data appears.
Sending volume and queue backlog
Track messages sent per hour, per sending domain and per SMTP route, alongside the depth of the listmonk queue. A backlog that grows during a campaign usually means the rate limit, an SMTP route or a relay is slower than planned, and a burst of retries can look like abuse to a mailbox provider. Owner: the platform operations team. Alert when the queue age exceeds the agreed send window. Data source: the campaign status and queue views in listmonk, plus relay logs from your SMTP provider or MTA.
Bounce rate
Hard bounces tell you addresses that will never accept mail, and soft bounces tell you about temporary refusals that may turn hard. Repeated hard bounces on the same list point to stale imports or a broken signup form, and they hurt sender reputation fast. Owner: the list manager for each audience. Alert on a hard bounce rate the team sets per campaign, with automatic suppression of addresses that hard bounce. Data source: the bounce records and bounce analytics in listmonk, which feed back into subscriber status.
Complaint rate
Spam complaints are the signal mailbox providers weigh most heavily, and a small number of complaints from one campaign can outweigh a clean list. Watch complaints per campaign and per sending domain, and confirm that feedback loop reports reach the team. Owner: the marketing owner who approves the send, with the platform team responsible for suppression. Alert on any complaint spike against the team's baseline and pause the list until the cause is found. Data source: campaign analytics in listmonk, plus feedback loop data from each mailbox provider that offers it.
Authentication pass rates
SPF, DKIM and DMARC results show whether receivers can verify that your messages came from the domains you control. A drop in DKIM passes after a key rotation or a new relay often appears before any complaint trend does. Owner: the DNS and email infrastructure owner. Alert on any failing alignment for a production sending domain and on DMARC reports that show unexpected sources. Data source: DMARC aggregate reports sent to your reporting address, plus the authentication logs of your SMTP provider or MTA. Confirm the DMARC policy on each domain before a volume increase.
Blocklist status
Public blocklists list sending IPs and domains that receivers have flagged, and a listing can cut delivery to large providers within hours. Check your sending IPs and domains against major lists on a schedule and after any complaint spike. Owner: the security or network operations team, with a documented delisting process. Alert on any new listing for a production IP or domain. Data source: a blocklist monitoring service or script run against your sending IPs and domains, and the bounce codes your relay returns when a receiver rejects mail for reputation reasons.
Engagement trend
Opens, clicks and unsubscribes over several sends show whether subscribers still want the mail, which is the long-run defense against spam filtering. Track the trend per segment rather than the list average, because an old segment that stopped engaging can drag the whole domain down. Owner: the marketing owner, reviewing the trend before each send. Alert when engagement for a segment falls below the agreed baseline for consecutive sends, then suppress or re-permission that segment. Data source: the built-in campaign analytics for opens, clicks and links in listmonk, with segment queries in SQL to isolate cohorts.
Which platform fits which sending volume
listmonk is the leaner choice for very large one-way campaigns, where the job is to send the same newsletter to a big list through a queue with rate limits. It is a standalone Go binary whose only dependency is PostgreSQL, so the footprint stays small: the project's own website cites a production instance sending a campaign of more than 7 million emails at a fraction of one CPU core, a claim you should verify in your own load test before you rely on it. Its queues spread sends across several SMTP servers, which is where your relay decision (Amazon SES or your own MTA) plugs in. Confirm the current release before committing: v6.2.0 was published on June 26, 2026, and you should check the GitHub releases page for anything newer and for the support status of your chosen version.
Mautic suits teams that run segment-driven campaigns and automation, where sends depend on contact behavior, campaign branches and triggers. That power comes with heavier hosting. The Mautic project says it should not be installed on shared hosting and recommends a VPS or dedicated server. It relies on cron jobs for segment updates, campaign updates and campaign triggers, which the docs say should be staggered so they do not collide. When emails are queued, you also need a messenger consumer running, or mail will sit unsent. Mautic 7.0 requires PHP 8.2 to 8.5 and MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, so plan for a larger database and a supervised worker process, not a single small server.
Mautic's release windows are shorter than many teams expect. Mautic 7.2 receives security support only until September 30, 2026, while Mautic 7.3 is planned as the long-term support release with security support through December 31, 2027. Before you choose a version, confirm which release is current, which PHP version your hosts run, and whether your organization needs the long-term support line. For either platform, ask your implementation partner to document the upgrade path and the cron, worker and queue settings in writing, so volume growth does not depend on one person's memory of the setup.
Which platforms fit high-volume sending and why
High-volume sending depends on two choices: the application that manages lists, queues and campaigns, and the relay that delivers mail to mailbox providers. The cards below cover the two self-hosted applications in scope and the relay options that sit behind them, with the work each one leaves to the operator.
listmonk for queued campaigns
listmonk is AGPL v3 licensed and ships as a standalone binary with PostgreSQL as its only dependency. Its multi-threaded queues can spread a campaign across several SMTP servers and apply rate limits, which suits large one-way newsletter sends. The operator provides the PostgreSQL sizing, the SMTP endpoints, the bounce mailbox handling and the monitoring. Confirm the current release, v6.2.0, against the GitHub releases before you pin a version.
Mautic for sequenced campaigns
Mautic 7.2.1 is GPL-3.0 licensed and written in PHP on the Symfony framework. It fits organizations that need segment-driven campaigns, scoring and multi-step journeys alongside bulk sends. Its sending depends on cron jobs for segment and campaign updates, a broadcasts command and a messenger consumer when mail is queued. The operator must stagger those jobs, run the consumer under a supervisor, and size a VPS or dedicated server, since the project advises against shared hosting.
Amazon SES as a managed relay
Amazon SES is a managed sending service that listmonk or Mautic can use as their SMTP relay, so the operator does not run mail servers or manage inbound feedback loops for major providers. The trade-off is a processor relationship for mail content and recipient addresses, which the data protection team must document. The operator provides the sending identity, DKIM and bounce and complaint notifications routed back to the platform. Confirm current SES quotas and regional availability in your account.
Owned MTA for full control
An owned mail transfer agent, such as Postfix with its own outbound IP ranges, keeps message flow and logs inside your infrastructure. It suits organizations with strict data location rules or existing mail staff, but reputation sits entirely with your IP addresses and domains. The operator must build warm-up schedules, reverse DNS, feedback loop registrations and blocklist monitoring from the start. Ask any partner to show these controls in a written scope before committing to an owned relay.
Queue and rate design
Whichever application and relay you choose, the sending rate must match what mailbox providers accept from a new or recovering sender. Queue concurrency, per-SMTP rate limits and retry policy decide whether a large send spreads over hours or floods one provider. Set limits per provider domain, not only globally, and test them against a staging list before a live campaign. Confirm how each platform reports deferred and throttled messages.
Bounce and complaint processing
Hard bounces, soft bounces and spam complaints must reach the list database quickly, or the platform keeps mailing addresses that will never accept mail. listmonk records bounces and campaign analytics, and Mautic handles bounces through its own configuration. The operator must confirm the bounce mailbox or webhook path, the thresholds that suppress an address, and how complaint feedback is removed from every list. Test this path with sample bounces before the first production send.
How a high-volume sending rollout is phased
The sequence moves a self-hosted sending platform from an audited baseline to a controlled, monitored volume that your team can run on its own. Each phase ends with a named artifact, so progress can be checked before the next phase starts.
Audit the current sending baseline
The partner reviews the existing lists, sending history, domains, IP addresses and any current sending service, then records the findings in a sending architecture record. The audit covers which sources feed each list, how opt-in is captured, and what bounce and complaint rates look like today. The step is done when the client has signed off the record and the open questions are assigned to named owners.
Configure the relay and sending path
The team connects listmonk or Mautic to the chosen relay, either a managed sending service such as Amazon SES or the organization's own mail transfer agent, and sets SMTP credentials, concurrency and rate limits. For listmonk, queue and rate settings are applied to the SMTP servers in use. For Mautic, cron jobs and the broadcasts command are staggered and the messenger consumer is confirmed to run. The step closes with a test campaign that reaches seed mailboxes through the intended path.
Verify DNS and authentication records
The partner publishes and checks SPF, DKIM and DMARC records for the sending domain and any subdomains, and confirms that the envelope and visible sender domains align. Return path, tracking domain and unsubscribe headers are checked against the sending service's documentation. The phase produces a verified DNS record set with test results attached, and the client's DNS owner confirms the changes in their zone.
Build the warm-up plan
Using the sending architecture record and the baseline audit, the team writes a warm-up plan for the domain and any dedicated IP addresses. The plan lists the most engaged segments first, the daily volume ceilings, the mailbox providers to watch and the pause conditions. The client approves the plan before any volume is sent. The output is a written schedule with the criteria that move each step forward or hold it.
Increase volume under controlled gates
The team sends each planned batch and checks delivery, deferral, bounce and complaint results before releasing the next batch. Engagement signals guide which segments are added. Suppression lists are applied for hard bounces and unsubscribes, and sending pauses if complaint or bounce levels cross the thresholds in the plan. The step is done when the platform sends the target volume at the planned rate with results inside the agreed limits.
Document the bounce and complaint runbook
The partner writes a runbook that covers how hard bounces, soft bounces, feedback loop complaints and unsubscribe requests are processed, who reviews them, and how suppression is synchronized across the platform and the sending service. It also describes how list hygiene runs on a set schedule and how a sudden reputation drop is handled. The runbook is tested with the client's operations staff on a live sample, and the output is a signed-off document.
Set monitoring and alert thresholds
The team builds a monitoring dashboard for delivery, bounce, complaint, queue depth and send rate, and the client sets the alert thresholds that matter to its risk appetite. Alerts are routed to named responders. The dashboard and thresholds are tested by triggering a controlled alert. The output is a live dashboard with documented thresholds, owners and escalation paths.
Hand over and confirm operations
The partner runs a handover session covering the architecture record, DNS evidence, warm-up history, runbook and dashboard, and confirms that the client's team can perform each routine task alone. Open items and any ongoing support or retainer scope are recorded in writing. The phase closes when the client accepts the handover in writing and the fixed scope is marked complete.
Evidence that proves controlled sending to auditors and regulators
This table maps each piece of evidence an assessor or regulator may ask for to the component that produces it and what to check. Read it as a starting inventory for your own evidence plan, since DeployOpen prepares this evidence but auditors and regulators decide whether it is sufficient. The main takeaway is that most sending evidence sits in the application logs, the relay's reporting and the DNS zone, so retention and change control must cover all three.
| Evidence | Produced by | What to confirm |
|---|---|---|
| Suppression and unsubscribe logs | listmonk subscriber status history and campaign data, or Mautic contact and DNC records | Entries are timestamped, retained for the period your policy requires, and included in backups |
| Bounce and complaint records | listmonk bounce handling and analytics, Mautic bounce processing, and the relay's bounce and complaint feedback | Hard and soft bounces are classified, and complaints are linked to the campaign that caused them |
| Consent records linked to list membership | listmonk list subscription status (single or double opt-in) and Mautic consent and segment history | Each opt-in event stores the source, time and confirmation step, and can be exported per subscriber |
| Authentication configuration | DNS records for SPF, DKIM and DMARC, plus the sending domain settings in the relay console | Records match the sending domains and the DMARC aggregate reports are collected and reviewed |
| Relay agreements and processor terms | Contracts and data processing terms with the relay or your own MTA hosting provider | Terms cover data location, sub-processors, retention of logs and deletion on exit |
| Change records for sending settings | Configuration files or infrastructure-as-code history, SMTP and rate limit settings, and administrator audit logs | Each change to rate limits, sending domains or templates has an author, a date and an approval |
| Warm-up and volume records | Relay sending statistics and the platform's campaign reports for each domain and IP pool | Daily volumes during warm-up match the agreed plan and are kept with the sending history |
What to ask an implementation partner about sending at scale
Start with the sending account, because it decides who can fix a reputation problem at 2 a.m. Ask the partner to state in writing which relay carries mail (Amazon SES, another hosted relay, or your own MTA), who holds the account, who holds the verified domain and DNS records, and who can change sending limits or suspend a stream. Ask how listmonk's multi-threaded queues and per-server rate limits will be set for each SMTP endpoint, and who owns those values after go-live. Warm-up responsibility should also be a named role with a written ramp plan, not an assumption that the platform handles it.
Ask how tuning will be tested with real volumes in your environment, not only in a staging copy. A useful test plan uses a seeded list of your own addresses across the mailbox providers you care about, runs a staged send at increasing rates, and records queue depth, throttling responses, bounce classes and complaint counts at each step. Ask for the bounce and complaint runbooks, including how hard bounces suppress addresses in listmonk or Mautic, how feedback loop reports are ingested, and who acts within what window. Ask which monitoring dashboards and alerts are handed over, who is paged, and what the partner will test during handover.
Make acceptance tests part of the fixed scope. Ask the partner to list each test, its pass criteria, the evidence delivered (test logs, configuration exports, alert screenshots, the runbook version), and what happens if a criterion fails. Confirm what support covers after go-live, the response expectations in writing, and whether a retainer is needed for upgrades to listmonk, which the project publishes releases for (v6.2.0 was published on June 26, 2026), or to Mautic, whose support windows the project lists by version. Confirm these terms with the partner and in your contract rather than assuming them.
How much work and cost does high-volume sending setup involve?
What drives the cost of setting up high-volume email sending?
The cost is driven mainly by the relay choice, the number of sending domains and IP pools, the sender's existing reputation, the number of lists and segments, and how much of the bounce and complaint handling must be built. A team that relays through a managed service such as Amazon SES has less infrastructure to build than one running its own MTA, but it still pays for configuration, authentication records, queue tuning and monitoring. Ask any implementation partner for a written scope that lists each of these drivers separately, so you can see which ones change the price and which are fixed.
How long does it take to reach a stable sending state?
The honest answer depends on the starting point: whether the sending domain is already established, whether any IP or domain warm-up is needed, and how many mailbox provider feedback loops must be configured before volume increases. Warm-up is a gradual process driven by the mailbox providers' response, so no fixed duration can be promised before the sender's history is known. Ask for a written plan that separates setup work from the warm-up period, and for the volume ramp steps you will be expected to follow.
What must our team supply before an implementation starts?
Most delays come from access and ownership gaps rather than technical work. Expect to supply:
- DNS access to publish and adjust SPF, DKIM and DMARC records for each sending domain
- An account with your relay, such as Amazon SES or your own MTA, with credentials and sending quotas you agree to
- Subscriber list data, including consent evidence and suppression lists from any previous platform
- Named owners for bounce, complaint and alert notifications who can act on them
Confirm these items with your team before the scope is signed.
Can an internal team set up high-volume sending alone?
A capable platform or messaging team can configure listmonk or Mautic and a relay on its own, provided it has someone who understands mailbox provider rules, DNS authentication and queue behavior. The harder part is operating the system under load: warm-up pacing, complaint thresholds and recovering reputation after an incident. Mautic adds further operational work because it relies on cron jobs and a messenger consumer, which must be staggered and monitored. Weigh the internal skills you have against the time your team can give to the project, and consider a partner for the parts that are new to you.
What work recurs after go-live for a self-hosted sending platform?
Recurring work falls into four groups: platform upgrades, bounce and complaint review, list hygiene, and reputation monitoring. Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, and its older versions reach end of security support on dates listed on its releases page, so budget for regular upgrades. listmonk releases are published on GitHub and should be reviewed on the same basis. Ongoing support, upgrades and continuous testing can be covered by a DeployOpen retainer, which is agreed separately from the fixed-scope setup.
How do relay and hosting choices change the running cost?
A managed relay charges by message volume, so cost rises with sends, while a self-run MTA shifts cost toward servers, IP addresses, monitoring and the people who maintain them. Mautic should not be installed on shared hosting and the project recommends a VPS or dedicated server, so hosting cost is a fixed line in both cases. Ask each option to be priced against the same monthly volume, the same number of domains and the same retention period, so the comparison reflects the real drivers.
Does the platform itself carry licence cost at high volume?
listmonk is licensed under AGPL v3, and Mautic is licensed under GPL-3.0 or later with no paid edition of the software itself, so the platform licence does not scale with the number of messages sent. The costs that grow with volume sit with the relay, hosting and staff time. Confirm with your legal team how AGPL obligations apply if you modify the software and make it available to users over a network, since that depends on your use and is not a question this page can settle for you.
What evidence should we ask a partner to show before we commit?
Ask for a written scope that names the relay, the number of domains, the list and segment structure, the volume ramp plan and the monitoring you expect to see. Request the acceptance criteria for go-live, the handover of runbooks, and the support terms after go-live, including what is covered by a retainer. DeployOpen works on fixed-scope engagements with scope, deliverables and timelines agreed in writing before work starts, and does not publish a price list, so a quote follows from that written scope.
How DeployOpen scopes and supports high-volume sending
DeployOpen plans, implements, hardens, documents and supports self-hosted listmonk or Mautic inside your own cloud accounts, data centers or air-gapped networks. For a high-volume sending program, that work usually covers the sending path (listmonk's multi-threaded queues and SMTP settings, or Mautic's cron jobs and messenger consumer), the relay to Amazon SES or your own MTA, DNS records for SPF, DKIM and DMARC, bounce and complaint handling, warm-up schedules, and the monitoring that tells you when reputation starts to slip. Each of those pieces is agreed in writing before any work starts, so you know which components are in scope and which remain with your team.
Engagements are fixed-scope. The written scope names the platform and version, the sending services and domains involved, the list and segmentation rules to be configured, the integrations with your identity provider and data sources, the test and cutover plan, and the handover documents. Because pricing follows from that scope, the most useful preparation is an inventory of your sending volumes by stream, your current bounce and complaint figures, and the mailbox provider and sending service accounts you already hold. Ask any partner, including DeployOpen, to state which of these items are included and which are your responsibility. Ongoing support, upgrades and continuous testing are available as retainers, which suit programs where warm-up, reputation monitoring and platform upgrades recur across the year.
DeployOpen prepares the evidence that supports your own compliance and audit work, such as configuration records, runbooks, access reviews and sending logs, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies make those determinations. Before you sign, confirm with any implementation partner who owns each control, where the sending logs and suppression data are stored, how long they are retained, and what happens to the platform after go-live.
