Real estate
A property portal's most valuable message is an automated one. A watchdog fires the moment a matching listing appears, and the person who reads it first books the viewing. An inquiry that does not reach the other side of the marketplace is a transaction that does not happen, for both parties and for you. Omnivery is delivery infrastructure for portals and brokerage marketplaces, where the mail is high-frequency, machine-generated, genuinely wanted by the person receiving it, and time-critical in a way that promotional email never is. Ohne-Makler, across Germany and Austria, and Bezrealitky, across Czechia and Slovakia, both send with Omnivery.
Updated: August 2026
Four failure modes account for most of the problems property portals bring to a new provider. None of them is about whether the platform can send fast enough.
This is the structural problem in portal email. A saved-search alert is triggered by the recipient's own criteria and is wanted, sometimes urgently. To a filter it looks like the opposite: high frequency, machine-generated, templated, sent to a large list, with a link to a commercial listing.
The fix is to stop that traffic sharing an identity with your promotional sending. On Omnivery the alert stream is signed with its own DKIM key, runs through its own IP pool and sends from its own domain, so the reputation it builds is its own and a newsletter's complaint rate does not decide whether tomorrow's watchdog reaches the inbox. Receivers weight a DKIM-signed domain more heavily than the IP behind it, which is why the signing key is the boundary that matters most.
In a tight market a good property is viewed within hours. An alert delayed by a queue, a retry cycle or a throttle at the receiving end is not a degraded experience, it is a worthless one, and the user learns to check the site instead of trusting the mail.
Real estate shares that property with travel: the message has an expiry. Omnivery sends according to each receiving side's requirements rather than one global profile, which is what keeps throughput up at receivers that throttle an unfamiliar sender, and every domain carries a rate limit that increases by 20% automatically at 75% utilization so a listings surge does not queue behind a ceiling.
A marketplace's core function is connecting a buyer to a seller, and on most portals that connection is an email. When it fails, neither side knows: the inquirer assumes they were ignored and the lister assumes no interest. It surfaces as a complaint about the platform rather than as a bounce in a report.
Two things help. Suppression state that distinguishes a genuine hard bounce from an unsubscribe means a transactional inquiry notification is not withheld because someone opted out of your marketing. And email journaling sends exact copies of outgoing messages to an archive address from a single domain setting, so when a user insists they were never contacted there is a record.
Portals decide who still wants alerts from opens and clicks, and both are unreliable. Apple Mail Privacy Protection opens messages automatically, corporate security gateways follow links before a person sees them, and botnets click for payout. A sunset rule fed by that keeps mailing addresses nobody reads, which is exactly how an alert stream's reputation degrades.
Omnivery's Bot Detection API returns an is_bot decision for an interaction, built from more than 20 proprietary datasets, with a honeypot mechanism for confirming automated clicks. For a portal the practical result is that a dormant subscriber is identified as dormant rather than as engaged.
Most senders have one high-value stream and a lot of noise around it. A property portal is the other way round: the automated mail is the reason people come back. A watchdog on a saved search, a price change on a followed property, a new listing in a district somebody is waiting on, an inquiry routed to a lister, a viewing confirmation. Volume is high, cadence is irregular, and every message has a short useful life.
That combination is badly served by a platform tuned for either transactional or marketing traffic alone. An alert is transactional in intent and bulk in shape, and the two halves need different handling:
List-Unsubscribe with one-click support under RFC8058, applied by Omnivery whether or not the sending system emits themPortals also run a promotional stream alongside all of this, and both can sit on Omnivery. They stay separated where it counts: distinct signing keys and IP pools, separate domains, and per-domain suppression state, so a campaign and an alert never share a reputation. That is covered on the e-commerce page, which sets out the both-streams position in full.
Property markets are local. Email markets are too. A German property buyer is far more likely to use GMX or web.de than someone in another market like the US. In Czechia, Seznam matters. That means global deliverability averages can hide the providers that matter most to your business. For a portal, the receivers that decide the business are exactly the ones a delivery platform tuned for Gmail, Outlook, Yahoo and Apple treats as tail traffic.
It gets sharper for a portal operating in more than one country, because the receiver mix changes at the border rather than gradually. Omnivery's two named customers in this sector both do. Ohne-Makler covers Germany and Austria, where GMX and web.de hold share that no global average reflects. Bezrealitky covers Czechia and Slovakia, where Seznam does the same. Each of those is two national markets with two different sets of receivers behind them, so one blended placement figure describes none of the four, and a provider optimizing for the big four is optimizing for the part of the list that matters least.
Those receivers also do not behave alike. Omnivery's own measurement shows how far apart they sit: bot-click contamination runs around 30% at Outlook and over 20% at Gmail, while GMX and Yahoo hold at 2 to 4% and Libero stays under 1%. Same metric, entirely different meaning depending on which country your listings are in. Reviewing placement and engagement per receiver rather than in aggregate is what surfaces a national provider quietly throttling your alerts in one country while the average stays healthy.
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 with no public contact route. Omnivery is a certified member of the Certified Senders Alliance, having passed its certification process against the CSA legal and technical criteria, which German and wider European receivers treat as a sender-side trust signal. It is also a member of Signal Spam in France and of M3AAWG globally. The per-provider evidence, across 126 mailbox-provider families in six world regions, is on the deliverability page.
A portal holds contact details for both sides of every inquiry, which puts the delivery layer squarely 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. Data residency is a customer choice between the EU and the US, on infrastructure Omnivery owns in both cases. The full reasoning is on the GDPR compliant email API page.
Watchdog alerts on saved searches, new-listing and price-change notifications, and the inquiry routing that connects the two sides. Ohne-Makler, across Germany and Austria, and Bezrealitky, across Czechia and Slovakia, both send with Omnivery.
Viewing confirmations, document and contract correspondence, and offer status updates, where the message is part of a transaction someone is making the largest financial decision of their life inside.
Where the receiver mix changes at the border, and GMX and web.de, or Seznam, or a regional host nobody outside that market has heard of, hold the share that decides the quarter. Placement is reviewed per receiver rather than as one blended figure.
Transactional in intent, bulk in shape. Its own DKIM key, IP pool and domain, the required bulk headers applied automatically, and rate limits that rise 20% at 75% utilization.
Bot Detection separates human interaction from Apple Mail Privacy Protection opens, security-gateway prefetching and botnet clicks, so a sunset rule retires addresses that are genuinely dormant.
When a user insists they were never contacted about an inquiry, email journaling sends exact copies of outgoing messages to an archive address from a single domain setting, with no BCC rules in application code.
The identity the alerts send under. An alert is transactional in intent and bulk in shape, so it needs to build its own reputation rather than inherit one from promotional sending. On Omnivery that means its own DKIM signing key, its own IP pool and its own sending domain. The signing key is the boundary that matters most, because receivers weight a DKIM-signed domain more heavily than the IP a message arrived on.
Omnivery also applies the headers a bulk-shaped message is required to carry, including List-Unsubscribe with one-click support under RFC8058, whether or not your platform emits them itself. That matters for alerts specifically, because a filter reading an unsubscribe-less high-frequency stream draws the obvious conclusion.
Yes, provided it is sent on a domain configured as transactional. Omnivery treats transactional messages as bypassing unsubscribe and complaint suppressions, on the basis that routing an inquiry to a lister is part of delivering the service 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, precisely because it changes suppression behavior. Keeping the service stream and the promotional stream on separate domains is the usual pattern.
It changes which receivers decide your results, and most platforms handle that badly. A portal's audience reads its mail at the providers that are large in its own market: GMX and web.de in Germany, Seznam in Czechia, and a long list of regional hosts elsewhere. A provider tuned for Gmail, Outlook, Yahoo and Apple treats exactly those receivers as tail traffic.
If you operate in more than one country it matters more, not less, because the receiver mix changes at the border rather than gradually. Both of Omnivery's named customers here are in that position: Ohne-Makler covers Germany and Austria, Bezrealitky covers Czechia and Slovakia. A single blended placement number across two countries can look healthy while alerts are failing in one of them.
Omnivery sends according to each receiving side's requirements rather than one global profile, reports per receiver rather than as a blended average, and holds relationships that make escalation possible at receivers with no public contact route. It is a certified member of the Certified Senders Alliance, which German and wider European receivers treat as a sender-side trust signal.
Each sending domain carries a rate limit that automatically increases by 20% when it reaches 75% utilization, so ordinary growth in listing volume is handled without intervention. For a known event with a step change, raise it with the team in advance so the ceiling is lifted before the batch 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, and delivery metadata is kept for a maximum of 30 days before being reduced to summary volume counts, so journaling is the mechanism if you need the message itself retained.
It matters more for a portal than for most senders, because engagement is usually what decides who keeps receiving alerts. If a sunset rule runs on opens that Apple Mail Privacy Protection generated, or clicks a security gateway made, you keep sending to addresses nobody reads, and that is how an alert stream's reputation degrades.
The Bot Detection API returns an is_bot decision for a given interaction, built from more than 20 proprietary datasets, and identifies automated opens, link prefetching and botnet clicks. 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 alerts share reputation with whatever those accounts send.
Migration itself is usually not the long part. Omnivery natively implements the SendGrid v3, Mailgun v3 and SparkPost v1 request formats, so an existing integration works after changing a base URL and an API key, and there is an SMTP relay with full API parity for anything that only speaks SMTP.
If your watchdog alerts and your newsletter currently leave on the same reputation, that is the first thing worth looking at. Vetting takes one to three working days, so there is a lead time to plan around.