Skip to content
PROJECT-SCOPED · 24-48 HOURS

A working production stack in 48 hours.
We deploy, configure, hand you root, and verify the first send.

PowerMTA bound to your dedicated IPs with proper VMTA pool architecture. MailWizz on a tuned database server with Redis caching and supervisor-managed queue workers. DKIM signing keys generated and published. SPF authorised. DMARC at p=none with aggregate reporting active. MTA-STS policy live. Custom rDNS aligned with HELO. FBL inboxes connected and parsing. FCrDNS verified. You can ship the first campaign 24 hours after kickoff.

Most operators take five or six weekends to get this stack into production themselves. The PowerMTA documentation alone runs to 600 pages, MailWizz adds another 300, and the integration between them is undocumented. We do the integration in two days because we've done it 400 times.

price €299
delivery 24-48 hours
warranty 14 days
handover runbook + walkthrough
why DIY usually drags

The PowerMTA docs don't tell you about MailWizz. The MailWizz docs don't tell you about PowerMTA.

The PowerMTA reference manual is genuinely good. It runs about 600 pages and covers every directive, every VMTA option, every pickup directory knob, every accounting field. The MailWizz documentation is also fine. About 300 pages, covers most of the admin UI and the API. Neither documents how to make the two cooperate. That's the part you'll spend three weekends on.

The integration touches half a dozen non-obvious surfaces. MailWizz needs delivery servers configured to route through PowerMTA's submission port, not its standard SMTP port. PowerMTA needs accounting files placed where MailWizz's bounce processor can read them, in the format MailWizz expects. The bounce-classification rules in PowerMTA need to align with MailWizz's internal categories or you end up suppressing soft-bounces and retrying hard-bounces. DKIM signing happens in PowerMTA, not MailWizz, but the selector configuration lives in MailWizz's delivery server settings. The rDNS gets set at the IP level but PowerMTA needs to declare it as HELO and MailWizz needs to know which delivery server uses which IP.

And then there's the operational layer. supervisor managing the queue workers and bounce processors so the daemons restart cleanly. cron schedules for FBL pulls, list maintenance, bounce processing. Log rotation tuned so the accounting files don't fill the disk. Database tuning so MailWizz's tracking events don't slow campaign delivery. Redis configured so MailWizz caches sessions instead of hammering the database. Per-receiver throttling profiles tuned for Gmail vs Outlook vs Yahoo vs Apple, because each receiver has different rate-limit responses and PowerMTA's defaults are not optimal for any of them in 2026.

None of this is hard, individually. There's enough of it that the first time through takes most engineers five to six weekends. We've done it enough times that we have it deployed clean in a day. That's what the €299 buys.

the stack we ship

What gets installed and configured.

Click any component to see the specific items configured at that layer. Everything in the diagram is part of the standard €299 scope.

honest fit assessment

Who orders this, and who shouldn't.

good fit
  • You bought (or want to buy) PowerMTA and MailWizz licenses but don't want to spend two weekends getting them to talk to each other for the first time.
  • You're moving from SaaS (Mailgun, SendGrid, Mailchimp) to self-hosted and need a working baseline before migration day.
  • You have engineering capacity to operate the stack but no internal expert on first-time MTA deployment. Operating it day-to-day is much easier than setting it up.
  • You're running an agency and need a repeatable, documented stack for client deliverables. The runbook we ship doubles as your client-handover documentation.
  • You hired a freelancer who got it half-working and you need someone to finish or fix it. We can take over from any state of partial completion; mention what's done at intake.
  • You're scaling past SaaS economics (50K+ monthly volume) and the deployment is the only thing standing between you and lower per-message costs.
poor fit
  • You want everything managed forever. Buy a Bundle (WaaS, Cold Outreach, ESP Starter, Recovery Pack) instead. This is just the initial setup, not ongoing operations.
  • You don't have PowerMTA license and don't want to buy one. We can resell lifetime (€1499) or rent monthly (€99/mo). Mention at intake. Postal or open-source alternatives are not part of this scope.
  • Volume below 100K monthly. The infrastructure is overkill for your scale. Consider the SMTP Relay tier (€69-249/mo) where the operations are bundled and the per-message cost is comparable.
  • You need a custom front-end ESP that isn't MailWizz or Acelle. We do MailWizz, Acelle, or Postal as standard. Other systems on quote.
  • You expect to operate the stack with no Linux admin background. The runbook helps but it doesn't replace having someone on staff who can SSH into a server and read logs.
DIY vs freelancer vs us

Cost-of-time calculator.

Adjust the inputs to your situation. The calculator runs the math on three options: doing it yourself, hiring a freelancer at market rate, or paying us €299. Output below.

€80/hour

What is an hour of your time genuinely worth, accounting for the work you're not doing while you set up MTAs?

First-time PowerMTA + MailWizz integration takes 60-80 hours. Each level of experience cuts that meaningfully.

€90/hour

Mid-market rate for deliverability freelancers on Upwork and Toptal. Top-tier is €120-180; the cheap ones cost more in rework.

option 1

You do it yourself

Time 60h
Cost €4,800

Wall-clock time: 4-6 weekends, assuming you're doing this around your day job.

option 2

You hire a freelancer

Time (theirs) 25h
Cost €2,250

Wall-clock time: 1-3 weeks. Variability depends entirely on the freelancer's other commitments.

option 3 · this is us

You order from ASH

Your time ~1h intake
Cost €299

Wall-clock: 24-48 hours. Includes runbook, 14-day warranty, walkthrough call.

Calculator math: DIY hours scale with experience tier (60h, 50h, 30h, 18h). Freelancer hours assume mid-tier productivity. Your-time-cost = DIY hours × your hourly rate. Freelance cost = freelancer hours × freelancer rate. We assume nothing about quality of result; we've cleaned up freelance work often enough that "cheaper" sometimes means "more expensive after the rework."

scope of work

Every task we run between order and handover.

01

Infrastructure provisioning

Dedicated server provisioned in your chosen jurisdiction (Bulgaria, Romania, Moldova, Panama, Hong Kong, Singapore, Ukraine). Hardware specs aligned with your expected volume, we don't oversize you into paying for capacity you won't use.

Operating system hardened. SSH key-only authentication. fail2ban running with sane defaults. ufw firewall configured to allow only what we need. Automatic security updates enabled. Time synchronisation via chrony. Hostname configured to match what HELO will declare.

PowerMTA-recommended kernel tuning applied: TCP backlog increased, file descriptor limit lifted, ephemeral port range expanded, somaxconn raised. Default kernel limits cap PowerMTA's throughput at perhaps 10% of what it can do; we configure for what you're actually paying for.

02

PowerMTA installation and configuration

Latest stable PowerMTA installed and licensed. Service-managed by systemd with restart policy. Log rotation tuned so accounting files don't fill the disk. Firewall holes opened only where needed.

VMTA pool architecture designed for your specific use case. Per-customer pools if you're an agency. Per-message-type pools if you mix transactional and marketing. Per-warmup-stage pools if you're starting fresh with multiple new IPs. The architecture choice has direct deliverability consequences and we make it deliberately, not by default.

Per-receiver throttling profiles tuned for 2026. Gmail, Outlook, Yahoo, Apple, AOL each get their own retry-and-backoff configuration calibrated to current observed receiver behaviour, not the documentation defaults from 2018. Bounce categorisation rules align hard, soft, transient, content-rejection, IP-rejection, policy-rejection. Accounting files routed for downstream ingestion (MailWizz bounce processor, parsedmarc, custom analytics).

03

MailWizz Pro installation and tuning

MailWizz Pro installed on its own service. License registered. php-fpm and nginx configured for the workload. PHP opcache tuned for persistent applications.

MariaDB tuned for tracking-event throughput: innodb_buffer_pool_size set to 60-70% of RAM, innodb_flush_log_at_trx_commit calibrated for durability vs throughput, query cache disabled (it hurts at the scales we operate at), max_connections increased.

Redis configured for sessions and queue cache. Supervisor managing campaign delivery workers, bounce processors, and FBL pullers with automatic restart on failure. Worker count scaled to expected campaign concurrency. cron schedules configured for list maintenance, tracking aggregation, statistics rollups. Initial admin and API user provisioned with credentials handed over securely.

04

DNS authentication, full stack

SPF record published authorising your sending IPs. Lookup count verified under the 10-lookup ceiling exhaustively. Hard-fail terminator (-all) by default; soft-fail (~all) only where your sending profile genuinely needs it.

DKIM keys generated at 2048-bit RSA with rsa-sha256 signing. Public keys published with predictable selector naming (year-quarter format, e.g. 2026q1) so future rotations are clean. Multi-string TXT format applied where the key exceeds the 255-byte single-string limit.

DMARC published at p=none with rua= reporting active to a destination that actually parses (your inbox, parsedmarc, dmarcian, our managed monitoring). Subdomain policy explicit (sp= set, not inherited). Aggregate report ingestion verified.

MTA-STS policy file deployed at the well-known path under HTTPS. Mode set to testing initially, ready for promotion to enforce after 14 days of clean TLS-RPT data. TLS-RPT companion record published. BIMI bootstrap if you have a registered trademark and DMARC enforcement.

05

rDNS, FCrDNS, HELO alignment

Custom rDNS set on every sending IP, aligned with the HELO/EHLO hostname under your sending domain. Forward A records published for the hostname. PTR records configured at the IP allocation level. FCrDNS verified per IP. Both directions of the loop close.

PowerMTA configured to declare the correct HELO per source IP. MailWizz delivery server settings reflect the IP-to-hostname mapping so per-IP signing happens correctly. The whole verification chain tested with a sample send before we declare the rDNS layer complete.

06

FBL enrolment and processing

Microsoft JMRP, Yahoo CFL, Apple FBL enrolment submitted in your name. Verification messages received and confirmed. FBL inboxes set up with IMAP credentials. MailWizz's bounce processor configured to poll them on schedule. Parser tested with the verification messages from each FBL provider.

Suppression-list pipeline verified end-to-end: FBL message arrives, parser extracts the complainant address, suppression entry written to MailWizz, future sends to that address blocked at the queue stage. Verified with a synthetic complaint test before handover.

07

Documentation and handover

Operations runbook documenting every credential, every config file, every cron schedule, every backup job. Diagram of the stack architecture as deployed. Complete list of DNS records published with explanation of each. List of post-handover tasks (BIMI deployment, IP warmup, additional VMTA pools as you scale).

30 minutes of Telegram or Jitsi handover with your team. We walk through the runbook, answer questions about the operational layer, and demonstrate the most common operations (sending a test campaign, checking PowerMTA pickup queue, reading bounce reports). Recording available on request for your team's reference later.

08

14-day warranty

For 14 days after handover, anything we configured that breaks gets fixed at no additional cost. Configuration drift, package upgrade issues, missed edge case in our setup, bug in our runbook, all covered. Things you change yourself afterward (new VMTA you added, different cron schedule, MailWizz plugins) are not covered, but we'll usually help anyway if it's straightforward.

honest expectation-setting

After handover: what works, what's still your job.

Setup is initial deployment, not full operations. Toggle to see what you have versus what you'll need to do (yourself or via our addons) before you can scale to production volume.

Working stack with first test send confirmed

Infrastructure provisioned, PowerMTA + MailWizz running, sample message sent through every VMTA, accepted at major receivers.

All authentication green

SPF, DKIM, DMARC, MTA-STS, TLS-RPT all published and validating. Free SPF/DMARC checkers pass clean.

FBL processing live

Microsoft JMRP, Yahoo CFL, Apple FBL all enrolled and pulling. Suppression pipeline verified.

Custom rDNS, FCrDNS verified

Reverse DNS aligned with HELO. Forward A records published. Loop closes both directions.

Documentation runbook in your hands

Every credential, config file, cron job, backup job documented. Diagrams. Post-handover tasks listed in priority order.

You can send today

Production-ready for first campaigns within minutes of handover, at the appropriate volume for your IP warmup stage.

hour by hour

What happens between order and handover.

Hour 0

Telegram kickoff

You confirm jurisdiction (BG, RO, MD, PA, HK, SG, UA), target volume, sending domain(s), license arrangement (your license, our resold lifetime, our monthly rental). NDA signed. We confirm scope and 24h or 48h delivery target depending on architecture complexity.

Hours 1-12

Infrastructure provisioning

Server provisioned, OS hardened, kernel tuned. PowerMTA and MailWizz installations begin in parallel. Initial PowerMTA configuration (VMTA pool architecture, per-receiver throttling, accounting). Initial MailWizz configuration (database tuned, Redis configured, supervisor managing workers).

Hours 12-24

Authentication and integration

DNS records published (SPF, DKIM, DMARC, MTA-STS, TLS-RPT). rDNS set per IP, FCrDNS verified. PowerMTA-MailWizz integration tested with sample sends. FBL applications submitted (Microsoft JMRP, Yahoo CFL, Apple FBL).

Hours 24-48

Verification and handover

Test campaigns sent through every VMTA. Each major receiver checked for acceptance and authentication pass. Bounce processing verified end-to-end with a synthetic test. Documentation finalised. 30-minute Telegram or Jitsi handover scheduled with your team.

questions before you order

Frequently asked.

Do I need to provide my own PowerMTA license?

Either way works. If you have a license already, we use it. If not, we can resell a lifetime license (€1499, you own it forever, conversion credit from rental if you do that first) or set up a monthly rental (€99/mo, no upfront, includes minor version updates, cancel any month). Postal and other open-source MTAs are a different scope; we deploy them on quote but the standard €299 setup is PowerMTA. Mention your licensing situation at intake.

Can I keep my current ESP and just add PowerMTA on the back end?

Sometimes. PowerMTA accepts SMTP injection from any source, so a custom application or another ESP can hand mail to PowerMTA for actual delivery. We deploy this configuration occasionally where the customer has invested heavily in another front-end (custom CRM with built-in email, Salesforce Marketing Cloud bridges, etc).

But if you're paying for both Mailchimp and PowerMTA, you're probably wasting money. Tell us your current setup at intake; we'll honestly tell you whether the bridged architecture makes sense or whether full migration to MailWizz is better economics.

What about IP warming after setup?

Setup gets you a working stack. IP warming is a separate 30-day operation with its own engagement-network requirements. Combine setup with our Warmup-as-a-Service (€199/mo, single-IP focus) or Multi-domain Warmup (€599 one-time, batch warming for cold outreach). Don't skip warming. New IPs sending production volume on day one is the most expensive mistake we see; it triggers Spamhaus listings within hours and reputation recovery costs more than the warmup would have.

Will you maintain the stack after setup?

Not by default. Setup is a one-time service, at handover you have full ops responsibility. If you want ongoing management, we have specific addons:

  • MailWizz Managed (€49/mo) covers patches, daily encrypted backups, license active
  • Deliverability Monitoring (€49/mo) covers Postmaster Tools, SNDS, 84-RBL polling
  • DKIM Rotation (€29/mo) covers M3AAWG-compliant quarterly rotation
  • Bounce Processing Service (€29/mo) covers FBL handling and suppression hygiene at scale

Mix to your needs. Setup plus a few addons gets you 80% of the way to a Bundle for less than the Bundle.

I already have MailWizz but no PowerMTA. Is the price the same?

Slightly less in practice. Tell us at intake, we adjust scope and pricing. The PowerMTA install is roughly half the work; if you only need PowerMTA installed and integrated with your existing MailWizz, we typically charge €199. Likewise if you have PowerMTA but no front-end ESP, or if you want Acelle instead of MailWizz.

What if something breaks 7 days after handover?

14-day warranty is included on the setup itself. If something we configured breaks (and you didn't change it afterward), we fix it. After day 14, you're on your own unless you have an ongoing maintenance addon or you re-engage us hourly. Keep good backups; the runbook walkthrough at handover covers backup procedures and the most common recovery operations.

Can I get setup in a jurisdiction not in your standard list?

We operate primary infrastructure in 7 jurisdictions: Bulgaria, Romania, Moldova, Panama, Hong Kong, Singapore, Ukraine. We can also deploy on customer-supplied infrastructure (your AWS, Hetzner, OVH, etc.) for the same fee, the constraint is that we need root SSH access and the ability to set rDNS at the IP allocation level, which most major providers grant. For uncommon jurisdictions or providers, mention at intake; we either accommodate or recommend the closest fit.

Do you handle the MailWizz license purchase?

Yes, on request. MailWizz sells direct from their website (€59-99 depending on tier). We can purchase on your behalf as part of the setup or you can buy it yourself before kickoff and provide the purchase code. Acelle Mail and Postal are open source and free.

What's the catch?

There isn't one, but here's the honest framing: setup is a loss-leader for us at €299. We make money when customers stay in our ecosystem (servers, addons, bundles). Most setup customers add at least one addon within 60 days. Some don't, and that's fine, the setup itself is delivered to the same standard either way. If you want to take the documentation runbook and operate elsewhere, the runbook works fine on any equivalent infrastructure.

How does payment work?

Standard process: half upfront (€150) on intake, half (€149) on handover. Payable in any of our 11 supported cryptocurrencies. Self-hosted BTCPay, no third-party processor, no KYC. Invoice generated automatically on order. If scope expands during the project (you decide you also want Acelle alongside MailWizz, or you need 50 IPs warmed instead of 5), we quote the expansion before doing the work.

Setup engagement quality benchmarks

Setup engagement quality reflects in specific operational characteristics that emerge after deployment rather than in deployment artifacts alone. The benchmarks below capture what production-quality setup looks like 30 days after engagement completion.

Authentication coverage: SPF, DKIM, DMARC fully configured across all sending sources with DMARC at minimum p=quarantine. DMARC aggregate reports flow to a dedicated mailbox with parsing infrastructure operational. TLS-RPT and MTA-STS deployed for senders with audience requirements warranting them.

Sending infrastructure: deployed and reputation-warmed for the target volume profile. Initial production sending validated through controlled campaigns demonstrating expected placement across the major receivers. Monitoring infrastructure operational with alerting through customer-preferred channels.

Operational documentation: configuration documented with sufficient detail for customer team to maintain ongoing operations. Runbooks for common operational scenarios (adding new sending source, rotating keys, responding to reputation events) provided. Customer team trained on essential operational practices through documented walkthroughs.

Ready to ship a working stack on day 2?

Telegram intake takes 30 minutes. 24-hour delivery starts after that. Median customer outcome: first production campaign sent within 36 hours of order, full ops handover completed within 48.

# Median Telegram response: 12 minutes during operating hours