Security and Privacy

We take the security and privacy of your data very seriously, and these considerations were taken into account early in the development of the platform. We have designed the core of our platform around security and privacy, including special features for increased recipient data privacy.

System Architecture

All systems are fully owned and operated by Omnivery staff. We do not use any third-party cloud or VPS services. All data centers we use must be ISO 27001 and TIER 3 certified and have physical access control and 24/7 surveillance.

The system architecture is designed for scalability, redundancy, and security. Each element in our infrastructure is connected directly to our 10Gbps internal network using a dedicated interface. Our internal network spans multiple geographic locations using encrypted tunnels or dedicated fiber connections (where available). All servers are running the latest stable version of Linux distributions and use stable versions of open-source software with LTS support.

All communication is conducted over the internal network using TLS/SSL encryption for additional security. Access to our internal network is allowed only through dedicated VPN access points with authentication using password-protected certificates, and access is limited to essential personnel only.

Every element of our infrastructure is redundant and exists in at least two instances per location.

All public-facing systems (web, UI, and API interfaces) are connected to the internet only through our proxy and firewall. All other systems have no direct internet connection and must pass through our secure gateway if access to the internet is necessary (for example, installation of updates).

graph TB ui ---- core api ---- core api --- mta mta --- logs mta ---> smtp logs --- webhooks webhooks ---> web subgraph Internet smtp["Remote MX"] web["Web Endpoints"] subgraph pf [Public-facing] ui["Frontend/N+1"] api["API interfaces/N+1"] end end subgraph Internal core["Core DB/N+1"] mta["MTA/N+1"] logs["Log DB/N+1"] webhooks["Engine/N+1"] end style pf text-color:#000,fill:#bbf,stroke:#f66,stroke-width:3px,color:#000,stroke-dasharray: 5 5

Authentication

Omnivery uses various authentication methods depending on the system being accessed.

  • User interface - our UI requires a username in the form of an email address and password for authentication. Passwords must meet length (8 characters) and diversity requirements (uppercase, lowercase, digits, symbols). Users are encouraged to enable two-factor TOTP authentication. Single Sign-On (SSO) will be supported in future versions.
  • API interfaces - our API interfaces use different authentication mechanisms depending on the original API specifications. All interfaces require at least a token as a password. Tokens are randomly generated at the time of creation and can be manually regenerated from the user interface. For security reasons, there are multiple types of tokens with different roles. Only the primary account token can be used to manipulate any Omnivery account settings. It is strongly advised that this token is never used for sending messages and kept secret. IP access lists will be supported in future versions.
  • Internal services - all internal services have access limited to the internal network with a minimum password length of 16 characters and diversity (uppercase, lowercase, digits, symbols).

Data Security

Core databases

At the center of our system lies the core database system that holds information about our customers and their domains. Information in the core database contains:

  • Customer account details - the information Omnivery holds about you as our client. These include company name, address (street, city, zip, state, country), registration number, VAT number, contact person, contact email, billing email, and billing plan information.
  • User account information - the information about individual user accounts necessary to facilitate access. These include the user's username (email address), hashed password, relations to individual customer accounts, access privileges, temporary access tokens, two-factor authentication token, account holder's full name, and other vital information.
  • Domain information - domain information covers everything related to domain settings, webhooks and routes of the domain, data location assigned to a domain, DKIM keys, etc.

The core database uses multiple levels of data security:

  • Storage encryption - the data storage subsystem is encrypted using dm-crypt encrypted filesystem. This makes it impossible for anyone with physical access to retrieve data from our storage subsystem.
  • Password encryption - passwords stored in our database use Salted SHA-512 Hash with a 32-byte salt. This prevents bad actors from retrieving any plain-text passwords from the database.

The core database is operated in redundant mode with real-time replication. All non-database core systems operate with N+1 redundancy.

Location databases

Customer data and its processing are delegated into Data Locations. Each location contains systems responsible for processing and storage of data in a specific location. This allows for very granular distribution of data to meet customer needs.

Data locations are not just a geographical distinction but a technical one as well. While most systems provide an option of EU versus US data centers, we have gone a few steps further—we can have data locations specific to our customer's needs. Clients can choose to have each domain's data in a distinct data location (for example, marketing in Frankfurt, transactional in Berlin).

For clients with high-end security requirements, we can deploy a custom data location instance to their on-premise or datacenter location.

We currently operate the following data locations in the following geographic locations:

  • eu1 - 2x Prague, Czech Republic (EU)

Data locations hold event information for domains assigned to the specific data location. These include:

  • Event logs - hold information about individual message events and are retained for 30 days. After this period, only summary volume counts are available.
  • Webhook logs - hold information about webhook calls (endpoint URL, timestamp, response code). Webhook content is never stored.
  • Suppression and Allow list - hold addresses that must be suppressed (do not send) or never suppressed (allow list).

The data in all data locations is stored on encrypted storage subsystems.

Location databases are operated in redundant mode with real-time replication. All non-database systems operate with N+1 redundancy.

Data Minimization

Data that does not exist cannot leak. That is why we ensure to minimize the amount of PII as well as the overall amount of information stored. We DO NOT store message body contents, and message metadata is kept for a maximum of 30 days. The metadata for individual messages contains:

  • Timestamp - event timestamp
  • Channel - the channel used for message delivery (email/SMS)
  • Recipient hash - MD5 hash of recipient address (email, phone number, UUID)
  • Recipient - plain-text recipient address
  • Message metadata - ID, Sender, Recipient, number of attachments, Timestamp, Message headers, variables, and tags.
  • Connection metadata - information about local and remote IP, hostname, TLS (status, cipher, and keysize), bounce code, bounce message, and bounce category

Strict privacy mode

For domains with strict privacy mode enabled, only the recipient hash will be stored, and the recipient address will be replaced with the "-- anonymized --" string. All detectable PII matching the pattern for an email address or an IP address will be removed from message and connection metadata before logging.

We CANNOT guarantee removal of all PII from our event logs, as it is not feasible to detect all such information automatically.

Note that since the recipient MD5 hash represents the original recipient's address, it cannot be considered fully anonymized but only pseudonymized.

Transport Security

Omnivery uses different transport security measures depending on the type of traffic and its destination. High availability being critical for our services, we use redundant servers and employ multiple load balancing measures.

  • Public networks - all our public interfaces use SSL/TLS encryption using EC certificates with 2048-bit key length. Secure transport is enforced for webhook event data transmission, and unsecured connections and/or redirects are not allowed. Communications over API can be further secured using API allowlists to prevent the use of API credentials from unknown sources.

  • Internal network - all data is transported using SSL/TLS encryption with EC (preferred) or RSA certificates with 2048-bit key length.

  • Message transport - our MTAs (message transport agents) are configured to use opportunistic TLS for both outbound and inbound connections (for example, to attempt a secure connection first and fall back to insecure connections where secure connections are not supported). For compatibility reasons, 2048-bit RSA certificates are used.

Platform Security

Omnivery is built on a foundation of rigorous security standards, ensuring that data handled across the platform is protected in accordance with internationally recognized frameworks and regulatory requirements.

Certifications and Compliance

Omnivery currently holds 7 ISO certifications, demonstrating a sustained commitment to security management, operational excellence, and continuous improvement across its systems and processes. These certifications include:

  • ISO 9001 — Quality Management Systems
  • ISO 14001 — Environmental Management Systems
  • ISO 22301 — Business Continuity Management Systems
  • ISO 27001 — Information Security Management Systems
  • ISO 27017 — Code of Practice for Information Security Controls for Cloud Services
  • ISO 27018 — Code of Practice for Protection of Personally Identifiable Information (PII) in Public Clouds
  • ISO 27701 — Privacy Information Management Systems

A full list of these certifications is available for review in the Omnivery ISO Certificates document.

In addition, Omnivery maintains full HIPAA compliance, meeting the standards set forth by the Health Insurance Portability and Accountability Act for the secure handling of protected health information (PHI). This compliance reflects Omnivery's ability to support organizations operating in healthcare and other regulated industries where data privacy is a critical requirement. The official HIPAA compliance certificate can be accessed here.

What This Means for Users

These certifications and compliance designations provide assurance that Omnivery adheres to established protocols for:

  • Data security and confidentiality — protecting sensitive information from unauthorized access
  • Risk management — identifying and mitigating potential vulnerabilities within the platform
  • Regulatory alignment — meeting the legal and industry-specific requirements relevant to users and their organizations

Organizations seeking a platform that meets high security standards can rely on Omnivery's certified infrastructure to support their operational and compliance needs.

Operational Security

To protect our systems from abuse and attacks on a daily basis, we use a suite of internal and third-party tools for monitoring, vulnerability and incident management, and abuse prevention.

Due to the nature of abuse in the email industry, our first line of defense in abuse prevention is our customer vetting process, which minimizes the risk of onboarding bad actors. All customers are subject to vetting before signing a contract, which focuses on identifying customer identity, email history, reputation, and practices. In addition, all sending domains are subject to vetting before being approved for sending.

Our platform has built-in auditing in its core that collects critical authentication information for both external and internal calls. Audit information is subject to automated analysis by our monitoring suite.

We use open-source tools to monitor the infrastructure, audit logs, and network traffic for suspicious activity and perform vulnerability scans on a regular basis. All incidents are classified by severity, and our team prioritizes incident management based on the severity of the event.

Anti-phishing

We understand that every authenticated email infrastructure can become a vector of attack for bad actors. This is especially relevant in the financial and insurance industries. To minimize these risks, Omnivery allows customers to set up an allowlist for target URL patterns used in messages and enforce Reply-To address alignment.

This is an additional line of defense against malicious actors in case of account takeover. If a malicious actor tries to send messages using stolen credentials and the links in the message body are not on the list of allowed URL patterns, or if the attacker tries to redirect replies, the messages will be blocked. This significantly reduces the risk of account abuse for authenticated phishing attacks.

Message deduplication

This might seem trivial, but it happens quite often—a bug in code, a runaway script, or just an incorrect automation keeps sending the same message multiple times. To protect recipients, we have implemented deduplication into our delivery network. We calculate checksums for all messages to prevent the same message from being sent repeatedly.

For every message you send through Omnivery, we calculate a checksum—a message fingerprint that we keep for a couple of minutes. If a message with the same checksum is sent again, it will be suppressed from delivery to protect the recipient.

Notifications

It is one thing for us to monitor our platform, but customers often need to know about changes in their account, whether authorized or not. Omnivery sends email notifications for all account changes impacting account security. Whether it is a minor change of settings or a major change in access rights, our backend will notify the security contact of the account.

Data Access

To keep customer data private and secure, we logically isolate each customer's data from one another. Only a small group of Omnivery employees have access to customer data. The access right levels for our staff are based on their job roles using the least-privilege and need-to-know concepts. The access right assignment follows a preset process, and changes are logged in audit records.

Physical access to our servers is limited to select employees who are trained for hardware maintenance and data integrity operations. All our hardware is tracked from the moment of acquisition through installation, retirement, and destruction. Components that hold customer data (memory modules, storage devices) are physically destroyed at their end of life.

Third-Party Suppliers

Omnivery directly conducts virtually all data processing activities to provide our services. We engage third-party suppliers for specific services that we could not provide at the top quality that our customers expect. Services provided by third parties are Email Validation provided by Kickbox and SMS/RCS/Viber delivery by ProfiSMS. All our third-party suppliers must meet our security and privacy requirements. Third-party suppliers never receive any customer data without a request for such transfer being initiated by the customer.