...

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. 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 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 custom domaintenant.

Anchor
Legacy Legacy

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 so to allow domain owners can 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 used in practice 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 might fail validation or getting a negative score because of that. Given the type of business the customer is you as service provider are running this might still be a valid scenario or rather not.

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 must SHOULD have DKIM DNS configured correctly. To be managed by respective domain owner.
  DNS entry looks entries required look like:
  mail1._domainkey CNAME mail1._domainkey.cloudeu.xion.oxcs.net.
mail2._domainkey CNAME mail2._domainkey.cloudeu.xion.oxcs.net.
  supports DMARC as signing domain and mail from domain matchEspecially those entries point directly to the correct public keys and all those records will look the same for all domains.

Anchor
Default Default

Default

...

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 is a generic OX managed oneand signing domain are generic and managed by OX
• NO 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 as well