App Suite Cloud

Page tree

Applies to

  • OX Cloud
  • OX Custom Cloud


Summary

This article describes how you use DomainKeys Identified Mail (DKIM) with OX Cloud to ensure that destination email systems trust messages sent outbound from your custom domain.

You should use DKIM in addition to SPF and extend this combination perspectively towards a DMARC policy to help prevent spoofers from sending messages that look like they are coming from your domain. DKIM lets you add a digital signature to outbound email messages in the message header. When you configure DKIM, you authorize your domain to associate, or sign, its name to an email message by using cryptographic authentication. Email systems that receive email from your domain can use this digital signature to help determine if incoming email that they receive is legitimate.

Basically, you use a private key to encrypt the header in your domain's outgoing email. You publish a public key to your domain's DNS records that receiving servers can then use to decode the signature. They use the public key to verify that the messages are really coming from you and not coming from someone spoofing your domain.


Now in practice at this moment OX by default automatically sets up DKIM via its generic domains. That means you don't need to do anything to set up DKIM for any domain names. This is the Default scenario as explained below. (The also described Legacy scenario only fits for customers managing a rather small number of domains where DNS is well controlled or ISPs w/o because of its mentioned disadvantages there.)

OX Cloud creates private and public key pairs, enables DKIM signing, and then configures the OX Cloud default policy for the whole of your tenant.


Legacy (deprecated; only useful in specific cases)

DKIM signing and the used mode can only be enabled for a whole brand. OX will prepare two keys (for easier rollover) and hand over the public key to the customer to allow domain owners to set the required DNS records.

This variant allows for aligned DKIM validation and therefore also supports DMARC policy validation but at the same time every single domain being provisioned better has to have the DKIM DNS records set. This needs to be handled by the Cloud service provider or delegated to the domain owner. DKIM signatures w/o a matching DNS records are not expected and it's unclear how those are treated from receivers. They might even fail validation or getting a negative score because of that. Given the type of business you as service provider are running this might still be a valid scenario.

Quick summary

  • One keypair for the whole brand
  • the signing domain is always set to the mail sender domain → supports DMARC as signing domain and mail from domain match
  • ALL domains managed within the brand SHOULD have DKIM DNS configured correctly. To be managed by respective domain owner.
    DNS entries required look like:
    mail1._domainkey CNAME mail1._domainkey.cloudeu.xion.oxcs.net.
    mail2._domainkey CNAME mail2._domainkey.cloudeu.xion.oxcs.net.
    Especially those entries point directly to the correct public keys and all those records will look the same for all domains.


Default

OX by default uses DKIM keypairs with its own domains. OX Cloud uses a default signing configuration for domains that do not have a policy in place.

The advantage in that case is that sender domain DNS does not need to be modified at all. Everything is under OX control. The problem with that approach is that it's not compatible with DMARC because the DKIM signing domain and sender domain not being "aligned" (matching). Any DMARC policy check would fail on the DKIM check and could only rely on the SPF assessment to succeed.

Quick summary

  • One keypair for the whole brand
  • signing key and signing domain are generic and managed by OX
  • NO customer domain DNS modifications/maintenance required
  • does NOT support DMARC as signing domain and mail from domain do not match
  • Microsoft 365 also implements this as default


  • No labels