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.