On-premise MTA replacement
A twenty-year-old billing platform is not going to be rebuilt because Google changed its bulk sender rules. But the Postfix box in front of it still needs patching, its IP reputation still needs defending, and its DKIM keys still need rotating - and none of that is anyone's actual job. Point the system at a certified relay instead. One configuration change, no code, and the compliance obligations move onto infrastructure that is audited for them.
Updated: July 2026
The server itself is cheap. The cost is in five obligations that arrive whether or not anyone has been assigned to them.
SPF, DKIM and DMARC used to be optional hygiene. Since Google and Yahoo tightened bulk sender requirements they are entry conditions, and the requirements keep moving - alignment rules, DMARC policy expectations, and one-click unsubscribe under RFC8058 for bulk mail.
On a self-hosted MTA every one of those is a change someone has to make, test and document. On Omnivery the sending records are published once from the domain screen, and DKIM keys rotate through CNAMEs rather than needing a key swap each time.
The target keeps moving after that, too. DKIM2 is being developed as the successor to today's DKIM, signing the recipients as well as the headers and body so that replay attacks become impossible. It reuses the keys you already publish, so there are no DNS changes to make, but the signing behavior itself changes and receivers are expected to push for adoption quickly. On a self-hosted MTA that is another authentication project for a team that has one already. Omnivery is preparing support now, so it lands as a platform update instead.
A self-hosted MTA sends from your own IP range, which means your reputation is entirely your own problem: blocklist monitoring, feedback loop enrollment, warmup after any change, and escalation to a receiver who has no relationship with you.
A well-run shared pool usually outperforms a dedicated IP for this exact reason. Omnivery's position is that dedicated IPs are an industry upsell that underperforms for senders who cannot maintain warm volume, and that a vetted shared neighborhood does better. The vetting is what makes that true, which is why there is no free tier.
GDPR applies to every message containing personal data, including while it sits in a mail queue on a server in your own rack. If you hold ISO 27001, the outbound mail path is in scope. If you handle PHI, so is the MTA.
Routing through Omnivery moves that segment onto infrastructure that is independently audited for it: seven ISO certifications plus HIPAA, published as downloadable certificates rather than supplied on request. Message content is never stored and delivery metadata is capped at 30 days.
A local MTA gives you mail logs. It does not tell you whether the message reached the inbox, whether it was filtered, or whether the click in your reporting came from a person.
Omnivery provides delivery and engagement events over webhooks, 30 days of event logs with bounce classification, and Bot Detection for separating human interaction from scanner and botnet activity. Senior deliverability analysts are included rather than invoiced as a tier, and they make contact when sending patterns look wrong.
One host, often one IP, frequently no documented failover, and a queue that silently grows when a receiver starts deferring. Disruption events are exactly when the notifications matter most.
Domain rate limits on Omnivery increase automatically by 20% at 75% utilization, and because Omnivery also speaks the SendGrid, Mailgun and SparkPost APIs, it can sit alongside another provider rather than replacing one single point of failure with a different one. See the developers page.
Notino, one of Europe's larger online beauty retailers, ran its own Postfix infrastructure. It worked, in the sense that mail left the building and the logs said so. What it could not do was tell anyone what happened next.
After moving to Omnivery, the reporting gap closed. The bigger change was visibility:
A self-hosted MTA tells you a message was accepted for delivery. It does not tell you whether it reached the inbox, which receiver deferred it and why, how bounces break down by category, or whether the clicks in your reporting came from people. Notino gained insight into its email it had never had before - not because Omnivery added a reporting feature, but because a relay sits in the position where that information exists and a local mail server does not.
Most teams move off a self-hosted MTA to escape maintenance: authentication upkeep, IP reputation, patching, the DKIM rotation nobody owns. Those savings are real, and they are usually what starts the conversation. What customers comment on afterwards is more often the visibility.
Notino also sends from several systems rather than one. Consolidating onto a single relay is what makes per-receiver placement measurable: split across separate sending paths, the national receiver quietly rejecting your dispatch notices appears in nobody's report.
One thing: the SMTP host, port and credentials. Everything upstream of that stays as it is.
Point the sending system at smtp.omnivery.net on port 587, authenticate as an SMTP user with AUTH LOGIN, and upgrade the connection with STARTTLS. The MAIL FROM address has to be on your sending domain and the From header has to align with it, which is a requirement your DMARC policy already imposes.
No application code changes. No new dependency. No library to evaluate. For most legacy platforms this is a configuration screen or a line in a properties file.
This is where SMTP relay usually disappoints: at most providers it is a delivery pipe, and the useful features live behind the REST API. On Omnivery the relay carries full parity, exposed through X-OV-* headers that a legacy system can set as ordinary mail headers:
X-OV-Template and X-OV-Template-Variables - use server-side templates from a system that cannot render themX-OV-Require-TLS - refuse to deliver unless the receiving server offers TLS, which is often the control an auditor is actually asking aboutX-OV-Track, X-OV-tracking_click, X-OV-tracking_open - per-message tracking controlX-OV-Callback-URL and X-OV-Callback-Format - delivery events without an API integrationX-OV-Recipient-Variables and X-OV-Variables - per-recipient substitutionX-OV-testmode - exercise the whole path before anything reaches a real recipientEmail journaling is a domain setting rather than a header, and sends exact copies of outgoing messages to an archive address - which is usually a cleaner answer to a retention requirement than BCC rules scattered across several legacy systems.
If the old server also received mail, routes handle that: filter inbound messages on mail_from, mail_to or subject with a regular expression, then either forward to a real mailbox or stop. The stop action is final; forward takes a destination address.
The comparison that matters is not features, it is which obligations you keep. The comparison is against a self-managed Postfix, Exim, Sendmail or Exchange relay rather than a competing provider.
| Obligation | Self-hosted MTA | Omnivery SMTP relay |
|---|---|---|
| Change needed in the sending system | None, until something breaks | SMTP host, port and credentials |
| SPF, DKIM, DMARC upkeep | Yours, and the requirements keep moving | Published once; DKIM rotates via CNAME |
| IP reputation and blocklist monitoring | Yours alone | Vetted shared pool, actively monitored |
| Feedback loop and complaint handling | Enrol and process per receiver | Handled, incl. RFC9477 CFBL reports |
| One-click unsubscribe (RFC8058) | Implement yourself | Automatic on bulk categories |
| Enforced TLS on delivery | Configurable, per-destination work | ✓ X-OV-Require-TLS per message |
| DANE validation on delivery | Off by default, needs DNSSEC-aware resolution | ✓ TLSA records validated where published |
| Delivery and engagement events | Mail logs only | Webhooks plus 30 days of event logs |
| Bounce classification | Parse SMTP responses yourself | Classified, with suppression handling |
| Message archiving for retention | BCC rules per system | Email journaling, one domain setting |
| Human deliverability escalation | No relationship with receivers | Senior analysts included, M3AAWG and CSA member |
| ISO and HIPAA scope over the mail path | Yours to certify and audit | Seven ISO certifications plus HIPAA, published |
| Capacity headroom | Fixed by the host | Rate limit auto-increases 20% at 75% use |
| Message content at rest | Queued on your disk | Never stored; metadata capped at 30 days |
Sources: Omnivery product documentation at omnivery.com/docs, July 2026. The self-hosted column describes obligations inherent to running your own MTA rather than any specific software. A well-staffed mail team can meet all of them.
The old server keeps running until you are satisfied. Nothing about this needs a cutover weekend.
Add your sending domain and choose its data location, EU or US. Those two settings cannot be changed later; everything else can. Vetting normally takes one to three working days. Ask the team to enable transactional mode if these are operational rather than marketing messages, since that changes suppression behavior.
Add SPF, DKIM and the tracking CNAME from the domain detail screen. If the old MTA signed with its own DKIM selector, both can coexist during the transition - a domain can carry more than one valid selector.
Create an SMTP user per sending system rather than one shared account, so you can see which platform sent what and revoke one without affecting the others. Passwords need at least 8 characters with a capital and a special character. SMTP credentials attract brute-force attempts, so treat them accordingly.
Pick the least critical sender first - internal reports, not password resets. Change host, port and credentials, and send with X-OV-testmode set so the path is exercised without delivering. Then send real mail from that one system and watch the event log.
Each system is an independent configuration change, so there is no all-or-nothing moment. Multi-platform environments usually end up with a mix: newer applications on the API, legacy ones on the relay, all on one certified provider with one set of suppressions and one reputation.
Email journaling sends exact copies to an archive address from a single domain setting. X-OV-Require-TLS refuses delivery to a receiver that will not offer TLS. Both are usually easier to justify to an auditor than the equivalent on a self-managed server.
Once nothing is pointing at it, retire it. Keep the DNS records until you are sure no forgotten cron job is still relaying through it - a stray sender that starts bouncing is a cheaper discovery than one that starts silently queueing.
E.ON and Centropol Energy both send through Omnivery. Energy retail is the clearest case for this pattern: high volume, billing systems that predate the compliance regime they now sit inside, and messages customers are legally entitled to receive.
Billing runs, meter reading requests, tariff change notices and outage communications, generated by systems that cannot be rewritten on a compliance timetable. E.ON and Centropol Energy send with Omnivery.
Statement delivery, transaction notifications and regulatory correspondence out of core banking or policy administration platforms, where the sending system is the last thing anyone wants to modify.
Where procurement requires ISO certification over the whole processing chain and an audit trail that does not stop at the application boundary.
Appointment and administrative mail out of systems that must stay HIPAA compliant. Omnivery is HIPAA certified and publishes the certificate. See HIPAA compliant email.
Order and dispatch notifications leaving through a self-hosted relay, with no way to see which receivers accepted them. Notino replaced Postfix with Omnivery and gained visibility it had never had.
Newer services on the REST API, older ones on the relay, one certified provider underneath both - so suppression state, reputation and reporting are shared rather than split per system. Superzoo runs exactly this pattern across several platforms.
The most common case. The MTA works until authentication requirements change or an IP lands on a blocklist, and then it becomes urgent for someone who has never owned it.
The SMTP host, port and credentials. Point the system at smtp.omnivery.net on port 587, authenticate with AUTH LOGIN as an SMTP user, and use STARTTLS. The MAIL FROM address has to be on your sending domain and the From header has to align with it, which DMARC already requires.
No application code changes and no new dependency. For most legacy platforms this is a configuration screen or one line in a properties file.
No. This is the usual disappointment with SMTP relay elsewhere, where the useful features sit behind the REST API and the relay is just a pipe. On Omnivery the relay has full parity, exposed through X-OV-* headers a legacy system can set as ordinary mail headers: X-OV-Template and X-OV-Template-Variables for server-side templates, X-OV-Require-TLS to enforce TLS on delivery, X-OV-Track and the per-channel tracking headers, X-OV-Callback-URL for delivery events without an API integration, X-OV-Recipient-Variables for substitution, and X-OV-testmode to exercise the path without delivering.
Email journaling and inbound routes are domain settings rather than headers, so they apply to relayed mail too.
Yes, and it is the right way to do it. Each sending system is an independent configuration change, so there is no cutover moment and the old MTA can keep running until you are satisfied. Start with the least critical sender - internal reports rather than password resets - and use X-OV-testmode to prove the path first.
Create a separate SMTP user per system rather than sharing one account, so you can see which platform sent what and revoke one without affecting the others.
It is the first thing most teams try, and for internal or low-volume mail it works. Where it breaks down is customer-facing volume. Microsoft caps client SMTP submission at 10,000 recipients per day and 30 messages per minute, and its unthrottled methods (Direct Send, High Volume Email) deliver only to recipients inside your own tenant. Google's relay service allows 10,000 recipients per user per 24 hours with a hard limit of 100 recipients per SMTP transaction. Neither is a substitute for the MTA you are replacing, because neither returns per-recipient bounce classification or a webhook stream, and both put application sending on the same reputation as your staff's mailboxes.
The two guides go through the options in detail: Office 365 SMTP relay and Google Workspace SMTP relay.
Both can coexist during the transition, because a domain can publish more than one valid DKIM selector. Omnivery publishes its sending records from the domain detail screen and rotates DKIM keys through CNAMEs, so key rotation stops being a recurring manual task once you are across.
Usually the opposite. A dedicated IP only outperforms a shared pool if you can keep it warm with consistent volume; below that threshold you inherit all the reputation risk with none of the volume that establishes trust. Omnivery's position is that dedicated IPs are an industry upsell that underperforms for most senders, and that a vetted shared neighborhood does better.
That depends entirely on the vetting. Every customer and every domain is checked before sending, and there is no free tier, which is what keeps the shared reputation worth having. The same argument would not hold on a platform that accepts anonymous signups.
All Omnivery operations are performed by the Czech entity, including the US data centers offered for US residency. The Austin office is a sales function that operates no infrastructure and holds no customer data. Data residency is a customer choice between EU and US on infrastructure Omnivery owns in both cases, so choosing US changes where the machines are without changing who the processor is.
Omnivery runs no third-party cloud in the delivery path, never stores message content, and caps delivery metadata at 30 days. There are no US sub-processors in the core email service; US-incorporated vendors apply only to optional, customer-selectable features. The published sub-processor list is at Sub-processors, and the CLOUD Act and Schrems II analysis is on the GDPR compliant email API page.
Omnivery can deploy a custom data location instance into a customer's own datacenter or on-premise environment. The commercial and operational arrangements differ from the hosted relay, so contact sales to discuss it.
The configuration change per system is minutes. Notino's switch off its own Postfix infrastructure took 45 minutes, and it was not being rushed. The lead time is vetting, normally one to three working days per domain, plus whatever your own change process requires. Because systems move independently there is no big-bang date to coordinate.
If the driver is a compliance deadline, start with vetting rather than with the technical work, since that is the part with a queue in front of it.
If the mail server is nobody's actual job until it breaks, that is the case for moving it. Start with domain vetting rather than the technical work - the configuration change takes minutes, the vetting queue is the part with a lead time.