E-commerce
A customer who has just paid expects the confirmation before they close the tab. A shipping notification that lands in spam becomes a support ticket, and an invoice that never arrives becomes a chargeback. Omnivery is the delivery infrastructure under both halves of retail email - the order confirmation and the campaign - for retailers selling internationally, built on the view that a destination is not less important because it is smaller: every receiver gets sent to on its own terms, not just the four that dominate the averages. Native Bloomreach Engage, Targito and Meiro integrations, an official Mautic plugin, compatible APIs for anything else, and EU or US data residency by choice.
Updated: July 2026
Four failure modes account for most of the email problems retailers bring to a new provider, and they show up on the campaign side as readily as on the order confirmation. None of them is about raw sending speed.
This is the most common and the most damaging, because it looks like correct behavior. A customer unsubscribes from a promotional campaign, and the platform then withholds their order confirmation and shipping notification too.
Omnivery separates the two. A message categorized as transactional bypasses unsubscribe and complaint suppressions, so a receipt still reaches someone who has opted out of marketing. Bounce and block suppressions still apply, because those represent addresses that genuinely cannot or must not receive mail. Transactional mode is enabled per domain by the Omnivery team rather than self-serve, precisely because it changes suppression behavior.
The separation is real rather than a label on a message. Your marketing stream sends from its own domain with its own suppression state, is signed with its own DKIM key, and runs through a different IP pool - so the unsubscribe there is fully respected and the reputation it builds is its own. The signing key matters most of the three: receivers weight a DKIM-signed domain more heavily than the IP behind it, so that is where your brand's standing actually accumulates. Both streams can run through Omnivery; what they do not share is a key, a domain or a pool.
Retail volume is not flat. A campaign, a sale or a stock drop produces a spike, and a limit that was invisible for eleven months becomes the incident.
Each Omnivery sending domain carries a rate limit that automatically increases by 20% when it reaches 75% utilization, so ordinary growth does not require a support ticket. For a known event, raise it with the team in advance rather than discovering the ceiling during the event.
Retail decisions get made on open and click rates, and both have become unreliable. Apple Mail Privacy Protection opens messages automatically, corporate security gateways follow links before a human sees them, and botnets click for payout.
Omnivery's Bot Detection API returns a simple is_bot decision for an interaction, built from more than 20 proprietary datasets, with a honeypot mechanism for confirming automated clicks. For a retailer, the value is that segmentation and reactivation stop being driven by engagement that no person produced.
A disputed order or a consumer-rights complaint eventually turns into a question about exactly what the customer was told and when. Reconstructing that from application logs is usually unsatisfying.
Omnivery can send exact copies of outgoing messages to an archive address through email journaling, enabled with a single domain setting rather than BCC rules scattered through application code. Omnivery itself does not store message body content, so journaling is how you keep a copy if you need one.
Retail email is rarely sent from the shop itself. It is orchestrated by a customer data platform or an automation tool that owns the segments, the triggers and the templates, and the delivery provider sits underneath. So the question that matters is not whether a provider has an API, but how cleanly it drops in beneath the platform you have already committed to.
What that platform sends is marketing email: lifecycle flows, promotional campaigns, abandoned-cart and reactivation series. Omnivery delivers it on the same owned infrastructure, with the same per-receiver sending and the same analysts as the order confirmations. It is the delivery layer rather than the campaign tool - no segment builder, no template manager, and nothing to migrate off the platform your team already chose. Your CDP decides who receives what; Omnivery gets it there to the standard each receiver expects.
A marketing message has to carry headers a transactional one does not, and those requirements have moved. Since the Google and Yahoo bulk sender rules, List-Unsubscribe with one-click support under RFC8058 is an entry condition rather than a nicety, and plenty of automation platforms still do not emit it correctly. On most providers that becomes your problem to discover. Omnivery applies the required marketing headers itself, including one-click unsubscribe, whether or not the platform above it supports them - so a campaign leaving an older tool still meets the current standard, and unsubscribes arriving through the header are honored in Omnivery's own suppression state.
A native integration, added in Bloomreach under Data & Assets as an email provider with a sending domain and API key. Omnivery also emits two dedicated Bloomreach webhook formats, so engagement events flow back without a translation layer. Teams moving off Bloomreach's default Mailgun integration should transfer suppressions first.
A native premium integration, built and maintained on the Targito side and available to all qualifying Targito customers. Segments, triggers and templates stay in Targito; Omnivery is the delivery layer underneath, with no connector for your team to build or maintain.
A native integration with the Meiro customer data platform, so segments and triggers built in Meiro can send through Omnivery directly rather than through a generic SMTP hop.
An official transport plugin, OmniveryMailerBundle, published under GPL-3.0 and tested against Mautic 5. It is configured through Mautic's Email DSN settings. Being a transport plugin, it covers sending: configure bounce, unsubscribe and webhook handling in Omnivery itself.
Anything else connects through the compatible APIs. Because Omnivery natively implements the SendGrid v3, Mailgun v3 and SparkPost v1 request formats, a CDP or automation tool that can already send through one of those can send through Omnivery by changing a base URL and an API key - no connector to build and no vendor certification to wait for. For low-code stacks there is an Automations API and an official Make.com app, and for a platform that only speaks SMTP there is the relay, which carries full API parity through X-OV-* headers.
The same property is what makes Omnivery viable as a second, redundant sending path: matching request formats and matching webhook formats mean a standby provider does not require a standby integration.
For a retailer selling internationally, the addresses that decide the quarter are frequently not at Gmail, Outlook, Yahoo or Apple. They are at a national provider with a few million users, a regional ISP, or a mailbox host nobody outside that country has heard of - and to a delivery platform tuned for the big four, those receivers are rounding errors.
Omnivery's position is that a destination is not less important because it is smaller. That matters concretely in retail because a blended placement figure hides the case that matters: if placement is 99% at Gmail and 70% at the provider your fastest-growing market actually uses, the headline looks healthy while order confirmations quietly fail in one country. Nobody notices, because the average absorbed it. Reviewing placement per receiver rather than in aggregate is what surfaces it.
The per-provider evidence, drawn from Omnivery's own research across 126 mailbox-provider families in six world regions, is on the deliverability page.
For retailers this has a practical consequence: data residency is a customer choice between the EU and the US on infrastructure Omnivery owns in both cases, and because all operations are performed by the Czech entity, selecting US residency changes where the machines are without changing who the processor is. For a retailer with customers on both sides of the Atlantic that is one processor and one contract rather than a regional patchwork.
If the general principle is that every destination counts, Europe is where it stops being a principle and starts costing money. It is the most fragmented mailbox market a retailer has to sell into.
In much of the world you can reach most of a list through a handful of providers. In Europe you cannot. National and regional providers hold meaningful share market by market - Seznam in the Czech Republic, GMX and web.de in Germany, Libero in Italy, and a long list beyond them - and their share is concentrated exactly where a cross-border retailer is trying to grow. A platform that treats them as tail traffic is treating your addressable market as tail traffic.
They also do not behave like the large providers. Filtering thresholds differ, throttling differs, and the reputation signals they weight differ. Omnivery's own measurement shows how far apart they sit: bot-click contamination runs around 30% at Outlook and over 20% at Gmail, while Yahoo and GMX hold at 2 to 4% and Libero stays under 1%. Same metric, entirely different meaning depending on where your customers read their mail. Treating Europe as one market produces one blended number that describes none of it.
Omnivery grew out of Mailkit, founded in the Czech Republic in 2006. Those years are why the provider relationships in these markets exist, and why escalation is possible at receivers that have no public contact route.
Omnivery is a certified member of the Certified Senders Alliance, the European sender accreditation scheme, having passed its certification process against the CSA legal and technical criteria. German and wider European receivers treat that listing as a sender-side trust signal. Omnivery is also a member of Signal Spam in France and of M3AAWG globally.
An EU retailer processes consumer personal data on every order, so the delivery layer is in scope. Omnivery is operated by a Czech entity, runs exclusively on its own physical infrastructure with no AWS, Azure or Google Cloud in the delivery path, never stores message body 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. See the GDPR compliant email API page.
Selling into Europe from outside it does not change that position, which is the useful part: a US or APAC retailer expanding into the EU gets an EU-governed processor without moving vendors.
Retail email rarely comes from one system. There is the shop platform, the ERP or warehouse system that raises dispatch notices, a CDP running lifecycle campaigns, and usually something older that only speaks SMTP. The default outcome is a different sending path per system, which means split reputation, suppression state that disagrees with itself, and no single answer to what was sent.
Superzoo sends through Omnivery from several distinct platforms, using both the API and the SMTP relay. The shape is newer systems on the REST API, anything that cannot be changed on the relay, and one certified provider underneath all of it - so suppressions, reputation, analytics and the compliance posture are shared rather than reimplemented per system. Notino also sends with Omnivery.
Consolidating also fixes the measurement problem. Per-receiver placement is only meaningful if all of your sending is visible in one place; split across four providers, the national receiver that is quietly rejecting your dispatch notices appears in nobody's report.
Marketing and transactional are usually split across two vendors, on the reasoning that they must never share a reputation - which is correct, and which does not require two providers. Omnivery separates them at every level that carries reputation, starting with the one that carries most of it: each stream is signed with its own DKIM key. The receiving side weights a DKIM-signed domain more heavily than the IP a message arrived on, which makes the signature, rather than the address, the thing holding your brand's standing at each receiver. A campaign that draws complaints does not spend the standing your order confirmations depend on.
Separate IP pools sit underneath that. The two streams also send from distinct domains, with transactional mode enabled only on the transactional one, so an unsubscribe from a promotion is honored in full while a receipt still gets through, and they carry different headers, because a campaign has obligations a receipt does not. The signing keys and IP pools keep the reputations apart, the domain split makes the suppression behavior correct, and the header handling keeps each stream compliant on its own terms.
Suppression state and reporting stay separate too, because both are held per domain. That is the correct behavior rather than a limitation: it is precisely why an unsubscribe from your campaigns does not withhold a receipt, and why a complaint rate on one stream does not appear against the other. Do not expect a single merged list or one blended report across the two.
What one provider gives you is everything that is not the sending itself. One contract, one compliance posture and one set of certificates for a vendor review rather than two. One integration pattern, one set of APIs and webhook formats to build against. Both domains in one account instead of two vendor portals. And the same deliverability analysts across both streams, which matters because the campaign is where the volume and the complaint exposure concentrate, and it is still your brand doing the sending.
Senior deliverability analysts are part of the service rather than a separately invoiced tier, and they contact customers proactively when sending patterns look wrong - which for a retailer usually means catching a campaign's reputation sliding before peak season rather than during it. That is covered on the deliverability page.
Order confirmations, dispatch and delivery notifications, returns and refund confirmations, and invoices, where the message is part of fulfilling the order rather than a marketing touch.
Both streams under one certified provider, signed with distinct DKIM keys and running through different IP pools so neither inherits the other's reputation. Suppressions and reporting stay per domain, as they should. One contract, one integration pattern, and the same analysts across both.
Native integrations for Bloomreach Engage, Targito and Meiro, an official open-source plugin for Mautic, and compatible APIs or SMTP for anything else in the stack.
Where growth is coming from markets the big four providers do not cover, and a blended placement figure hides the one country where order confirmations are failing.
The most fragmented mailbox market there is, where national providers hold the share that matters. Plus consumer personal data on every order, an EU-governed processor, and EU or US residency by choice.
Domain rate limits that auto-increase by 20% at 75% utilization, and analysts who raise a ceiling in advance rather than after an incident.
Bot Detection separates human interaction from Apple Mail Privacy Protection opens, security-gateway prefetching and botnet clicks, so segmentation is based on people.
Shop platform, ERP, CDP and an older system that only speaks SMTP. Superzoo sends through Omnivery from several distinct platforms using both the API and the relay, so reputation and suppression state stay shared rather than split per system.
Email journaling sends exact copies of outgoing messages to an archive address from a single domain setting, without BCC rules in application code.
Yes, provided the message is sent on a domain configured as transactional. Omnivery treats transactional messages as bypassing unsubscribe and complaint suppressions, on the basis that a receipt or a dispatch notice is part of fulfilling an order rather than a marketing communication. Bounce and block suppressions still apply, because those addresses genuinely cannot or must not receive mail.
Transactional mode is enabled per domain by the Omnivery team rather than being self-serve, specifically because it changes suppression behavior. A common pattern is to separate marketing and transactional streams onto different sending domains.
Yes. Kiwi.com did it in that order - marketing moved off Mailgun first, and the results there led to transactional following. What Omnivery provides is the delivery layer: segments, templates and campaign logic stay in your CDP or automation platform, and there is nothing to migrate off the tool your team already uses.
The streams stay separated where it counts. Each is signed with its own DKIM key, which is the boundary that matters most - receivers weight a DKIM-signed domain more heavily than the IP a message arrived on, so that signature is what carries your brand's standing. Underneath it, the two run through different IP pools and send from separate domains, with transactional mode enabled only on the transactional one. They also carry different headers: Omnivery applies the headers a marketing message is required to carry, including List-Unsubscribe with one-click support under RFC8058, whether or not your platform emits them itself. Suppression state and reporting are held per domain, so the two streams keep their own - which is exactly why the marketing unsubscribe does not withhold a receipt. What running both on one provider saves you is the rest of it: one contract and one compliance posture, one integration pattern to build against, both domains in a single account, and the same deliverability analysts across both streams.
Bloomreach Engage, Targito and Meiro have native integrations - the Targito one is a premium integration built on the Targito side, available to all qualifying Targito customers. Mautic is covered by an official open-source transport plugin, OmniveryMailerBundle, published under GPL-3.0 and tested against Mautic 5.
For any other platform, the practical answer is usually yes without a dedicated connector: Omnivery natively implements the SendGrid v3, Mailgun v3 and SparkPost v1 request formats, so a tool that can already send through one of those can send through Omnivery by changing the base URL and API key. There is also an Automations API with an official Make.com app for low-code stacks, and an SMTP relay with full API parity for anything that only speaks SMTP.
Each sending domain carries a rate limit that automatically increases by 20% when it reaches 75% utilization, so gradual growth is handled without intervention. For a known event with a step change in volume, raise it with the team in advance so the ceiling is lifted before the event rather than during it.
Yes, through email journaling, which sends exact copies of outgoing messages to an archive address you nominate. It is a single domain setting rather than BCC rules distributed through application code.
Omnivery does not store message body content itself, so journaling is the mechanism if you need a copy kept. Delivery metadata is kept for a maximum of 30 days and then reduced to summary volume counts, so journaling is the mechanism if you need the message itself retained.
Omnivery is operated by a Czech entity, runs exclusively on infrastructure it owns rather than on a hyperscaler, never stores message body 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. Data residency is a customer choice between EU and US, and both run on owned infrastructure.
Omnivery also holds ISO/IEC 27701 for privacy information management alongside ISO/IEC 27001, and publishes both certificates. The full regulatory reasoning, including the CLOUD Act and Schrems II position, is on the GDPR compliant email API page, and the sub-processor list is published.
That is what the Bot Detection API is for. It returns an is_bot decision for a given interaction, built from more than 20 proprietary datasets, and identifies automated opens from Apple Mail Privacy Protection, link prefetching by corporate security gateways, and botnet clicks aimed at click-based payouts. There is also a honeypot mechanism for confirming automated clicks.
For a retailer the practical use is keeping reactivation and segmentation decisions based on human behavior. Details are on the Bot Detection API page.
Every Omnivery domain is vetted before it can send, normally within one to three working days, and there is no free tier. That is deliberate: it is the mechanism that keeps the shared sending reputation clean, since a platform accepting anonymous signups means your order confirmations share reputation with whatever those accounts send.
Plan for it in a migration timeline, and start the conversation before the peak season rather than during it.
If your order confirmations and your campaigns currently share a sending reputation, that is worth a conversation before the next peak season. Both streams can run on Omnivery, signed with separate DKIM keys and on separate IP pools so the reputations stay apart, under one contract and one set of analysts. Vetting takes one to three working days, so there is a lead time to plan around.