Support resources
Postmaster information page
OX Cloud EU and US platforms (standard AVAS)
https://postmaster-oxseu.vadesecure.com/
OX Cloud US platforms (standard AVAS)
https://postmaster-oxsus.vadesecure.com/
Set up domain records for OX Cloud
OX Cloud is available as a whitelabel solution where all public endpoints appear under the partner's brand. This table lists the different entrypoints.
The hostnames listed here are examples. The specific ones managed by OX will be communicated as part of the onboarding process. The partner names are already required to be given by the partner during the onboarding request together with matching certificates (wildcard preferred).
The DNS records are supposed to be CNAME records pointing to the A records on the right side of the table.
"partner" in the table is always a placeholder. Your own domain and for the oxcs.net entries it is an identifier you will get during the onboarding phase from us.
"partner" in the table is always a placeholder. Your own domain and for the oxcs.net entries it is an identifier you will get during the onboarding phase from us.
| Purpose | CNAME record managed by partner (exemplary) | A record managed by OX |
|---|---|---|
| Web UI | webmail.partner.com | http.partner.xion.oxcs.net |
| Guest sharing host | share.partner.com | share.partner.xion.oxcs.net |
| DAV protocol host | dav.partner.com | dav.partner.xion.oxcs.net |
| IMAP | imap.partner.com | imap.partner.xion.oxcs.net |
| POP3 | pop.partner.com | pop.partner.xion.oxcs.net |
| SMTP (Submission) | smtp.partner.com | smtp.partner.xion.oxcs.net |
Set up MX records for OX Cloud
These MX records are to be used for mail domains which are accessed under the whitelabel domain either in EU or in US.
Please note: In case you will be using custom endpoints with your own domain you will get a different set of MX records during onboarding compared to the example below. The SPF records typically stay identical though unless stated otherwise. MX records must NOT be CNAME
| Name/Host/Alias | Time to live (TTL) | Record Type | Priority | Value/Answer/Destination |
|---|---|---|---|---|
| @ or leave blank | 3600 | MX | 10 | mx001.partner.xion.oxcs.net |
| @ or leave blank | 3600 | MX | 10 | mx002.partner.xion.oxcs.net |
| @ or leave blank | 3600 | MX | 10 | mx003.partner.xion.oxcs.net |
| @ or leave blank | 3600 | MX | 10 | mx004.partner.xion.oxcs.net |
Service discovery records for DAV (optional) (to be set up in mail domains)
| Name/Host/Alias | Time to live (TTL) | Record Type | Value/Answer/Destination |
|---|---|---|---|
| 3600 | SRV | dav.partner.com |
| 3600 | SRV | dav.partner.com |
Configure SPF for OX Cloud
SPF records are in the responsibility of the domain owner. OX provides records which can be included in the own policy and include the IP address ranges which are used for sending mail.
How to include those is outlined below. Those are valid for the primary Cloud platforms. In case of doubt please align with an OX representative if those are the right ones to use.
OX Cloud EU
| Name/Host/Alias | Time to live (TTL) | Record Type | Value/Answer/Destination |
|---|---|---|---|
| @ or leave blank | 3600 | TXT | v=spf1 include:spf.cloudeu.xion.oxcs.net ~all |
OX Cloud US
| Name/Host/Alias | Time to live (TTL) | Record Type | Value/Answer/Destination |
|---|---|---|---|
@ or leave blank | 3600 | TXT | v=spf1 include:spf.cloudus.xion.oxcs.net ~all |
TLS certificates
To keep your mail and web services secure, every domain hosted on our platform requires a valid TLS certificate. This is the certificate that allows browsers, mail clients, and other applications to establish a secure, trusted connection.
We offer the following options for maintaining TLS certificates.
Upload certificate and key
This option requires you to provide your own certificate and matching private key for the custom hostnames listed above.
- The certificate must cover all endpoints listed in the table above (Web UI, guest sharing, DAV, IMAP, POP3, SMTP) — either as individual SAN entries or, preferably, as a single wildcard certificate (e.g.
*.partner.com). - Key algorithm: RSA, 2048-bit minimum, for broad client compatibility (browsers, mail clients).
- Certificate and private key need to be provided together during onboarding; renewals must be delivered before the current certificate expires, as OX does not manage renewal for this option.
LetsEncrypt
There are two scenarios we currently can support to create and maintain certificates for you in our infrastructure.
The primary difference between the options is how the certificate is validated and what DNS configuration is required on your side.
Why Is Domain Validation Required?
Before a Certificate Authority (CA) can issue a certificate for a domain, it must verify that the party requesting the certificate is authorized to manage that domain.
We handle the certificate request and renewal process. However, proof of domain control must come from either:
Your domain’s DNS configuration, or
- A hostname that already resolves to and is reachable through our platform
Which method is used depends on the certificate option you select.
Option 1: Wildcard Certificate
A wildcard certificate covers your domain with a single certificate.
For example:
can cover hostnames such as:
mail.yourdomain.comwebmail.yourdomain.comimap.yourdomain.com- any other hostname under
yourdomain.com
Validation
Wildcard certificates require DNS validation.
You create a single CNAME record that points a special validation hostname on your domain to a corresponding hostname that we provide.
Once this record is in place, we can automatically validate the domain, issue the certificate, and handle future renewals without additional changes from you.
_acme-challenge.yourdomain.com. CNAME _acme-challenge.something-OX-provides.oxcs.net.
Best suited for
This is generally the simplest option when you want to cover multiple or changing hostnames without having to specify each hostname individually.
Option 2: Specific Hostnames — DNS Validation
Instead of covering all hostnames, a certificate can explicitly include only the hostnames you select.
For example:
Other hostnames under the domain would not automatically be covered.
Validation
This option also uses DNS validation, but validation is performed individually for each hostname.
You therefore need to create a separate CNAME validation record for each hostname included on the certificate.
For example:
3 hostnames = 3 validation CNAME records similar to the above
Once those records are configured, we handle certificate issuance and subsequent renewals automatically.
Best suited for
This option is useful when you want precise control over which hostnames are included without using a wildcard certificate.
Which Option Should I Choose?
As a general guideline:
- Choose Wildcard if you want broad coverage for subdomains with minimal ongoing DNS configuration.
- Choose Specific Hostnames with DNS Validation if you want explicit control over the hostnames covered and prefer DNS-based validation.
- Choose Specific Hostnames with HTTP Validation if the hostnames already point to our platform and you want to avoid creating additional validation records.
If you’re unsure which option is appropriate, or need the exact CNAME values for your domains, contact your account representative and we will help you determine the appropriate configuration.