For ESPs & platforms
Your product, your brand, our delivery layer
If you run an ESP, a customer data platform, or any product that sends on behalf of its customers, delivery is something you inherit rather than control. The infrastructure underneath decides your customers' placement, your data residency answer in their security review, and who they escalate to at 09:00 when a campaign stalls. Omnivery is that layer: owned European infrastructure, EU or US residency as a choice, senior deliverability analysts standing behind your senders, and Bot Detection for the engagement data your product reports on.
Updated: July 2026
What you inherit from your delivery layer
Four things pass straight through from your provider to your customers, whether or not you chose them.
Their placement is your product quality
When a customer's campaign underperforms, they do not blame the infrastructure they have never heard of. They blame your product, because that is the interface they used.
Deliverability is therefore a feature of your platform that you did not build and cannot directly fix. What you can choose is a layer where it is actively managed: senior deliverability analysts included rather than invoiced, proactive contact when sending patterns look wrong, and escalation through M3AAWG, the Certified Senders Alliance and Signal Spam rather than a public contact form.
Their sending neighborhood is whoever else is on the platform
If your delivery provider accepts anonymous free signups, your customers' transactional mail shares reputation with whatever those accounts send. You are reselling a shared resource whose quality you do not control and cannot audit.
Omnivery has no free tier and reviews every customer and every sending domain before it can send, normally within one to three working days. For a platform reselling delivery, that vetting step is the difference between a neighborhood you can vouch for and one you can only hope about.
Their security review lands on your desk
Sooner or later an enterprise prospect of yours asks where the email is processed, who the sub-processors are, and whether there is a hyperscaler in the path. That question is about your vendor, and you have to answer it.
Omnivery runs exclusively on its own physical infrastructure with no AWS, Azure or Google Cloud in the delivery path. All operations are performed by the Czech entity, including the US data centers, so selecting US residency changes where the machines are without changing who the processor is. Message content is never stored and delivery metadata is capped at 30 days. Seven ISO certifications plus HIPAA are published as downloadable certificates, and Omnivery signs Business Associate Agreements.
Their engagement data is your reporting
Your dashboards report opens and clicks, your automations trigger on them, and if you sell advertising or attribution then money moves on them. Omnivery's own research finds roughly half of B2C opens are non-human, and that the B2C bot click rate rose from about 2% in 2023 to about 16% by 2026.
A platform reporting raw engagement is therefore reporting partly on machines, and any automated decision downstream inherits the error.
Platforms already trusting Omnivery
A newsletter platform, a martech suite, a customer data platform and an engagement cloud. Some use Omnivery as their delivery layer, some run their engagement data through Bot Detection, and some do both.
White-Glove Deliverability Your Customers Can Actually Escalate To
The support gap in reselling delivery is specific and familiar. A customer reports a placement problem. Your team can see the send succeeded, so the problem is downstream, and now you are the intermediary between a frustrated customer and a provider whose support queue you do not control. You add no value in that chain, and you absorb all of the dissatisfaction.
Senior deliverability analysts, behind your senders
Omnivery includes senior deliverability analysts rather than pricing them as a support tier. For a platform partner that matters in two ways: your own team has a named person who knows the traffic you send, and where it makes commercial sense your larger customers can be brought into that conversation directly rather than relayed through you.
The engagement is not incident-driven. An analyst is involved from onboarding - sending domains, authentication records, which message categories belong together, expected volume shape - and then holds a standing call at a cadence agreed with you, weekly, every two weeks or monthly depending on volume and how much is changing. Sending is monitored around the clock, and contact is made when patterns look wrong rather than after a ticket is raised. The detail is on the deliverability page.
This applies to marketing and transactional volume alike. Most platforms send both on their customers' behalf, and Omnivery is the delivery layer under either - your product keeps the segments, the templates and the campaign logic. The two streams are signed with separate DKIM keys and run through separate IP pools, so a customer's campaign volume does not decide where their transactional mail lands, and they carry different headers. The signing key is the one to note in a partner conversation: receivers weight a DKIM-signed domain above the IP behind it, so it is the key that carries your customer's brand reputation rather than the address.
If your product has a compliance backlog, the header handling matters. Omnivery applies the headers a marketing message is required to carry, including List-Unsubscribe with one-click support under RFC8058, whether or not the platform above it emits them. When the bulk sender requirements move again, your customers are compliant through the layer underneath rather than through a release you have to schedule.
Regional receivers, which is where platforms lose placement
A global platform treats regional and national mailbox providers as tail traffic. If your customers are European, those receivers are not tail traffic - they are the audience. Omnivery grew out of Mailkit, founded in the Czech Republic in 2006, maintains provider relationships reaching niche markets, and is a member of M3AAWG, of the Certified Senders Alliance - the European sender accreditation scheme, which carries particular weight with German and wider European receivers - and of Signal Spam in France.
Data residency as an answer, not a roadmap item
Residency is usually where a platform's enterprise deal stalls. Omnivery offers EU or US data residency as a straightforward customer choice rather than a pricing tier, on infrastructure it owns in both cases. Because all operations are performed by the Czech entity - including the US data centers, with the Austin office being a sales function that runs no infrastructure - choosing US residency changes where the machines are without changing who the processor is or which legal system governs it. For a European platform selling to US customers, and equally for a US platform whose buyers want an EU-governed processor, that is a usable answer rather than a caveat.
What you can put in your own security documentation
- No AWS, Azure or Google Cloud in the delivery path - there is no hyperscaler underneath to review
- Message body content never stored; delivery metadata capped at 30 days, then summary counts only
- Strict privacy mode available per sending domain: no personal information is stored at all, and it is fully anonymized once metadata has been relayed to the customer
- No US sub-processors in the core email service; US-incorporated vendors apply only to optional, customer-selectable features
- Seven ISO certifications plus HIPAA, published as downloadable certificates, and BAAs signed
- Data centers required to be ISO 27001 and Tier 3 certified
Bot Detection as a Feature of Your Platform
Every ESP, CDP and marketing platform reports opens and clicks, and a large and growing share of both is machine-generated. Omnivery's own research puts non-human opens at roughly half of B2C volume, and the B2C bot click rate at about 16% by 2026 against 2% in 2023, with bot clicks running near 30% at Outlook against 2% to 4% at Yahoo and GMX. The full findings are in The State of Email Bots 2026, also available as a 10-page PDF.
For a platform, that inflation is not a reporting curiosity. It is a defect that propagates:
- Segmentation and "most engaged" lists include recipients who never opened anything
- Sunset and reactivation rules mis-fire in both directions, so you keep sending to addresses that only looked active
- Send-time optimization trains on proxy fetch times rather than human reading times
- Lead scoring and attribution credit machine activity
- If you monetize engagement, you are paying out on it - which is the case beehiiv brought
Two ways platforms use it
To protect revenue. beehiiv uses Omnivery Bot Detection to save $14.4M in fraudulent ad spend over six months. Where a platform pays advertisers or publishers on clicks, bot filtering is directly a margin question rather than a data-quality one.
To differentiate the product. Reporting human-only open and click rates alongside raw rates is a feature competitors largely do not have, and it survives a procurement comparison, and it makes every automation built on your engagement data defensible.
What integration requires
The API takes a batch of up to 500 events, each needing at minimum an IP address, a user agent and an event ID, and returns each event extended with an is_bot decision plus a request ID. Batches are answered asynchronously by webhook; a single-interaction mode is available synchronously but rate-limited. There is also a honeypot mechanism - a link that no human would follow - which caches IP and user agent for 30 minutes to catch novel bot infrastructure.
One hard prerequisite disqualifies some platforms: raw per-interaction event data must be available, with source IP and user agent. If your tracking layer aggregates, proxies or discards those fields, integration is not technically possible. That is a question to settle before commercial discussion rather than after.
Third-party platform access is reviewed before it is enabled, and partnership terms are volume-based. White-label arrangements are available. The product detail is on the Bot Detection API page.
What changes for you as a platform
The delivery layer underneath a platform, not the platforms themselves.
| What your customers ask about | A hyperscaler-hosted provider | Omnivery underneath your product |
|---|---|---|
| Where is the mail processed | A cloud region, on shared tenancy | Owned hardware; no AWS/Azure/GCP in the path |
| Data residency choice | Often a higher tier, still on the hyperscaler | EU or US by customer choice, owned in both cases |
| Who is the processor | Provider plus its cloud provider | The Czech entity, including the US data centers |
| Sub-processors to review | Provider plus hyperscaler plus their chain | No US sub-processors in the core email service |
| Message content retention | Commonly stored | Never stored; metadata capped at 30 days |
| Who your customer escalates to | Your support team, then a ticket queue | A named senior deliverability analyst |
| Deliverability review cadence | On incident | Standing weekly, biweekly or monthly call |
| Receiver escalation route | Provider-dependent | M3AAWG, CSA and Signal Spam channels |
| Sending neighborhood | Includes free-tier and self-signup accounts | No free tier; every customer and domain vetted |
| Engagement data quality | Raw opens and clicks, bots included | Bot Detection available, is_bot per interaction |
| Migration for your customers | Whatever the provider supports | Native SendGrid v3, Mailgun v3, SparkPost v1 |
| Compliance evidence you can forward | Usually on request under NDA | Seven ISO certificates plus HIPAA, published; BAAs signed |
The left column describes the common pattern among transactional providers running on shared public cloud rather than any single named vendor; specifics vary by provider and tier. Verify your current provider's position directly. Omnivery positions are from its product documentation, July 2026.
Who this is for
Email service providers
Where delivery is the product and its quality is your reputation. Upland Adestra works with Omnivery.
Customer data platforms
Where you own the segments and triggers and need a sending layer beneath them. Bloomreach Engage, Targito and Meiro all have native integrations.
Newsletter and creator platforms
Where engagement data is monetized and bot clicks are a direct cost. beehiiv uses Bot Detection to save $14.4M in fraudulent ad spend over six months.
Platforms that send on their customers' behalf
Booking systems, practice management, e-commerce platforms - anything where your customers' mail leaves under your infrastructure and their security review becomes yours.
Platforms selling into regulated European buyers
Where "which cloud is it on" and "who is the processor" decide the deal, and a short answer is worth more than a long one.
Agencies and managed service providers
Running sending for multiple clients, where one client's bad list should not degrade another's placement and vetting is doing real work.
At a glance
- Platforms already trusting Omnivery beehiiv, Upland Adestra, Targito and Bloomreach Engage all work with Omnivery. The relationship differs by platform - some use Omnivery as their delivery layer, some run engagement data through the Bot Detection API, and some do both. Bloomreach Engage, Targito and Meiro also have native sending integrations, and Mautic is covered by an official open-source transport plugin.
- Owned infrastructure, no hyperscaler to review Omnivery runs exclusively on its own physical infrastructure. There is no AWS, Azure or Google Cloud in the delivery path, which removes an entire tier from a partner's vendor assessment.
- Residency is a choice, not a tier Omnivery offers EU or US data residency as a customer choice on infrastructure it owns in both cases, and all operations are performed by the Czech entity including the US data centers.
- Senior deliverability analysts included Omnivery includes senior deliverability analysts rather than pricing them as a support tier, working with senders from onboarding onward on a weekly, biweekly or monthly call cadence.
- Proactive contact Sending is monitored around the clock and Omnivery contacts customers when sending patterns look wrong, rather than waiting for a support ticket.
- Accredited escalation routes Omnivery is a member of M3AAWG, of the Certified Senders Alliance and of Signal Spam, and maintains direct provider relationships reaching regional and niche markets.
- A vetted sending neighborhood Omnivery has no free tier and reviews every customer and sending domain before sending, normally within one to three working days.
- Bot Detection for engagement data The Bot Detection API returns an is_bot decision per interaction from more than 20 proprietary datasets, in batches of up to 500 events answered by webhook, with a honeypot mechanism for novel bot infrastructure.
- Documented Bot Detection outcome beehiiv uses Omnivery Bot Detection to save $14.4M in fraudulent ad spend over six months.
- Integration prerequisite for Bot Detection Raw per-interaction event data must be available with source IP and user agent. If a platform aggregates, proxies or discards those fields, integration is not technically possible.
- Partnership terms Third-party platform access to Bot Detection is reviewed before being enabled. Terms are volume-based and white-label arrangements are available.
- Compliance evidence is publishable Omnivery holds seven ISO certifications - ISO 9001, ISO/IEC 20000-1, ISO 22301, ISO/IEC 27001, ISO/IEC 27017, ISO/IEC 27018 and ISO/IEC 27701 - plus HIPAA, signs Business Associate Agreements, and publishes the certificates for download.
- Content is never stored Omnivery does not store message body content. Delivery metadata is retained for a maximum of 30 days. Strict privacy mode can be set per sending domain, in which case no personal information is stored and all of it is fully anonymized once metadata has been relayed to the customer.
Questions from platform partners
Can we white-label the delivery layer?
Your customers send under your product and your sending domains, so Omnivery is not customer-facing by default. For Bot Detection specifically, white-label arrangements are available and terms are volume-based.
The commercial shape depends on volume and on whether you want your larger customers brought into deliverability conversations directly or kept behind your own support. Both patterns exist. Discuss it with sales@omnivery.com.
Do our customers get access to a senior deliverability analyst, or just we do?
Both patterns are workable. Your own team gets a named senior deliverability analyst who knows the traffic you send in aggregate, and where it makes commercial sense your larger senders can be brought into that conversation directly rather than relayed through your support team.
The second pattern is usually the one that removes work rather than adding it, because the intermediary step - your team relaying a placement problem to a provider queue - is where platforms absorb dissatisfaction without adding value.
How does vetting work when we are onboarding customers, not Omnivery?
Every sending domain is reviewed before it can send, normally within one to three working days, and there is no free tier. For a platform that means domain provisioning has a lead time, which has to be built into your own onboarding flow rather than discovered by a customer.
Reselling delivery means inheriting your provider's abuse profile: if the platform underneath accepts anonymous signups, your customers' mail shares reputation with those accounts. The review step is what makes the shared neighborhood defensible when a customer asks.
What do we tell a customer who asks where their email is processed?
That it runs on infrastructure Omnivery owns outright, with no AWS, Azure or Google Cloud in the delivery path, and that all operations are performed by the Czech entity - including the US data centers offered for US residency, since the Austin office is a sales function that operates no infrastructure and holds no customer data.
Residency is a customer choice between EU and US on owned infrastructure either way, so selecting US changes where the machines are without changing who the processor is. Message content is never stored, delivery metadata is capped at 30 days, and there are no US sub-processors in the core email service. The certificates and the sub-processor list are published, so you can forward them rather than requesting them under NDA.
Can our customers migrate onto us from SendGrid or Mailgun without a rewrite?
Omnivery natively implements the SendGrid v3, Mailgun v3 and SparkPost v1 request formats, and can emit webhooks in those same formats plus two Bloomreach Engage formats.
So if your platform exposes an SMTP or API sending path, a customer arriving from one of those providers can often move with a configuration change rather than a development project. One-click migration also transfers domain settings, webhooks, suppressions, allowlists and templates. The detail is on the developers page.
What exactly does Bot Detection need from our tracking pipeline?
Raw per-interaction event data, with at minimum a source IP address, a user agent and an event ID. Optional fields include the action type, a recipient identifier (a hash is recommended), a message ID and timestamps. Batches take up to 500 events and are answered asynchronously by webhook; a synchronous single-interaction mode exists but is rate-limited.
The prerequisite is a genuine disqualifier for some platforms, so settle it early: if your tracking layer aggregates events, proxies them, or discards IP and user agent, integration is not technically possible. No amount of commercial agreement changes that.
Is Bot Detection about blocking traffic?
No. It returns an is_bot decision per interaction and leaves the action to you. There is no blocking, no CAPTCHA, and no automatic suppression, which matters for a platform because a false positive that silently suppressed a real recipient would be far more damaging than an unfiltered bot click.
What platforms typically do with it is report human-only rates alongside raw rates, filter the events that feed automation and scoring, and - where engagement is monetized - stop paying out on machine activity.
How is this priced for a platform?
Volume-based, and the arrangement differs from a direct sending contract. Third-party platform access to Bot Detection is reviewed before being enabled, and white-label options exist.
There is no published price list for partnerships. Contact sales@omnivery.com with your volumes and which of the two angles - delivery, bot detection, or both - you are evaluating.
Inboxing, Security, Compliance
Two separate conversations, and platforms come for either: moving your delivery layer onto owned European infrastructure with senior deliverability analysts behind it, or adding Bot Detection to engagement data you already collect. If it is the second, check first that your tracking pipeline keeps raw IP and user agent per interaction - that is the one hard prerequisite.