Skip to content
PMTA · LIFETIME LICENSE · BARE-METAL · NO KYC

PowerMTA without the Bird invoice and the year-long sales cycle.
Genuine license, hardware, reference configuration. One bundle.

PowerMTA is the gold-standard MTA for high-volume email sending. It also costs €5,500 to €8,000 annually direct from Bird, requires an enterprise sales engagement to get a quote, and ships with no preconfigured ISP throttling tables. The software is excellent. The commercial path to acquiring it is hostile to operators who want the software without the consulting wrapper.

We resell genuine PowerMTA licenses through an authorised reseller arrangement, bundle them with dedicated bare-metal hardware in our offshore jurisdictions, and deploy a production-tested reference configuration. €1,499 one-time covers the perpetual license and our 2-hour onboarding. €199 to €449 monthly covers the server, IPs, and operational support. No annual subscription, no KYC, crypto billing, full ownership of the resulting infrastructure.

License Lifetime · €1,499
Server From €199/mo
Setup 24-48 hours
Capacity 1M to 20M+ daily
why PowerMTA still defines the category

What PowerMTA does that Postfix and Sendmail do not.

The standard answer to "which MTA should I run for email sending" used to be Postfix or Sendmail, with Exim as a third option for shops that liked complicated config syntax. Those answers remain correct for transactional mail at moderate volume, corporate inbound mail, internal relay infrastructure, and most general SMTP use cases. Postfix in particular handles tens of thousands of daily messages without strain, has excellent documentation, and a large operator community.

The answer changes around the 100K daily message threshold, and changes definitively above 1M daily. Postfix lacks the per-IP virtual MTA isolation that serious sending requires. It has no native concept of recipient-domain throttling tables, no native FBL processing, no integrated bounce categorization by enhanced status code, and no per-receiver backoff state machine. You can build all of that on top of Postfix with glue scripts, custom queue management, and external tooling, and many ESPs have. The end result is fragile, undocumented infrastructure that one engineer in your operation understands.

PowerMTA was built for the high-volume sending case from day one. The configuration syntax mirrors the operational model: virtual MTAs map IPs to sending personas, queues map (VMTA, recipient-domain) tuples to delivery state, mx-rollup-list groups receiver MX hosts that share backend infrastructure (so Hotmail, Outlook.com, Live.com all share one queue because Microsoft routes them through the same MX cluster), domain-macro definitions group related domains for shared throttling policy, and smtp-pattern-list rules drive automatic backoff when receivers signal rate limiting through 421 or 451 responses. The whole stack is one piece of software with coherent operator semantics.

The newcomer is KumoMTA, open-sourced in 2023 by the architect of Momentum (one of PowerMTA's only historical competitors). KumoMTA is excellent technology with a more modern configuration model (Lua-based programmable rules rather than declarative config files), built-in observability via Prometheus metrics and OpenTelemetry, and a license that costs nothing. The trade-off: smaller operator community, fewer publicly documented configurations for niche scenarios, and a DevOps-oriented operational model that maps poorly onto traditional server-admin workflows. We deploy and support both PowerMTA and KumoMTA. Most operations request PowerMTA because the operational community knowledge is larger and the configuration patterns are stable across decades.

Capability Postfix KumoMTA PowerMTA
Cost Free Free (open source) €1,499 lifetime via us / €5,500-8,000+/yr direct
Per-IP virtual MTAs External tooling Native, Lua-configurable Native, declarative
Per-domain throttling Not native Native, programmable Native, declarative
FBL processing External Built-in Built-in
Bounce categorization Basic Detailed, programmable Detailed, by enhanced status
Operational community Very large, general SMTP Small, growing Large, ESP-focused
Configuration model Plain text directives Lua programmable Declarative tag-based
Sustained capacity ~100K daily before strain Tens of millions daily Tens of millions daily
Best for Transactional, corporate Modern DevOps shops ESPs, mature operations
three configurations · three capacity tiers

PowerMTA bundled with the right hardware for your volume.

Same hardware tiers as our dedicated server fleet (E3, E5, EPYC) sized to PowerMTA workload characteristics. Each plan includes the perpetual license, our reference configuration, 2-hour onboarding, and ongoing operational support of the underlying infrastructure.

Up to 1M sends/day

PowerMTA · Iron-E3

€199 / month
+ €1499 one-time (lifetime PowerMTA license + setup)
  • CPU. Intel Xeon E3-1245v6 (4c/8t)
  • RAM. 32 GB DDR4 ECC
  • Storage. 2 × 1 TB NVMe RAID-1
  • Network. 30 TB / 1 Gbps
  • Capacity. 1M daily
  • Genuine perpetual PowerMTA license
  • Reference configuration deployed
  • 2-hour onboarding session
  • FBL ingester + bounce processor
  • Per-receiver throttling tables
  • 1 IPv4 + IPv6 /64, custom rDNS
  • IPMI v2 + hardware monitoring
  • Volumetric DDoS protection
  • Engineer-direct support
  • Cancel server anytime, license is yours
Order on Telegram
20M+ sends/day · multi-tenant ESP scale

PowerMTA · Iron-EPYC

€449 / month
+ €1499 one-time (lifetime PowerMTA license + setup)
  • CPU. AMD EPYC 7402P (24c/48t)
  • RAM. 128 GB DDR4 ECC
  • Storage. 2 × 4 TB NVMe RAID-1
  • Network. unmetered / 10 Gbps
  • Capacity. 20M+ daily
  • Genuine perpetual PowerMTA license
  • Reference configuration deployed
  • 2-hour onboarding session
  • FBL ingester + bounce processor
  • Per-receiver throttling tables
  • 1 IPv4 + IPv6 /64, custom rDNS
  • IPMI v2 + hardware monitoring
  • Volumetric DDoS protection
  • Engineer-direct support
  • Cancel server anytime, license is yours
Order on Telegram

Capacity figures assume mixed receiver traffic (60% Gmail and Yahoo, 30% Microsoft, 10% other), reasonable list quality, and per-receiver throttling tuned to standard thresholds. Pure transactional traffic to a single receiver category reaches significantly higher numbers; aggressive cold-outreach throttling lowers them. Volume planning is part of onboarding and we revise the capacity model based on your actual sending mix during the first 30 days.

how PowerMTA works under the hood

Architecture: VMTAs, queues, mx-rollup, backoff state machine.

PowerMTA's runtime model is what makes it different from general-purpose MTAs. Five concepts compose the operational layer; understanding them is the difference between configuring PowerMTA for production and configuring PowerMTA for nothing in particular.

Virtual MTAs (VMTAs)

Each IP address that PowerMTA sends from is wrapped in a virtual MTA definition. A VMTA carries an IP, an associated rDNS hostname (HELO/EHLO), a DKIM signing key, and an independent reputation that receivers track against that specific IP. Sending domains are not VMTAs; domains can route across multiple VMTAs (for IP rotation) or one VMTA can carry multiple domains. The VMTA abstraction is what enables IP-pool architectures: ten VMTAs in a pool, traffic distributed across them based on current reputation health, with hot IPs throttled and cold IPs warmed.

Queue separation per VMTA per recipient domain

PowerMTA maintains a separate delivery queue for each (VMTA, recipient-domain) tuple. Mail to gmail.com from VMTA-1 sits in one queue; mail to gmail.com from VMTA-2 sits in another; mail to yahoo.com from VMTA-1 sits in a third. Queues track concurrent connections to the receiver, current rate, backoff state, and pending retry timers independently. The granularity matters: when Gmail starts deferring traffic from VMTA-1, only VMTA-1's gmail.com queue enters backoff; VMTA-2 keeps delivering normally, and VMTA-1's yahoo.com queue is unaffected.

mx-rollup-list for receiver families

Many receivers route mail through shared MX infrastructure across many domains. Microsoft handles hotmail.com, outlook.com, live.com, msn.com, and dozens of regional variants through the same MX cluster. Yahoo handles yahoo.com, ymail.com, rocketmail.com, and AOL properties since the Verizon-era acquisition through shared infrastructure. PowerMTA's mx-rollup-list lets you collapse mail for all those domains into a single queue per VMTA, because the receiver applies rate limits at the MX cluster level rather than per recipient domain. Without mx-rollup, sending 1000/h to each of five Microsoft domains exceeds Microsoft's 1000/h aggregate threshold and triggers throttling. With mx-rollup, the queue aggregates to 1000/h total against the Microsoft cluster.

domain-macro for shared throttling policy

The complement to mx-rollup-list. Instead of grouping by MX (which the receiver controls), domain-macro groups by domain (which you control). Useful when several domains you send to should share throttling settings without necessarily sharing the MX. Common pattern: a domain-macro definition for "small EU ISPs" with conservative rates covering 50+ regional ISP domains, applied as a single throttling block rather than 50 separate per-domain definitions.

smtp-pattern-list and the backoff state machine

Receivers signal rate limiting through SMTP responses: 421 (service temporarily unavailable), 451 (try again later), 452 (mailbox full but try again), specific 4xx patterns from major ISPs ("rate limit exceeded", "deferred due to volume"). PowerMTA's smtp-pattern-list watches for these patterns and triggers automatic backoff: the queue enters a slower sending state for a configurable cooldown period, then ramps back to normal rate. Configured correctly, this self-tuning behaviour responds to receiver pressure faster than human operators can react, and protects sender reputation by avoiding sustained rate-limited sending.

These five concepts compose the operational model. Our reference configuration encodes battle-tested values for each, tuned across many customer deployments and refined as receivers update their thresholds. You can override every value; the configuration is yours to modify after handover. The reference exists so you do not start from a blank file.

reference configuration · representative excerpt
# Microsoft cluster (Outlook, Hotmail, Live, MSN)
<mx-rollup-list>
  mx *.olc.protection.outlook.com  microsoft.rollup
  mx *.outlook.com                 microsoft.rollup
  mx *.hotmail.com                 microsoft.rollup
</mx-rollup-list>

# Per-receiver throttling, tuned to current thresholds
<domain microsoft.rollup>
  max-smtp-out          5
  max-msg-rate          1000/h
  max-msg-per-connection 20
  smtp-pattern-list     backoff-microsoft
  retry-after           30m
</domain>

# Backoff pattern: slow down on Microsoft 421/451
<smtp-pattern-list backoff-microsoft>
  pattern "421 RP-001"   action backoff   factor 0.5
  pattern "421 RP-002"   action backoff   factor 0.3
  pattern "451 4.7.0"    action backoff   factor 0.7
</smtp-pattern-list>

# VMTA-1 with custom HELO and DKIM
<virtual-mta vmta-1>
  smtp-source-host  203.0.113.10  send.example.com
  domain-key        s2026,*,/etc/pmta/dkim/s2026.pem
</virtual-mta>

# VMTA pool for traffic rotation across 8 IPs
<virtual-mta-pool send-pool>
  virtual-mta vmta-1, vmta-2, vmta-3, vmta-4
  virtual-mta vmta-5, vmta-6, vmta-7, vmta-8
</virtual-mta-pool>

Excerpt only. Full reference configuration is roughly 800 lines covering Gmail, Yahoo, Microsoft, Apple, AOL, Yandex, Mail.ru, ProtonMail, GMX, Web.de, regional ISP families, FBL ingestion, accounting log streams, and DKIM key management.

interactive · capacity planner

Sizing PowerMTA for your sending profile.

The right plan depends on daily volume, receiver mix, peak burst pattern, and number of sending domains. Use the planner to map your profile to the correct hardware tier and identify the configuration questions worth discussing during onboarding.

recommended configuration

PowerMTA · Iron-E5

€299/mo + €1,499 one-time range €199-€449/mo
Hardware Iron-E5 baseline
Daily capacity Up to 5M
VMTAs 8-16 in standard layout
Headroom ~40% above target
why this configuration

For 500K-2M daily across mixed receivers, the E5 platform's 14-core throughput handles the queue parallelism without bottlenecking. 64 GB RAM provides headroom for peak queue states. NVMe RAID-1 keeps PowerMTA's accounting logs writing without I/O contention.

configuration considerations during onboarding
  • VMTA pool architecture: dedicated per brand vs. shared rotation pool
  • FBL ingester routing: per-VMTA vs. consolidated
  • Logging retention: hot logs on local NVMe, cold logs to backup target
  • Backup VMTA strategy: standby IPs for emergency rotation

Capacity planning is iterative. The first 30 days establish actual throughput and receiver behaviour for your specific mix; we revise the configuration based on observed metrics. If your initial estimate undershoots and you outgrow the tier within 90 days, hardware upgrade is straightforward (configuration migrates across tiers without modification).

when to deploy PowerMTA

Use cases that justify the licensing investment.

PowerMTA's economics make sense for sustained sending operations. A €1,499 perpetual license amortises across millions of messages over years; the per-message cost becomes effectively zero past a few months of operation. Below are the operational profiles where deployment consistently pays off.

01

Customer-facing ESP

Multi-tenant email service providers selling sending capacity to end customers. Each customer needs their own VMTA pool, separated reputation, isolated FBL handling, and per-tenant accounting. PowerMTA's VMTA architecture maps cleanly onto this model: one VMTA pool per customer tier, customer-specific throttling policy, accounting logs feeding billing systems. The standard ESP MTA choice for the past two decades.

02

High-volume marketing operations

Newsletter operators, bulk marketing agencies, and in-house marketing teams sending 500K to 10M daily messages. PowerMTA's per-receiver throttling handles the scale; FBL processing automatically suppresses complainers; bounce categorisation feeds list hygiene workflows. The alternative for this volume profile is building extensive tooling around Postfix, which most shops eventually abandon for PowerMTA or KumoMTA.

03

Cold outreach at scale

Cold outreach operations sending to non-permission-based recipient lists at significant volume. The throttling discipline PowerMTA enforces is exactly what cold outreach needs to avoid blacklisting; the per-IP VMTA isolation prevents one burned IP from contaminating others; subdomain rotation pools distribute reputation risk across many sending identities. Architecture patterns common: 30-50 sending subdomains, 10-30 IPs, VMTA pool with reputation-based rotation.

04

Transactional at platform scale

SaaS platforms generating millions of transactional messages daily (signup confirmations, password resets, billing notifications, notification emails). The volume justifies dedicated infrastructure over SMTP relay services like SendGrid or Mailgun whose costs scale per-message. Break-even from SMTP relay to self-hosted PowerMTA typically occurs around 2-3M monthly messages.

05

Multi-brand multi-jurisdiction sending

Operations with sending across distinct brands or jurisdictions where reputation isolation matters. Brand A's traffic must not contaminate Brand B's reputation; jurisdiction-specific compliance requirements (CAN-SPAM, CASL, GDPR, local equivalents) require separate accounting trails. PowerMTA's VMTA pool model with per-brand isolation handles this cleanly; a single PowerMTA instance can carry 50+ brand-isolated sending identities.

06

Affiliate marketing infrastructure

Affiliate operations running aggressive sending patterns: multi-domain rotation, IP rotation pools, subdomain warming, controlled reputation burning when a domain or IP starts failing. PowerMTA's tooling for VMTA reputation management, automatic backoff, and granular per-receiver behaviour fits the operational tempo. This is the most common request from operators we onboard.

total cost of ownership

PowerMTA economics across alternatives.

The price tag on the software hides the real economics. What matters is total cost across hardware, license, configuration, and operational maintenance for a representative sending profile over an operational horizon. Below is a working model for a 5M daily messaging operation across four common architecture choices.

Scenario: 5M daily messages, mixed receiver mix, 12 sending IPs, 5 sending domains, 3-year operational horizon, target inbox placement > 85%. Single-node sending architecture.
alternative

PowerMTA direct from Bird

Annual subscription (entry tier)~€7,500/yr · €22,500/3yr
Cloud hardware (AWS r5.2xlarge)~€340/mo · €12,240/3yr
Bandwidth (15TB/mo at AWS rates)~€1,200/mo · €43,200/3yr
Elastic IPs + setup~€500/3yr
3-year total~€78,440

Bandwidth alone exceeds our entire bundle. Annual license escalation common in enterprise contracts. Plus consulting hours typically billed separately.

free option

KumoMTA self-hosted

License€0 (open source)
Iron-E5 hardware (with us)€169/mo · €6,084/3yr
Extra IPv4 (8)€64/mo · €2,304/3yr
Engineering time to build config (200h)€39,800 internal cost
3-year total~€48,188

Software free; engineering time to build production configuration is the dominant cost. Worth it for shops with the engineering capacity and DevOps culture; expensive for shops without.

avoid for this volume

SendGrid / Mailgun / SES

5M monthly at SendGrid Pro~€500/mo · €18,000/3yr
Volume above plan tier~€800/mo · €28,800/3yr
Dedicated IP addons (12)~€700/mo · €25,200/3yr
3-year total~€72,000

Pay-per-message economics break above 1-2M monthly. Plus reduced control: AUPs disqualify many operations, IPs are not actually dedicated despite the name, list ownership murky.

The directional point: at 5M daily volume, the choice collapses to "PowerMTA via us" or "KumoMTA self-built." Bird-direct PowerMTA pricing assumes you need the consulting engagement; if you do not, our reseller arrangement is roughly 80% cheaper. SaaS relays make sense for under 1M monthly volume; above that, dedicated infrastructure dominates the economics.

what is included

The standard PowerMTA bundle.

01

Genuine perpetual license

Real PowerMTA license registered to your operation, sourced through authorised reseller channels. License key yours to keep; if you migrate to another infrastructure provider, the license travels with you. Lifetime entitles you to the version installed; major version upgrades typically require new licenses from upstream Bird.

02

Reference configuration deployed

Production-tested config covering Gmail, Outlook, Yahoo, AOL, Apple, ProtonMail, Yandex, Mail.ru, GMX, Web.de, regional ISP families. Per-receiver throttling tables tuned to current thresholds. Backoff smtp-pattern-list for major receivers. mx-rollup-list grouping. domain-macro definitions for receiver families. FBL ingester routes. ~800 line configuration.

03

2-hour onboarding session

Live walkthrough of the deployed configuration, architecture decisions, where to extend for your specific use cases. Telegram or Jitsi, recorded if you want it for team reference. Engineer-direct, not scripted onboarding. Additional hours billable at consulting rate if you need extended help.

04

FBL ingester service

Configured to receive feedback loops from major ISPs (Microsoft, Yahoo, Comcast, AOL, regional providers with FBL programs). ARF-format complaint reports parsed, recipients added to suppression list, delivery to complainers stopped automatically. The complainer suppression alone saves hours of manual list hygiene per week at scale.

05

Bounce processor + categorisation

Bounces parsed and categorised by SMTP enhanced status code (5.1.1 mailbox unavailable, 5.2.1 mailbox disabled, 5.7.x policy rejection, soft-bounce 4xx codes for retry queues). Hard bounces feed suppression; soft bounces feed retry logic with appropriate backoff. Output streams parseable by external tooling.

06

DKIM key generation + management

2048-bit DKIM keys generated per sending domain, published to DNS, integrated into PowerMTA signing configuration. Selector rotation hooks ready for quarterly rotation discipline. Multi-key support per domain for cutover periods during rotation.

07

Accounting log streams

PowerMTA's structured logs configured for downstream consumption: delivery accounting, bounce accounting, FBL accounting, queue accounting. JSON-format available; default tab-delimited compatible with standard log analysis tooling. Hot logs on local NVMe; rotation policy preconfigured.

08

Hardware infrastructure

All standard dedicated-server inclusions: bare-metal with IPMI, Tier 1 BGP transit, custom rDNS, IPv4 + IPv6, hardware monitoring, SLA-backed replacement, volumetric DDoS. The PowerMTA bundle does not strip standard infrastructure benefits.

09

Engineer-direct support

Tickets and Telegram route to engineers familiar with PowerMTA. Routine questions answered without escalation. Major configuration changes (new VMTA pools, new receiver throttling profiles, FBL changes) via consulting addon or Deliverability Consulting service.

technical reference

Operational details: licensing, hardware sizing, scaling.

License terms and ownership

The €1,499 license fee delivers a perpetual licence for PowerMTA, sourced through our authorised reseller arrangement with Bird. The license key is registered against your operation's identifier (which we negotiate with the upstream registrar without requiring government-ID KYC on your end; the registration is operational, not regulatory). If you decide to leave us and move infrastructure to another provider, the license key moves with you; we provide license documentation and handover support.

What lifetime covers: indefinite use of the version installed at handover. PowerMTA versions support multi-year operational lifespans without modification; Bird typically issues major version updates every 18-30 months and minor patches more frequently. Major version upgrades after handover are not covered by the lifetime license; we maintain access to current versions through our reseller relationship and can quote upgrade pricing when relevant. Most customers run a major version stably for 3-5 years before updating.

What lifetime does not cover: Signals analytics platform (Bird's separate analytics product, requires its own subscription), enterprise consulting from Bird directly (out of scope of our reseller arrangement), and any upstream changes Bird makes to commercial terms after your license is issued (those affect future purchases, not your existing license). The license is bulletproof against future commercial changes; future purchases would be at then-current pricing.

Hardware sizing rationale

PowerMTA's bottlenecks are CPU (queue processing, DKIM signing), RAM (queue state in memory), and disk I/O (accounting log writes). Network is rarely bottleneck below 10 Gbps because SMTP delivery is latency-bound, not throughput-bound; one slow receiver does not slow others.

Iron-E3 (4 cores, 32 GB) sustains the queue management for ~1M daily messages with reasonable peak headroom. DKIM signing on E3-1245v6 reaches 8,000-12,000 signatures per second across cores, which translates to roughly 1.5-2x the daily message rate as headroom. At 1M daily, peak-hour rate around 80,000/h fits comfortably in this envelope.

Iron-E5 (14 cores, 64 GB) handles 5M daily because the core count parallelises queue scheduling more effectively. At peak hours of 400,000/h, multiple receiver queues run concurrently without scheduling conflict. 64 GB RAM provides headroom for queue backlogs during receiver backoff (queued messages stay in memory until delivery or expiration).

Iron-EPYC (24 cores, 128 GB) reaches 20M+ daily because PowerMTA scales cleanly across cores once queue partitioning has enough work to distribute. EPYC's PCIe 4.0 NVMe throughput keeps accounting log writes from becoming I/O-bound. At very high volumes (50M+ daily), dual-EPYC configurations or horizontal scale across multiple PowerMTA nodes becomes the architecture; we quote those configurations on request.

Horizontal scaling architecture

Single PowerMTA nodes scale to roughly 50M daily messages on appropriate hardware before queue management overhead dominates. Above that, multi-node architectures distribute traffic across PowerMTA instances. Common patterns: 2-4 nodes load-balanced via DNS round-robin, each with non-overlapping IP allocations, accounting logs streamed to centralised storage for unified reporting. The configuration replicates across nodes (modulo IP differences); we deploy multi-node architectures as custom engagements.

Multi-jurisdiction sending follows the same horizontal pattern with the additional consideration of latency: PowerMTA nodes in different jurisdictions run independently, with traffic routed at application level based on origin or compliance requirement. We deploy this pattern frequently for operators needing both EU and APAC presence; the per-node cost remains the same, orchestration adds operational complexity that some customers handle in-house and others delegate to us as consulting.

Updates and upgrades

PowerMTA security patches issued by Bird are forwarded to customers within 30 days of release; we test patches in our staging environment before recommending deployment. Major version upgrades require commercial conversation: lifetime licence covers the version at handover, major version transitions are typically €499-799 depending on version delta. Most operations stay on a major version for 3-5 years; the upgrade decision depends on whether new features matter to your operation.

questions before you order

Frequently asked.

Is the PowerMTA license genuine and resold legally?

Yes. We resell genuine PowerMTA licenses sourced through authorised channels. The license key is registered to your operation, you hold it perpetually, and you can take it to another infrastructure provider if you ever leave us. No keygens, no cracked builds, no shared keys across customers. We are transparent that we are a licensing reseller in addition to operating the infrastructure: it is the only way to deliver lifetime licensing at this price point given that Bird (the upstream vendor) currently quotes €5,500 to €8,000 per year for direct enterprise licenses.

Why is your pricing so much lower than Bird directly?

Two reasons. First, Bird sells through enterprise sales motions with consulting, support, and Signals analytics bundled at significant markup. Most operators do not need consulting on top of the software. Second, our reseller arrangement gives us volume pricing on the underlying license. We pass that through to customers as a one-time perpetual license at €1,499 rather than annual subscription. Direct enterprise customers needing the full Bird relationship (white-glove onboarding, Signals analytics, dedicated TAM) should buy direct; operators needing the software with their own ops team get better economics through us.

What does the reference configuration include?

The PowerMTA config we deploy is production-tested across hundreds of operations: per-IP virtual MTA definitions, mx-rollup-list grouping major receiver families (Gmail, Outlook/Microsoft, Yahoo/Verizon, Apple, Yandex, Mail.ru, regional ISPs), domain-macro definitions for ISP families with shared infrastructure, recipient-domain throttling tables tuned to receiver thresholds, backoff smtp-pattern-list for automatic rate adjustment on 421/451 responses, FBL ingester service, bounce processor with categorisation by SMTP enhanced status code, DKIM key management with selector rotation hooks, and full accounting log streams. The configuration is yours to customise after handover.

How does PowerMTA compare to Postfix or KumoMTA?

Postfix is excellent for transactional mail and corporate infrastructure but lacks per-IP virtual MTA isolation, granular per-recipient-domain throttling, integrated FBL processing, and the operational tooling around large-scale sending. Postfix maxes out around 100K daily messages before configuration becomes unwieldy. KumoMTA (open source, free) is the modern alternative purpose-built by the Momentum architect; technically excellent and economically attractive but with a smaller operational community and DevOps-oriented configuration model. PowerMTA remains the default for ESPs and operators who value mature tooling, predictable behaviour, and twenty years of accumulated knowledge in the operator community. We deploy and support all three; PowerMTA is the most common request.

What sending volume does each plan support?

Iron-E3 sustains around 1M daily messages with reasonable concurrency to major receivers. Iron-E5 handles up to 5M daily, the standard ESP single-node capacity. Iron-EPYC handles 20M+ daily with multi-tenant VMTA pools and parallel queue processing across 24 cores. These numbers assume mixed receiver mix (60% Gmail/Yahoo, 30% Microsoft, 10% other) and reasonable list quality. Pure transactional traffic to a single receiver tier reaches higher numbers; aggressive per-domain throttling for marketing campaigns lowers them. Volume planning is part of the onboarding conversation.

Can I run multiple sending domains and IPs from one PowerMTA?

Yes. PowerMTA was designed for this. Each IP gets its own virtual MTA (VMTA) definition in the config, with independent reputation, rDNS, DKIM signing, and throttling profile. Sending domains are independent of VMTAs; one domain can pour traffic across multiple VMTAs (IP rotation) or one VMTA can carry multiple domains. The reference configuration supports up to 32 IPs per server in our standard layout; larger pools supportable via custom configuration on EPYC hardware.

What happens if Bird discontinues PowerMTA or changes licensing?

Your perpetual license remains valid for the version installed. Bird (or any successor entity) cannot retroactively invalidate licenses already issued. The risk you carry is around future updates: if Bird stops releasing new versions or significantly changes the licensing model for new versions, you remain on the version you have. Practically, PowerMTA versions support multi-year operational lifespans without updates; we have customers running PowerMTA 4.5 in production stably. If Bird discontinues development, KumoMTA migration becomes the natural path; we support that migration at the standard MTA migration rate when it becomes relevant.

Do you offer ongoing tuning and support?

The monthly plan includes hardware, IP allocation, and basic operational support (server uptime, hardware replacement, network issues). Per-receiver tuning, throttling adjustments, FBL configuration changes, and deliverability-focused configuration changes after the initial reference deployment are billed at our consulting rate (€199/hour) or available as a managed addon at €299/month for ongoing tuning across the entire send fleet. Most customers manage their own configuration after the initial 2-hour handover and only call us in for major changes.

Can I pair PowerMTA with MailWizz or another front-end?

Yes. PowerMTA is delivery infrastructure; it does not provide a campaign UI, list management, or template system. The standard architecture pairs PowerMTA with a front-end that handles those concerns. MailWizz is the most common pairing in our customer base; alternatives include Mautic, SendPortal, or custom in-house front-ends that submit via SMTP or PowerMTA's submission API. Front-end installation is a separate engagement (Mail Stack Setup at €299) or you can deploy your own.

What if I want to start smaller and upgrade?

Start at any tier; upgrade by migration when volume justifies it. Configuration moves cleanly between tiers (the same config works across hardware sizes). Migration takes 4-8 hours including DNS propagation; we coordinate to minimize sending downtime. The license is one-time and applies regardless of which tier you run on; you do not re-pay license on hardware upgrade.

Ready to deploy PowerMTA?

Telegram order takes 15 minutes. Hardware provisioned within 24 hours. PowerMTA installed with reference configuration and license activated within 24-48 hours of hardware availability. 2-hour onboarding scheduled at your convenience. License is yours regardless of cancellation.

# Median Telegram response: 12 minutes during operating hours