App Suite Cloud

Page tree

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.

PurposeCNAME record managed by partner (exemplary)A record managed by OX
Web UIwebmail.partner.comhttp.partner.xion.oxcs.net
Guest sharing hostshare.partner.comshare.partner.xion.oxcs.net
DAV protocol hostdav.partner.comdav.partner.xion.oxcs.net
IMAPimap.partner.comimap.partner.xion.oxcs.net
POP3pop.partner.compop.partner.xion.oxcs.net
SMTP (Submission)smtp.partner.comsmtp.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/AliasTime to live (TTL)Record TypePriorityValue/Answer/Destination
@ or leave blank3600MX10mx001.partner.xion.oxcs.net
@ or leave blank3600MX10mx002.partner.xion.oxcs.net
@ or leave blank3600MX10mx003.partner.xion.oxcs.net
@ or leave blank3600MX10mx004.partner.xion.oxcs.net



Service discovery records for DAV (optional) (to be set up in mail domains)

Name/Host/AliasTime to live (TTL)Record TypeValue/Answer/Destination
_caldavs._tcp.MYDOMAIN.TLD.
3600SRVdav.partner.com
_carddavs._tcp.MYDOMAIN.TLD.
3600SRVdav.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/AliasTime to live (TTL)Record TypeValue/Answer/Destination
@ or leave blank3600TXTv=spf1 include:spf.cloudeu.xion.oxcs.net ~all

OX Cloud US

Name/Host/AliasTime to live (TTL)Record TypeValue/Answer/Destination

@ or leave blank

3600TXTv=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:

*.yourdomain.com

can cover hostnames such as:

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.

  • No labels