Utilities & energy
Utility email is not a channel a customer chose to be on. It is the bill, the tariff change they are legally entitled to be told about, and the outage notice that has to arrive during the outage. It is also generated, very often, by a billing platform older than the regulations it now answers to. Omnivery is transactional email infrastructure for energy and utility retailers: E.ON and Centropol Energy send with Omnivery.
Updated: July 2026
Utilities combine constraints that usually appear separately: mandated communications, a monthly volume spike, and an unscheduled one that arrives exactly when it matters most.
A bill, a tariff or terms change, a meter reading request, a planned interruption notice: these are communications the customer is entitled to receive and the regulator generally requires you to send. They are not marketing, and treating them as marketing creates a compliance problem.
Omnivery treats transactional messages as bypassing unsubscribe and complaint suppressions, so a required communication still reaches a customer who opted out of promotional email. Bounce and block suppressions still apply. Because this changes suppression behavior, transactional mode is enabled per domain by the Omnivery team rather than being self-serve.
The billing run is predictable: a large monthly or quarterly spike you can plan for. Disruption is not. A storm, an unplanned outage or a supplier failure produces a burst of notifications with no notice, at the moment customers most need them, and frequently while your own operations team is fully occupied.
Domain rate limits on Omnivery increase automatically by 20% when they reach 75% utilization, which absorbs ordinary growth. A step change is better handled in advance: raise the expected shape with a senior deliverability analyst before the season rather than discovering the ceiling during an incident.
Utility billing and customer notification platforms are proven, business-critical and frequently a decade or more old. Upgrade cycles are measured in years. The obligations - GDPR, ISO expectations from procurement, mailbox provider authentication requirements - do not wait for the cycle.
The SMTP relay closes that gap with one configuration change and no code: point the platform at Omnivery and it inherits the certifications, retention limits and authentication handling. What it costs to keep running your own mail server is covered on on-premise MTA replacement.
"Your bill is overdue, click here" is an effective lure precisely because it is plausible from a utility, and your legitimate billing mail is the template being copied. Utilities also send to a very broad, non-technical customer base, which is exactly the population least able to spot a forgery.
Omnivery can hold an allowlist of permitted link destinations for a sending domain and reject a message outright if any link points somewhere not on it - so an edited template or an injected URL becomes a send failure rather than a customer incident. The X-OV-Require-TLS header additionally refuses delivery to a receiver that will not encrypt the connection, and works over SMTP as a mail header so a legacy platform can set it.
Billing disputes, ombudsman complaints and regulatory queries all eventually reduce to what the customer was told and when. Mail logs from a self-hosted server rarely answer it, and neither does an application log.
Email journaling sends exact copies of outgoing messages to an archive address you nominate, from a single domain setting rather than BCC rules spread across systems. It is the mechanism precisely because Omnivery does not retain message content itself.
Energy retail combines high volume, billing systems that predate the compliance regime they now sit inside, and messages customers are legally entitled to receive.
Meeting that does not take a migration project. The sending platform stays exactly as it is; its SMTP host, port and credentials change, and from that point every message leaving it passes through infrastructure that is independently audited for the obligations the platform itself cannot satisfy.
A self-hosted mail server tells you a message was accepted for delivery and nothing about what happened next: which receiver deferred it, how bounces break down, or whether a click came from a person. Notino found exactly that when it replaced its own Postfix infrastructure, where the visibility gained was worth more than the maintenance saved.
The obligation-by-obligation comparison is on the on-premise MTA replacement page.
Billing runs, tariff change notices, meter reading requests and outage communications. E.ON and Centropol Energy send with Omnivery.
The same shape of obligation on a similar systems estate: mandated customer communications from platforms that are not going to be rebuilt this year.
Service notifications, billing and planned maintenance windows, with the same broad non-technical customer base and the same impersonation exposure.
Planned interruption notices and appointment confirmations, where the message is part of an operational process rather than a customer relationship.
Where procurement requires ISO certification held by the processor itself, and an audit trail that does not stop at the application boundary.
A mail server that runs itself until authentication requirements change or an IP lands on a blocklist, and then becomes urgent for someone who has never owned it.
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 a bill, a tariff change or a planned interruption notice is a regulatory obligation rather than a marketing message. Bounce and block suppressions still apply, because those addresses genuinely cannot receive mail.
Transactional mode is enabled per domain by the Omnivery team rather than being self-serve, precisely because it changes suppression behavior. Separating mandated communications and marketing onto different sending domains is the usual pattern.
No. Change its SMTP host, port and credentials - point it at smtp.omnivery.net on port 587, authenticate with AUTH LOGIN and use STARTTLS - and it inherits Omnivery's certifications, retention limits and authentication handling. No application code changes.
The relay is not a reduced-capability path: templates, tracking control, callbacks, enforced TLS, link allowlisting and journaling are all available through X-OV-* mail headers. See on-premise MTA replacement.
Ordinary growth is handled automatically: each sending domain's rate limit increases by 20% when it reaches 75% utilization. A disruption burst is different in kind. Discuss the expected shape with your senior deliverability analyst in advance and have the ceiling raised before the season rather than during an incident.
Sending is monitored around the clock, and Omnivery makes contact when patterns look wrong rather than waiting for a ticket - which matters most when your own team is fully occupied with the outage itself.
On the outbound side, yes. Omnivery can hold an allowlist of permitted link destinations for a sending domain and reject a message outright if any link points somewhere not on that list. That turns an edited template, an injected URL or a compromised content system into a send failure rather than a phishing message delivered to your customer base under your own authenticated domain.
Alongside that, SPF, DKIM and DMARC are published once and DKIM keys rotate through CNAMEs, and X-OV-Require-TLS refuses delivery to a receiver that will not encrypt the connection. None of this stops a forgery sent from somebody else's infrastructure - that is what DMARC enforcement is for - but it does stop your own sending path becoming the delivery mechanism.
Through email journaling, which sends exact copies of outgoing messages to an archive address you nominate, enabled with a single domain setting rather than BCC rules distributed across systems.
Journaling is how this works because Omnivery does not retain message content itself - delivery metadata is kept for at most 30 days and then reduced to summary volume counts. The retention decision, and where the archive lives, stay yours.
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, and publishes all of them for download rather than supplying them on request. ISO 22301 for business continuity and ISO/IEC 20000-1 for service management are usually the two a utility procurement process asks about.
Omnivery also runs exclusively on its own physical infrastructure with no AWS, Azure or Google Cloud in the delivery path, so there is no hyperscaler subcontracting chain beneath the provider to assess. Data centers are required to be ISO 27001 and Tier 3 certified.
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.
If the billing platform is not going to change and the obligations are not going to wait, the relay bridges the two. Domain vetting takes one to three working days, so start before the next billing cycle rather than during it.