SMTP Relay
When a billing run, a shipment alert or a security notification has to arrive, the way the message is submitted should not limit the infrastructure behind it. Omnivery's SMTP relay brings mission-critical email infrastructure to anything that can speak SMTP, from a modern SaaS application to a decades-old billing platform - on Omnivery's own hardware, under EU law, with seven ISO certifications and HIPAA behind it.
Updated: August 2026 · Reading time: 6 min
An SMTP relay is an intermediary service that accepts outbound email from your application and takes delivery from there: authentication, reputation, bounce handling and compliance. The alternative is running your own mail server, which means owning the infrastructure, the IP warming, the DNS records and the deliverability expertise that come with it.
It is also the oldest and most universally supported way to send. Every framework, every language and every operating system speaks SMTP natively, which is why it remains the connectivity method of choice for systems as far apart as a new microservice and a mainframe application that has run without interruption for 30 years.
Your application opens a connection to the relay's SMTP server - port 587 with STARTTLS, or port 465 with TLS - authenticates, and hands over the message. Everything after that is the relay's job: DKIM signing, SPF alignment, DMARC enforcement, IP reputation, retries, bounce processing and delivery. The sending application never needs to know anything about the destination mail server.
Engineering teams pick SMTP because there is no SDK to add and no code migration if the provider changes later - switching means editing one configuration value. That isn't about volume or message variety: it matters when an API client is unavailable for the runtime, too costly to integrate, or the team wants queuing and retries controlled at the mail layer, not an SDK.
Utilities, banks, healthcare organizations and public-sector bodies often depend on billing platforms, ERP systems and reporting engines that have been running reliably for years. Rebuilding them to meet a new compliance or email requirement may be impractical. Changing an SMTP configuration usually isn't.
At most providers the SMTP endpoint is a delivery pipe. It takes the message, but the templating, the event stream and the security features live behind the REST API, and an older system routed through SMTP gets the reduced version of the product. On Omnivery the two are the same service with two front doors, and everything in the list below is reachable from both.
Which one to use comes down to what the sending system already does. A REST API gives finer programmatic control over templates, events and dynamic content, which suits an application being written now. SMTP suits everything else, and for an ERP or a legacy platform it is the only option that does not require touching the application at all.
Available identically from the SMTP relay and the REST API:
A billing platform that has processed millions of transactions reliably for 20 years is not going to be rebuilt in a three-month sprint because GDPR came into force or because Google revised its bulk sender guidelines. The obligations arrive anyway. GDPR applies to every message containing personal data, and ISO and HIPAA scope covers the whole data-handling chain, outbound email included. The obligation is fixed. The open question is how to meet it without disturbing infrastructure that works.
The integration is one change - the SMTP server address and the credentials. Nothing above that line is touched. What changes is everything downstream of it:
The legacy system carries on exactly as it always has. The compliance posture changes the same afternoon.
Every customer signs a contract, every sending domain is reviewed by a person, and there is no free plan, so there is no anonymous sender in the pool to drag a reputation down. For most senders that beats a dedicated IP, which carries only your own history, starts cold, and needs sustained volume to stay warm - a condition a legacy system sending at irregular volumes rarely meets. Dedicated IPs are available where the volume genuinely warrants one.
Omnivery's parent company is headquartered in the Czech Republic and its operations are governed by EU law. For any organization processing EU personal data that means no Schrems II complications, no Standard Contractual Clauses needed for the controller-processor relationship, and no US CLOUD Act jurisdiction over your email data. No US-headquartered relay provider can replicate it.
Most platforms optimize for Gmail, Outlook, Yahoo and Apple. Omnivery sends according to each receiving side's requirements rather than one global profile, which matters most when a legacy system's recipients sit in markets the big four do not cover. See the deliverability page.
Deliverability monitoring here is people, not a notification rule. Senior analysts read the sending data and call customers directly when they see something starting - while the industry moves the other way, toward automation and thinner expert headcount. Every customer has a real expert to reach, included and not invoiced.
| Feature | Self-hosted mail server | SendGrid SMTP | Mailgun SMTP | Omnivery SMTP Relay |
|---|---|---|---|---|
| Infrastructure | Your own | AWS shared | AWS shared | 100% own - no AWS/Azure/GCP |
| Feature parity with API | N/A | Reduced | Reduced | ✓ Full parity |
| Templating via SMTP | Manual | Limited | Limited | ✓ Full |
| Webhooks via SMTP | Manual | ✓ | ✓ | ✓ Full |
| ISO 27001 | Depends | ✓ | ✗ | ✓ |
| ISO 27701 | Depends | ✗ | ✗ | ✓ |
| HIPAA | Depends | ✗ | ✗ | ✓ |
| GDPR - content storage | Depends | Stored | Stored | Never stored |
| EU parent company | N/A | ✗ (Twilio, US) | ✗ (Sinch, mixed) | ✓ (Czech Republic) |
| Deliverability monitoring | Manual | Automated alerts | Automated alerts | Senior analysts - proactive |
| Compliance updates | Manual | Reactive | Reactive | Proactive - ahead of changes |
| Vetting / bad actor protection | N/A | Weak | Weak | Strict - every customer reviewed |
| Bot filtering on tracked engagement | No tracking | Basic proxy-open filtering | Basic proxy-open filtering | ✓ Full Bot Detection, included with Omnivery tracking |
| Email journaling | Manual | Add-on | ✗ | ✓ Native |
| Phishing protection | Manual | Basic | Basic | ✓ Real-time |
All platforms in this table offer open and click tracking. Basic proxy-open filtering means identification of Apple Mail Privacy Protection and image-cache proxy opens, which is the extent these platforms document; none publishes bot classification for clicks. Omnivery applies the same Bot Detection sold as a standalone API to tracked engagement for every customer using Omnivery tracking, at no additional charge.
Setting up Omnivery SMTP relay takes minutes for modern systems. For legacy systems, the configuration is typically a single settings file change.
Your account is reviewed and approved by Omnivery's team before activation. This vetting is what protects every sender on the platform.
Omnivery configures SPF, DKIM and DMARC on the domain, and keeps those records current as receiver requirements change.
Point your application or legacy system to Omnivery's SMTP endpoint with your credentials. For legacy systems, this is typically the only change required.
Omnivery handles authentication, reputation management, deliverability monitoring, compliance data handling, and bounce processing from this point forward.
Billing platforms, outage notifications, and customer communications that cannot be migrated to REST APIs on short timelines but must comply with GDPR and evolving provider requirements. E.ON and Centropol Energy send through Omnivery.
Transaction notifications, statement delivery, and compliance reporting from legacy core banking and ERP systems.
Patient communications, appointment confirmations, and administrative email from systems that must maintain HIPAA compliance. Omnivery is HIPAA certified and signs Business Associate Agreements.
Government and institutional email-generating systems where procurement requires ISO certification and audit trails.
Who prefer SMTP for its simplicity, universality, and provider portability, and want enterprise-grade compliance and deliverability behind it.
Organizations with a mix of modern API-integrated applications and legacy SMTP-only systems who want a single certified relay provider for all outbound email.
White-glove deliverability
Moving off your own MTA means giving up the queue you used to be able to inspect. What you get back is people who watch it for you. Everywhere else that expertise is a separate invoice - a consulting tier, a premium add-on, a business unit that bills you when sending goes wrong. We do not have a deliverability business unit, because deliverability is the business.
Omnivery's SMTP relay has full feature parity with the REST API. It is a first-class integration path, not a reduced-capability option, which is what distinguishes it from most providers' SMTP endpoints.
It works with any system that can speak SMTP, regardless of age, language or architecture. The integration is the server address and the credentials.
SMTP credentials and API access tokens can each be restricted to an allowlist of IP addresses or ranges, per credential, so a credential that leaks cannot be used from anywhere else.
Omnivery holds seven ISO certifications plus HIPAA, all independently audited. Those certifications extend to email routed through the relay. The HIPAA certificate is published for download, and the ISO certificates are on the certifications page.
Message content is never stored. Delivery metadata is retained for a maximum of 30 days.
Omnivery's parent company is headquartered in the EU (Czech Republic) and EU law governs its operations, so there is no US CLOUD Act jurisdiction risk and no Schrems II complication.
Omnivery operates entirely on its own physical infrastructure. No third-party cloud provider sits in the delivery path.
There is no free plan. Every customer is vetted before contract and every sending domain is reviewed by staff, which is the mechanism behind the shared sending reputation.
E.ON and Centropol Energy use Omnivery's SMTP relay to bring legacy billing and notification systems into compliance without modifying those systems.
It depends on your compliance requirements and your infrastructure profile. For enterprises that need ISO/IEC 27001, ISO/IEC 27701 or HIPAA certification, and particularly for EU organizations where GDPR and data sovereignty are requirements rather than preferences, Omnivery holds all three, operates entirely on its own physical infrastructure, and is headquartered in the EU under EU law. No other provider in the comparison combines those.
Where the estate also includes legacy or ERP systems, the relay having the same capabilities as the API makes Omnivery a single provider for the whole outbound stack rather than two contracts. Bot detection on tracked engagement matters here too, because non-human interaction is what corrupts the open and click data those systems report on.
If unit price is the deciding factor, a cheaper provider exists.
In most cases, yes. ERP platforms - SAP, Oracle, Microsoft Dynamics - and most legacy enterprise systems have native SMTP settings in their mail-sending module, so connecting to an external relay means updating the host, port and credentials there. No API integration, no SDK, no development work, and no change request against the application itself.
From the relay onward Omnivery handles authentication, compliance data handling, deliverability monitoring and bounce management. For an organization in the middle of a compliance audit, this is usually the fastest route to bringing ERP-generated email inside certified handling.
They are two integration methods for the same service. SMTP is the standard protocol every application and system already supports natively; a REST API is a modern interface offering finer programmatic control over templates, events and dynamic content.
At Omnivery the platform behind both is identical, including the features most providers reserve for the API: templating, webhooks, phishing protection, email journaling, bot detection and deliverability monitoring. The choice is about how the sending system connects, not about what it can do.
Yes. Omnivery's GDPR-native architecture applies to all email routed through the relay - message content is never stored, metadata is retained for a maximum of 30 days, and strict privacy mode is available to fully anonymize metadata. Omnivery's parent company is EU-headquartered, meaning EU law governs the entire data processing relationship. The Data Processing Agreement (DPA) is available at omnivery.com/legal/dpa.
Omnivery is HIPAA certified. The certificate is publicly available for download. Omnivery signs Business Associate Agreements (BAAs) for organizations sending email containing Protected Health Information. Request one from sales@omnivery.com.
Seven, plus HIPAA: ISO 9001 (quality management), ISO/IEC 20000-1 (IT service management), ISO 22301 (business continuity), ISO/IEC 27001 (information security management), ISO/IEC 27017 (cloud security), ISO/IEC 27018 (protection of personal data in the cloud) and ISO/IEC 27701 (privacy information management). All are independently audited, and every certificate is published for download.
In an SMTP relay evaluation the two that usually decide the review are ISO/IEC 27001 and ISO/IEC 27701. SendGrid holds ISO 27001 but not ISO 27701; Mailgun holds neither.
Dedicated IPs are a common industry upsell, but they only deliver their theoretical benefit when maintained with consistent, high-volume sending. Many senders - including those with legacy systems sending at irregular volumes - cannot keep one properly warmed, and a cold dedicated IP performs worse than a well-managed shared pool.
Omnivery offers dedicated IPs where the volume genuinely warrants one. The default recommendation is the vetted sending neighborhood, which outperforms them for most customers and requires no warming management.
For modern system integrations, Omnivery accounts are typically active within one working day after approval. For a legacy system where the work is an SMTP configuration change, sending can begin immediately after account activation and domain validation.
For low-volume internal mail, yes, and it is the sensible choice - do not add a vendor for a scanner. The limits bind sooner than most people expect for customer-facing traffic. Microsoft caps client SMTP submission at 10,000 recipients per day and 30 messages per minute, has scheduled Basic authentication for that method for deprecation, and its higher-volume connector method cannot be used from cloud hosting. Google's SMTP relay service allows 10,000 recipients per user per 24 hours with a hard 100-recipient limit per SMTP transaction. Neither provides per-recipient bounce classification, webhooks, per-message TLS enforcement, or engagement data with automated scanner activity separated out. Both guides set out the details: Office 365 SMTP relay and Google Workspace SMTP relay.
Free SMTP relay services exist, but they are not appropriate for enterprise or compliance-sensitive use. Free tiers rely on anonymous sign-up, which attracts abuse and degrades IP reputation for everyone on the same pool. They also carry no compliance certifications, no data processing agreement and no contractual obligations around data handling, which is direct GDPR and HIPAA exposure for any organization with personal data in its email.
Omnivery deliberately has no free plan. Every customer is vetted and signs a contract, and that vetting is what produces the clean sending neighborhood.
Nothing, for Omnivery customers. Omnivery enforces stricter standards than mailbox providers currently require, so when the requirements move, customers are already on the far side of them. When the Gmail and Yahoo bulk sender guidelines came into effect, Omnivery customers needed no changes. Where a sending system cannot be updated quickly, that lead time is the difference between a non-event and an incident.
Ready for communications infrastructure you can rely on when it matters most?