Source-state audit
Current sending volume by mailbox provider, IP pool composition, domain authentication state, suppression list export, reputation baseline (Postmaster Tools, SNDS, Talos), bounce and complaint rate trends.
ONE-TIME | DUAL-MTA CUTOVER | 21 BUSINESS DAYS | EUR 1,499
Migrate from cloud SMTP without the 4-8 week deliverability cliff that flip-and-pray cutovers produce.
Migrate from cloud SMTP without the 4-8 week deliverability cliff that flip-and-pray cutovers produce.
Dual-MTA running in parallel, traffic shifted gradually over 4-6 weeks, suppression lists preserved, 30-day post-migration support.
The structural problem with switching MTAs is reputation continuity. Your sending reputation is built up over months or years at your current MTA: recipient mailbox providers have learned your sending patterns, your IP reputation history, your authentication setup. Switching cold to a new MTA with new IPs resets all of that reputation to zero. A naive cutover that flips all traffic on day one typically produces a 4-8 week deliverability dip while the new infrastructure builds reputation from scratch. The dual-MTA cutover pattern documented in M3AAWG sending guidelines and reflected in the Postmastery migration case studies avoids this by running both old and new infrastructure simultaneously and shifting traffic gradually over 4-6 weeks. The Jobtome migration documented by Postmastery replaced 30 Postfix instances with one PowerMTA with a 2-month IP warmup phase preserving deliverability throughout.
MTA Migration handles the move from cloud SMTP (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost) or legacy on-premise MTA to self-hosted PowerMTA, Postfix, or Exim on ASH infrastructure. Source-state audit covering current sending volumes, IP pools, domain configuration, suppression list, and reputation baseline. Target-state architecture matching your operation sending profile. Dual-MTA cutover plan with traffic shifting in phases over 4-6 weeks. Suppression list migration with hard-bounce, complaint, and unsubscribe events preserved in append-only log format. DNS authentication update coordinated with TTL pre-staging. Per-ISP throttling configuration on the new MTA matching your historical sending patterns. Bounce processing pipeline (synchronous, asynchronous, FBL). 30-day post-migration deliverability support. One-time EUR 1,499, delivery in 21 business days.
Fixed price EUR 1,499
Delivery 21 biz days
Cutover window 4-6 weeks
Post-support 30 days
Four common source configurations with different operational profiles.
Your migration scope depends on what you are migrating from. Click a source to see the specific extraction, suppression migration, and cutover considerations for that source type.
Three target MTAs with different operational profiles.
Target MTA selection depends on volume, operational pattern, and licensing preference. The matrix below covers the three most common targets we deploy. The engagement scopes this decision during initial conversation.
| Attribute | PowerMTA | Postfix | Exim |
|---|---|---|---|
| License | Commercial (EUR 1,499 lifetime or EUR 99/month rent) | Open source (free) | Open source (free) |
| Volume sweet spot | 1M+ emails/month sustained | 100K-1M emails/month | Varies by configuration complexity |
| Per-ISP throttling | Native, granular, GUI-managed | Configurable via maps and policies | Configurable via ACL and routers |
| Multi-tenant IP pools | Native (virtual-MTA) | Requires custom configuration | Configurable via routers |
| Bounce processing | Built-in (sync, async, FBL) | External tooling typically | Configurable via filters |
| Logging detail | Rich CSV suitable for analytics platforms | Standard syslog + custom logging | Standard logs + main_log_selector flags |
| Configuration complexity | Moderate (config files plus GUI) | Moderate (main.cf key-value) | High (scriptable config language) |
| 2026 community recommendation | ESP and high-volume default | Self-hosting default per SmtpEdia 2026 | Complex routing scenarios only |
Specialised targets available on request: KumoMTA (Rust-based, modern architecture, growing 2026 adoption), GreenArrow (commercial ESP-focused), MailerQ (queue-centric architecture), Halon (programmable MTA for ESP and security-focused operations), Postal (platform-first open source). These targets scope through consulting engagement rather than this standard migration engagement.
The cliff that flip-and-pray migrations produce.
Cloud SMTP providers are convenient. SendGrid, Mailgun, Amazon SES, Postmark each offer simple integration: sign up, verify a domain, send via SMTP or API. The provider handles IP allocation, authentication, deliverability monitoring, and mailbox provider relationships. The operator just sends. For most operations at the time they first adopt cloud SMTP, the trade-off is favourable: pay a per-email rate, skip the operational overhead of running infrastructure, focus on the application rather than the SMTP layer.
The trade-off shifts as operations grow. At 1 million emails per month, the per-email pricing starts producing meaningful monthly invoices. At 5 million, the invoices fund a small DBA. At 20 million, the cloud SMTP costs comparable to a dedicated team plus infrastructure for self-hosting. The Postmastery Jobtome case study documented consolidating 30 Postfix instances onto one PowerMTA with substantial cost savings at their scale. The SmtpEdia February 2026 MTA guide documents the crossover criteria explicitly: early-stage SaaS should use cloud SMTP, scaling products and ESPs should adopt dedicated MTAs for cost control and advanced routing.
The other driver for self-hosting is reputation control. Cloud SMTP shared pools mean your deliverability depends on the worst sender in the pool you happen to share. Dedicated IP options on cloud SMTP narrow this risk but do not eliminate it; the provider IP range reputation still affects you when ISPs apply range-level filtering. Self-hosted infrastructure gives you direct control over IP allocation, warmup pacing, reputation maintenance, and incident response. For operations where deliverability is revenue-critical, the control margin matters even when the cost economics are close to neutral.
The reason most operations delay or avoid the migration despite favourable economics is fear of the deliverability cliff. The naive migration pattern (set up new MTA, point DNS at it, send mail) typically produces a 4-8 week dip in delivery rates while the new IPs build reputation from zero. During the dip, bounce rates spike, ISP filtering tightens, blocklist appearances become more likely. Operations have observed and remember these dips when other companies migrated; the fear of reputation damage outweighs the cost economics. The fear is justified for naive migrations but the dual-MTA pattern eliminates the cliff entirely.
The dual-MTA cutover treats migration as a warm-up problem rather than a switch problem. Both old and new infrastructure run in parallel for 4-6 weeks. Traffic shifts gradually: week 1 at 5/95 ratio, week 2 at 15/85, ramping until week 6 at 100/0. The new IPs accumulate reputation at the pace mailbox providers expect from organic warmup patterns. The old infrastructure carries the bulk of traffic during the transition, preserving the inbox placement rates the operation already built. The pattern is documented in M3AAWG sender practices and reflected in every Postmastery migration case study from the past five years. Operations that use the dual-MTA pattern typically see no measurable deliverability dip during the migration; the new infrastructure reaches its steady-state performance by the end of week 6.
The suppression list is the second consequential element. Cloud SMTP providers accumulate suppression events (unsubscribes, hard bounces, complaints) in their internal systems. The migration must extract these events completely and deduplicate them against the new MTA suppression mechanism before any production traffic flows. The engagement handles this with canonical append-only log format that supports any future migration without information loss. The 30-day post-migration support window covers the operational settling period where new infrastructure is still adjusting to real traffic patterns and may need pacing adjustments per mailbox provider.
Eight artefacts delivered across 21 business days plus 30-day support.
Target architecture design
MTA selection (PowerMTA, Postfix, or Exim) matched to operational profile. IP pool sizing. Per-ISP throttling configuration. Hostname structure. Storage and logging architecture.
Dual-MTA cutover plan
Week-by-week traffic shift schedule with explicit ratios per week. ISP-specific pacing rules. Rollback procedure documented. Customer signoff at each weekly checkpoint before progression.
Suppression list migration
Complete export from source provider in native format. Deduplication and normalisation into canonical append-only log. Import to new MTA suppression mechanism with verification before production traffic.
DNS authentication update
SPF, DKIM, DMARC updates coordinated with TTL pre-staging. Dual-MTA SPF during transition. New DKIM selector deployment. DMARC policy adjustment if needed for transition window.
Bounce processing pipeline
Synchronous bounce handling, asynchronous bounce processing, FBL integration with Google, Microsoft, Yahoo. Suppression feeds back into the canonical log automatically.
Per-ISP throttling configuration
PowerMTA virtual-MTA configuration, Postfix transport_maps, or Exim routers configured to match historical sending pace per major ISP. Initial throttling conservative during cutover, relaxed as reputation establishes.
30-day post-migration support
Daily monitoring of delivery rates per ISP. Weekly summary report. Alert response within 4 hours during operating hours. Pacing adjustments if any mailbox provider shows degradation. Weekly deliverability call for first two weeks then bi-weekly.
Operational profiles where the migration pays for itself.
Cost crossover from cloud SMTP
Operations sending 1M+ emails per month where cloud SMTP costs have grown to the point that self-hosted infrastructure pays for itself within 6-12 months. Common pattern after rapid subscriber growth.
Shared pool reputation problems
Operations on shared cloud SMTP pools experiencing deliverability degradation traced to other tenants in the pool. Migration to dedicated infrastructure isolates reputation risk.
Provider service quality issues
Operations leaving a cloud SMTP provider that has experienced outages, billing disputes, or service quality problems. The structured migration handles the transition without relying on the departing provider for cooperation beyond data export.
Per-ISP throttling requirements
Operations needing granular per-ISP throttling that cloud SMTP cannot satisfy. PowerMTA particularly supports throttling at the granularity ESPs and high-volume senders typically need.
Compliance jurisdiction requirements
Operations needing data residency in specific jurisdictions (EU for GDPR, non-US for non-FISA posture) that cloud SMTP providers cannot guarantee. Self-hosted on ASH infrastructure provides explicit jurisdiction control.
Multi-tenant operations
Agencies, ESPs, and resellers serving multiple downstream customers where multi-tenant IP pool management on PowerMTA enables proper customer isolation that shared cloud SMTP cannot provide.
Frequently asked.
What does MTA Migration deliver?
A one-time engagement migrating your email sending infrastructure from a cloud SMTP provider (SendGrid, Mailgun, Amazon SES, Postmark, SparkPost) or a legacy on-premise MTA to self-hosted PowerMTA, Postfix, or Exim on ASH infrastructure. The deliverables: source-state audit covering current sending volumes, IP pools, domain configuration, suppression list, and reputation baseline; target-state architecture matching your operation\'s sending profile; dual-MTA cutover plan with traffic shifting in phases over 4-6 weeks to preserve reputation; suppression list migration with hard-bounce, complaint, and unsubscribe events preserved in append-only log format; DNS authentication update coordinated with TTL pre-staging; per-ISP throttling configuration on the new MTA matching your historical sending patterns; bounce processing pipeline; 30-day post-migration deliverability support with daily monitoring and weekly summary. One-time engagement EUR 1,499, delivery in 21 business days.
Why migrate from cloud SMTP to self-hosted?
Three operational drivers typically motivate the migration. First: cost economics at volume. Cloud SMTP per-email pricing (SendGrid, Mailgun, SES) becomes uncompetitive at high volume; the crossover point typically appears at 1-5 million emails per month depending on which cloud SMTP is current. Second: IP reputation control. Cloud SMTP shared pools mean your deliverability depends on the worst sender in the pool you happen to share. Self-hosted infrastructure gives you direct control over IP allocation, warmup pacing, and reputation maintenance. Third: feature requirements that cloud SMTP cannot satisfy. Per-ISP throttling at the granularity PowerMTA supports, custom bounce processing, integration with custom suppression logic, multi-tenant IP pool management for agency or ESP operations, jurisdiction-specific data residency for compliance.
How does the dual-MTA cutover work and why does it matter?
The structural problem with switching MTAs is reputation continuity. Switching cold to a new MTA with new IPs resets all reputation to zero. A naive cutover that flips all traffic on day one typically produces a 4-8 week deliverability dip while the new infrastructure builds reputation from scratch. The dual-MTA cutover pattern avoids this by running both old and new infrastructure simultaneously and shifting traffic gradually over 4-6 weeks. Week 1: 5% of traffic to new infrastructure, 95% to old. Week 2: 15% to new, 85% to old. Continue ramping until week 6 where new is 100% and old can be decommissioned. The new IPs accumulate reputation at a pace mailbox providers expect for legitimate warm-up; the old infrastructure carries primary load while the new builds trust.
What about suppression list preservation?
Suppression lists are the most consequential single element to get right. If the migration loses any suppression event, you re-send to a recipient who already opted out, violating GDPR Article 7 right of withdrawal or US CAN-SPAM section 5 immediate opt-out requirements. The engagement handles suppression with three mechanisms. First: complete export from the source provider in their native format. Second: deduplication and normalization into a canonical append-only log format with event type (unsubscribe, hard_bounce, complaint), timestamp, source, and recipient address. Third: import into the new MTA\'s suppression mechanism with verification that suppression events apply correctly before any production traffic flows. The append-only log format becomes the source of truth going forward and supports any future migration without information loss.
Which target MTA should I choose: PowerMTA, Postfix, or Exim?
Three patterns based on operational requirements. Choose PowerMTA when: high-volume sender (1M+ emails per month sustained), need granular per-ISP throttling, need rich logging suitable for delivery analytics platforms, operating as ESP or agency with multi-tenant IP pools, willing to pay commercial license. Choose Postfix when: general mail hosting plus marketing sending, mid-volume (100K-1M emails per month), preference for secure simple configuration with reasonable complexity, open-source preference. The SmtpEdia 2026 guide and prospeo.io email MTA guide both recommend Postfix as the default for self-hosting in 2026. Choose Exim when: need complex routing logic implementable in MTA config rather than external scripts, custom filtering or policy decisions integrated with delivery, comfortable with Exim\'s scriptable config language despite steeper learning curve.
What happens to my IP reputation during migration?
Two scenarios. Scenario one: BYOIP migration where you bring your existing IP allocations to ASH. Reputation transfers directly with the IPs because mailbox providers track reputation per IP regardless of which MTA software sends from it. The migration becomes primarily a software cutover rather than a reputation rebuild. PTR records must update to reflect the new MTA\'s HELO hostname; we handle this as part of the engagement. Scenario two: new IPs allocated by ASH. New IPs start with no reputation and require warmup. The dual-MTA cutover pattern handles this by ramping new IP traffic gradually over 4-6 weeks so mailbox providers see organic-looking warmup rather than sudden traffic spikes. The 30-day post-migration support window covers the period when new IPs are still building reputation.
What about authentication setup on the new MTA?
Authentication transfers cleanly because SPF, DKIM, and DMARC live in DNS rather than in the MTA software. The engagement handles the DNS updates as part of the cutover sequence. SPF updates to add the new MTA\'s sending IPs (during dual-MTA window, both old and new IPs are in the SPF record; after cutover, old IPs are removed). DKIM keys typically rotate during migration: existing DKIM key stays valid for messages already in transit; new DKIM key gets published with a new selector for messages from the new MTA; both keys coexist during the cutover window then the old selector retires. DMARC policy may need to step down from p=reject to p=quarantine during the migration window if mixed authentication signals would cause legitimate mail to bounce.
What is the 30-day post-migration support window?
The migration completion does not end at cutover; reputation continuity requires sustained attention through the post-migration window. The 30-day support covers: daily monitoring of delivery rates per ISP; weekly summary report covering bounce trends, complaint rates, blocklist status, and any anomalies; alert response for any deliverability degradation with investigation within 4 hours during operating hours; pacing adjustments if any mailbox provider shows degradation; coordination with Postmaster Tools (Google) and SNDS (Microsoft); weekly deliverability call for the first two weeks then bi-weekly thereafter. Operations needing longer-term ongoing deliverability operations subscribe to Deliverability Monitoring (EUR 49/month).
Related services.
Migration scope and what each engagement actually covers
MTA migration engagements vary substantially in scope depending on the source platform, target platform, and customer requirements. The scope below captures what we have delivered across the migrations we have completed.
Standard scope: assessment of existing infrastructure documenting current configuration and operational patterns, design of target architecture with specific configuration decisions, parallel deployment of new infrastructure alongside existing, gradual traffic transition with reputation warming on new infrastructure, validation testing through controlled sending, full cutover once validation confirms readiness, decommissioning of old infrastructure once retention requirements expire.
Extended scope additions: ESP control plane migration when source and target use different ESP software, custom integration work when standard integration patterns do not cover specific customer requirements, compliance documentation when migration occurs during active audit observation windows, multi-region migration when target architecture differs geographically from source.
What we do not cover in standard scope: business process changes that the migration might enable (these belong with operational consulting rather than infrastructure migration), customer-facing communication coordination (customer team handles this with our technical input as needed), broader strategic decisions about sending architecture (these belong with strategic consulting engagements rather than migration projects).
For operators uncertain about scope fit, the discovery conversation typically identifies whether standard scope fits or whether extended scope or strategic consulting would be more appropriate. The structural pattern is matching engagement type to actual operational need rather than fitting customer needs into pre-existing engagement templates.
Migration patterns by source and target combinations
Specific migration patterns we have completed across different source and target combinations, with the operational characteristics of each.
SendGrid or Mailgun to self-hosted PowerMTA: typical timeline 6-8 weeks. The source platforms expose limited operational data, which produces extended discovery phase to reconstruct sending patterns. Reputation warming on new infrastructure requires careful pacing to match historical volume; aggressive transition produces predictable problems.
Postfix to PowerMTA: typical timeline 4-6 weeks. Both platforms expose similar operational data, which produces shorter discovery. The configuration patterns translate cleanly; most operational work involves PowerMTA-specific tuning rather than reconstruction of source platform behavior.
Self-hosted ESP to managed ESP: typical timeline 8-12 weeks. The longer timeline reflects coordination across two infrastructure stacks (sending platform plus underlying ESP control plane). Customer-side coordination tends to be higher because changes affect customer-facing workflows.
ESP platform A to ESP platform B (both self-hosted): typical timeline 6-10 weeks. The complexity comes from data translation between platforms that store configuration differently. Customer database migration requires careful validation; ESP differences in segment handling, automation logic, and reporting structures need explicit mapping.
Cross-jurisdiction migration: timeline depends on whether infrastructure changes happen simultaneously with jurisdiction changes. Sequential migrations (infrastructure first, then jurisdiction, or vice versa) typically run 12-16 weeks total. Simultaneous migrations are operationally complex and we recommend against them except when specific customer requirements force the combination.
Pricing structure and engagement timeline
MTA migration pricing reflects scope and complexity rather than time-and-materials billing that produces unpredictable customer costs. The standard engagement is fixed-price based on the assessment during discovery.
Discovery and assessment: free initial conversation through Telegram or ticket, paid discovery (EUR 500-1,500) when scope and timeline definition requires substantial diagnostic work. Discovery output is a written proposal with specific deliverables, timeline, and pricing for the migration itself.
Standard migration pricing: EUR 2,500-4,500 for typical migrations within the standard scope. Pricing varies based on specific source and target combinations, customer volume, and configuration complexity identified during discovery. The pricing is fixed for the agreed scope; scope changes during migration produce explicit change orders rather than scope-creep absorption.
Extended scope additions: priced incrementally based on the specific additions. Common additions include EUR 800-1,500 for ESP control plane migration, EUR 500-1,200 for custom integration work, EUR 800-2,000 for compliance documentation requirements. The pricing structure produces predictable customer cost without unbounded engagement expansion.
Most migrations complete on or near the timeline estimated during discovery. Migrations that extend beyond initial estimate typically do so due to customer-side delays (DNS coordination, vendor coordination, internal approval processes) rather than provider-side issues. We document timeline variance with customers as it develops to maintain visibility.
Order MTA Migration.
Telegram conversation establishes source provider, current sending volume, IP allocation (BYOIP or new), target MTA preference, suppression list size, compliance jurisdiction requirements, and acceptable cutover window. Engagement begins within 5 business days of confirmation. Cutover phase runs 4-6 weeks after initial setup. 30-day post-migration support follows. One-time EUR 1,499 fixed.
# Median Telegram response: 12 minutes during operating hours