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 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. It may sound complicated, but it's really not. 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.

By default OX 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.)

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


Legacy (deprecated; only useful in specific cases)

DKIM signing can be enabled for a whole brand. OX will prepare two keys (for easier rollover) and hand over the public key to the customer so domain owners can 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 used in practice has to have the DKIM DNS records set. DKIM signatures w/o a matching DNS records are not expected and it's unclear how those are treated from receivers. They even might fail validation or getting a negative score because of that. Given the type of business the customer is running this might be a valid scenario or rather not.

Quick summary


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.

Quick summary

  • One keypair for the whole brand
  • signing key is a generic OX managed one
  • no customer domain DNS modifications/maintenance required
  • does NOT support DMARC as signing domain and mail from domain do not match
  • Microsoft 365 implements this as default as well


  • No labels