OX Cloud DKIM (incl. per maildomain)

What is DKIM?

DomainKeys Identified Mail (DKIM) is an email authentication standard that uses a digital signature to verify an email's origin and ensure its content hasn't been altered, preventing spam and phishing by linking the message to a specific domain owner. 

In 2024 Gmail and Yahoo introduced stricter sender requirements, forcing large senders to authenticate with SPF, DKIM and DMARC, to provide easy one-click unsubscribes, and maintain low spam complaint rates to ensure better inbox security and relevance. This initiative was nicknamed "Yahoogle". In November 2025 Yahoo & Gmail further ramped up the enforcement of non-compliant traffic (https://support.google.com/a/answer/14229414?hl=en).

Relevant standards documentation:

A few words on the Why?

The email world is moving towards a situation where it becomes increasingly important that mails are signed by DKIM and that the DKIM alignment is respected.

Without it, your outbound messages might pass SPF, but still get flagged as unauthenticated. This triggers spam filters, fails DMARC validation, and increases exposure to spoofing and phishing.

In order to accommodate this shift in requirements, we've built a DKIM solution where we can DKIM sign per maildomain with dedicated keys.

If mail domains are not enabled explicitely, then our fallback is to sign with the default brand-based key and a signing domain we control (e.g. cloudus.xion.oxcs.net) which creates valid DKIM signatures but do NOT align with the sender address and therefore is not suitable for positive DMARC results.

Especially for customers that heavily depend on forwarding, it's recommended to implement DKIM signature per maildomain for deliverability purposes.

A prerequisite for using the service is the following: 

Before a domain can be enabled for DKIM signing, there must be at least one user created with an email address for the corresponding domain or alternatively a shared maildomain must exist.

How does the solution work?

As a mailbox provider, we do not have access to your DNS - and a working DKIM solution requires that the mailserver can check the public key pairs through the sender domain DNS zone.

We are storing the private keys on our servers, but it requires a CNAME in DNS that points to a special TXT entry under the OX managed oxcloud.zone. 

The solution currently signs with RSA keys. We will be adding support for EC keys at a later stage.

The solution also supports easy key rotation, which is triggered automatically, without involving the end user or our customers but also can be triggered manually via the provisioning API.

We provide an OX Cloud DKIM API, which can generate, remove and rotate keys. The documentation of the API can also be found in the link at the top of the page.

The DKIM key generation API call then creates the required TXT records with the public keys under the oxcloud.zone domain.

You have to create the CNAME records in DNS for your domain. Depending on your DNS solution how you add that CNAME entry may vary.

How to set up a maildomain for DKIM signing

Step 1 : Check for existing DKIM keys

Check in DNS for regular keys using the same selector already.

A DKIM selector is essentially a method used to distinguish between multiple keys published in a single domain’s DNS records. 

DKIM selectors enable the receiving email server to locate and validate the sender’s public key.

You can typically find the selector name by checking the mail source of a sent mail and look for the "DKIM-Signature” section.

We use the simple naming of selector1 and selector2.

dig TXT selector1._domainkey.example.com +short
dig TXT selector2._domainkey.example.com +short

Example:

If nothing is setup with that selector name you will get an empty reply.

You can have other selectors set up, and they can co-exist with this setup, so you do not have to delete any other selectors - unless there is name-overlap with selector1 or selector2.

Step 2: Create the DNS CNAME entries

Create a CNAME entry in the DNS for the maildomain pointing to "selector1-<domainname>._domainkey.oxcloud.zone"

For the domain name you would have to substitute any dots with dashes, so spamtrap.dk becomes spamtrap-dk

You need to create a CNAME for both selector1 and selector2, so it's set up to support transparent key rotation to happen.

Example:

selector1._domainkey.spamtrap.dk IN CNAME selector1-spamtrap-dk._domainkey.oxcloud.zone
selector2._domainkey.spamtrap.dk IN CNAME selector2-spamtrap-dk._domainkey.oxcloud.zone

We suggest you add this as part of your account creation provisioning process, so right after the first email account of a domain is created,  you generate the per maildomain DKIM keys for the domain. Similar if the domain is deprovisioned, we encourage you to remove any old keys before deprovisioning.

Step 3: Create the DKIM key

a) Setup authentication to the API

API access is granted with the standard provisioning credentials.

b) Check access works correctly:

curl -u {brand}:{secret} https://us.appsuite.cloud/cloudapi/v2/mail/dkim/{brand} to list all entries of that brand.

if no keys exist it will return "No DKIM entries found" with HTTP status NOT_FOUND (404)

Depending on which environment you are currently using the URL is different:

c) Check if any keys already exist for the domain?

GET /cloudapi/v2/mail/dkim/{brand}/{domain}

d) Generate new keys

PUT /cloudapi/v2/mail/dkim/{brand}/{domain}

Step 4: Test if it works

a) Check the private keys exist on our side:

GET /cloudapi/v2/mail/dkim/{brand}/{domain}/{selector}

b) Check the public keys can now be retrieved through the TXT record like in Step 1.

You can also use external tooling to check that the CNAME entry is correct in DNS - like https://mxtoolbox.com/dkim.aspx (it requires the domain name + the selector as input)

Example:

c) Send mail to yourself and check the DKIM signature in the mail source

How to delete existing keys before deprovisioning a domain

a) Delete the active keys through the API

DELETE /cloudapi/v2/mail/dkim/{brand}/{domain}

b) Verify the keys are removed

GET /cloudapi/v2/mail/dkim/{brand}/{domain}

you should get a 404 domain not found 

c) Remove CNAME entries from the maildomain DNS configuraton

This will differ depending on the DNS provider in use.

d) Verify the entry is gone

dig TXT selector1._domainkey.spamtrap.dk +short
dig TXT selector2._domainkey.spamtrap.dk +short

The empty response will show that the CNAME entries no longer exists